[systemd-devel] [PATCH v2] Add FDB support

Rauta, Alin alin.rauta at intel.com
Tue Dec 16 07:28:16 PST 2014

Hi Tom,

Thanks for your feedback. I will change "VLAN" to "VLANId" in the next patch. 
Regarding the flushing of entries that's done because we don't want to have dangling configuration between system restarts, but currently the discussion is ongoing internally and it may take some time. 

Best Regards,

-----Original Message-----
From: Tom Gundersen [mailto:teg at jklm.no] 
Sent: Monday, December 15, 2014 5:49 PM
To: Rauta, Alin
Cc: Lennart Poettering; systemd Mailing List; Kinsella, Ray
Subject: Re: [systemd-devel] [PATCH v2] Add FDB support

Hi Alin,

Thanks for the patch!

Overall it looks excellent, my only concern is with the clearing of FDB entries. Is there any reason to treat this differently than how we currently treat routes and addresses?

The current logic is that we don't support run-time reconfiguration (we only apply our (static) config once when the interfaces appear, and that's it). If there is some config there already we assume that it is intentional and leave it alone (i.e., if someone else have set addresses or routes we don't remove them, we just add new ones). In the future we plan to get a dbus API where networkd can be reconfigured at run-time (i.e., change which .network file is applied to a link), and then it definitely would make sense to flush routes and addresses when removing the .network from the link, but currently we don't do that at all.

If people want to reconfigure stuff now, they can of course just restart networkd, but then they should also manually flush the settings from the kernel, and this (changing the config, restarting the daemon and flushing) is more of a hack for testing than something we support.

So the question I have is: can we treat FDB entries the same as routes and addresses and simply leave them alone rather than flushing them, and then only add the flushing logic once we start supporting reconfiguration? If not, can you explain a bit more what the typical usecase is where flushing is desirable?

As to the naming, I like the suggestion made above to call it "VLANId"
rather than "VLAN".



On Mon, Dec 15, 2014 at 11:20 AM, Alin Rauta <alin.rauta at intel.com> wrote:
> Hi,
> Based on your feedback, I've created a new patch for adding the FDB support.
> networkd takes ownership of the FDB table.
> Configuration example:
>> cat /etc/systemd/network/em1.network
> [Match]
> Name=em1
> [Network]
> DHCP=v4
> [BridgeFDB]
> MACAddress=04:44:12:34:56:70
> VLAN=2
> [BridgeFDB]
> MACAddress=04:44:12:34:56:69
> VLAN=3
> Let me know what you think.
> Thanks,
> Alin
> Alin Rauta (1):
>   Add FDB support
>  Makefile.am                              |   1 +
>  man/systemd.network.xml                  |  22 ++
>  src/libsystemd/sd-rtnl/rtnl-message.c    |  56 ++++-
>  src/libsystemd/sd-rtnl/rtnl-types.c      |  15 +-
>  src/network/networkd-fdb.c               | 357 +++++++++++++++++++++++++++++++
>  src/network/networkd-link.c              |  25 +++
>  src/network/networkd-network-gperf.gperf |   2 +
>  src/network/networkd-network.c           |  13 +-
>  src/network/networkd.h                   |  30 +++
>  src/systemd/sd-rtnl.h                    |   4 +
>  10 files changed, 514 insertions(+), 11 deletions(-)  create mode 
> 100644 src/network/networkd-fdb.c
> --
> 1.9.3
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel

More information about the systemd-devel mailing list