[systemd-devel] [PATCH] Add FDB support
alin.rauta at intel.com
Fri Dec 12 08:08:54 PST 2014
> If I get this right "fdb" only makes sense in a bridge context, correct? Maybe [BridgeFDBEntry] instead?
Yes, the FDB table is used by a Layer 2 device (switch/bridge), but an ordinary interface also has a FDB table.
[BridgeFDBEntry] seems also fine.
> I mean, if networkd would simply flush the fdb of bridge devices unconditionally when it initializes that interface, would that be a problem?
It's fine to flush the table unconditionally, but this means the operation will be done for all kind of ports even if you are on a switch or not.
There may be an issue when running networkd and a port state is UP (for example when running networkd from command line), because during the UP operation, linux kernel adds some multicast FDB entries:
bridge fdb show dev em1
01:00:5e:00:00:01 self permanent
33:33:ff:8f:e7:4b self permanent
Without "FDBControlled/FDBCleanTable" then we clear the above mentioned multicast FDB entries and no one configures them again.
A down - up operation in the code would help but I guess it's not acceptable.
From: Lennart Poettering [mailto:lennart at poettering.net]
Sent: Friday, December 12, 2014 3:07 PM
To: Rauta, Alin
Cc: 'systemd-devel at lists.freedesktop.org'; Kinsella, Ray
Subject: Re: [systemd-devel] [PATCH] Add FDB support
On Fri, 12.12.14 09:07, Rauta, Alin (alin.rauta at intel.com) wrote:
> What do you think about the following transformations:
> [FDBEntry] =====> [FDBNeigh]
We try to avoid acronyms and abbreviations unless they are very widely established. Hence I am not convinced "Neigh" is something we should use.
Given that "fdb" and "entry" are commonly used I think [FDBEntry] would be fine.
If I get this right "fdb" only makes sense in a bridge context, correct? Maybe [BridgeFDBEntry] instead?
> FDBControlled =====> FDBCleanTable
> VLAN =====> VLANId
> When FDBCleanTable is set to yes, networkd will clean the existing FDB entries for current port and FDBCleanTable will have no impact on [FDBNeigh] sections ....
Hmm, networkd takes ownership of the network interfaces it is configured to manage, hence I am wondering whether the flushing of the FDB should not be the implied logic when it takes possession of an interface? Is there a good usecase why one would *not* want this? I mean, if networkd would simply flush the fdb of bridge devices unconditionally when it initializes that interface, would that be a problem?
Lennart Poettering, Red Hat
More information about the systemd-devel