> 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: Ex: 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. /Alin -----Original Message----- From: Lennart Poettering [mailto:lenn...@poettering.net] Sent: Friday, December 12, 2014 3:07 PM To: Rauta, Alin Cc: 'systemd-devel@lists.freedesktop.org'; Kinsella, Ray Subject: Re: [systemd-devel] [PATCH] Add FDB support On Fri, 12.12.14 09:07, Rauta, Alin (alin.ra...@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 -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
