[systemd-devel] [PATCH] Add FDB support

[Rauta, Alin]

> 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: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

--
Lennart Poettering, Red Hat