Re: [systemd-devel] [PATCH] Add FDB support
fdb and entry association is non-googlable, but bridgeFDB is. It will get you exactly where you want. -Original Message- From: Zbigniew Jędrzejewski-Szmek [mailto:zbys...@in.waw.pl] Sent: Saturday, December 13, 2014 12:20 AM To: Lennart Poettering Cc: Rauta, Alin; Kinsella, Ray; 'systemd-devel@lists.freedesktop.org' Subject: Re: [systemd-devel] [PATCH] Add FDB support On Fri, Dec 12, 2014 at 04:07:23PM +0100, Lennart Poettering wrote: 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. I don't think it's widely established. E.g. compared to VLAN, it certainly isn't. FDB is also pretty much non-googlable. ForwardingDatabase is imho much nicer and easier to search for. Also, it's not like you type those things by hand every day, so saving a few characters should not be a consideration. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add FDB support
What do you think about the following transformations: [FDBEntry] = [FDBNeigh] 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 /Alin -Original Message- From: Rauta, Alin Sent: Thursday, December 11, 2014 4:58 PM To: Lennart Poettering Cc: systemd-devel@lists.freedesktop.org; Kinsella, Ray Subject: RE: [systemd-devel] [PATCH] Add FDB support Hi Lennart, Thanks for your quick response. Regarding the naming FDBEntry. My inspiration was the bridge tool command. To add an entry using bridge command: bridge fdb add 44:44:12:34:56:73 dev em1 vlan 10 If FDBControlled is no (default value) then the forwarding database table for current port is not touched even if we have entries in the [FDBEntry] section of the file. The reason behind introducing FDBControlled is that we want to have the table cleared even if we don't want to add entries. So, if FDBControlled is set to yes, networkd clears the existing entries (if any) and adds those specified in the FDBEntry section(if any). Do you have any other suggestion for [FDBEntry] ? Best Regards, Alin -Original Message- From: Lennart Poettering [mailto:lenn...@poettering.net] Sent: Thursday, December 11, 2014 4:16 PM To: Rauta, Alin Cc: systemd-devel@lists.freedesktop.org; Kinsella, Ray Subject: Re: [systemd-devel] [PATCH] Add FDB support On Thu, 11.12.14 08:07, Alin Rauta (alin.ra...@intel.com) wrote: Hi, I've added support for handling the forwarding database table for a port. FDB entries can be configured statically through the .network files. To resume, - I've added a new boolean for the main network structure, named FDBControlled which is read from the .network file and defaults to false. - I've added a new section FDBEntry accepting 2 key-value pairs: -MACAddress (mandatory) -VLAN (optional) When FDBControlled is set to yes in the network section, networkd: - gets the FDB entries for current port; - clears them - configures those specified in the [FDBEntry] section. Configuration example: [Network] DHCP=v4 FDBControlled=yes [FDBEntry] MACAddress=44:44:12:34:56:71 VLAN=9 [FDBEntry] MACAddress=44:44:12:34:56:72 VLAN=10 Hmm, quick thoughts regarding the naming: can we find a better name than [FDBEntry] for this? At least I cannot really make much sense of this. Could you improve the man page a bit, explaining what fdb actually is? Currently VLANs are configured in a [VLAN] section, with an Id= setting to configure the id. Maybe following this naming the setting you introduce above should be called VLANId? What happens if FDBControlled is no, but still FDBEntrys specified? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
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
Re: [systemd-devel] [PATCH] Add FDB support
On 12/12/2014 03:07 PM, Lennart Poettering wrote: Given that fdb and entry are commonly used I think [FDBEntry] would be fine. It exist there in the first place makes it an entry so what's wrong with just calling this entry [FDB]? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add FDB support
On 12/12/2014 03:12 PM, Jóhann B. Guðmundsson wrote: On 12/12/2014 03:07 PM, Lennart Poettering wrote: Given that fdb and entry are commonly used I think [FDBEntry] would be fine. It exist there in the first place makes it an entry so what's wrong with just calling this entry [FDB]? Ignore that I asked for an opinion from the network guys and they went like what does FDB stand for? After I explained it to them they said why not just call it [BridgeFDB] ... JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add FDB support
Hi, Jóhann B. Guðmundsson: After I explained it to them they said why not just call it [BridgeFDB] ... +1 -- -- Matthias Urlichs ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add FDB support
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
Re: [systemd-devel] [PATCH] Add FDB support
Hi, [BrigdeFDB] can be also fine. It's just that [BridgeFDB] makes you think at the entire forwarding database table and you are actually defining only one entry. [BridgeFDBEntry] makes you think at just one entry in that table. /Alin -Original Message- From: systemd-devel [mailto:systemd-devel-boun...@lists.freedesktop.org] On Behalf Of Matthias Urlichs Sent: Friday, December 12, 2014 3:32 PM To: systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] [PATCH] Add FDB support Hi, Jóhann B. Guðmundsson: After I explained it to them they said why not just call it [BridgeFDB] ... +1 -- -- Matthias Urlichs ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add FDB support
On 12/12/2014 04:12 PM, Rauta, Alin wrote: Hi, [BrigdeFDB] can be also fine. It's just that [BridgeFDB] makes you think at the entire forwarding database table and you are actually defining only one entry. [BridgeFDBEntry] makes you think at just one entry in that table. Hmm So it can grow quite large with multiple entries along with all the other bridging features. At this point in time I'm actually wondering if it would not be better to introduce type .bridge networkd file to cover all current and future bridge features ( for example you probably want to be able to define that 802.1ad tag in an [Bridge] section as well right? ) as opposed to be cluttering the .network file with all of those options. Do you have any number of how many various type bridge entries will need to be supported by networkd in the long run? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add FDB support
For now I'm concerned with the FDB entries. They are in the .network files following the logic of [Address] [Route] sections. /Alin -Original Message- From: systemd-devel [mailto:systemd-devel-boun...@lists.freedesktop.org] On Behalf Of Jóhann B. Guðmundsson Sent: Friday, December 12, 2014 4:41 PM To: systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] [PATCH] Add FDB support On 12/12/2014 04:12 PM, Rauta, Alin wrote: Hi, [BrigdeFDB] can be also fine. It's just that [BridgeFDB] makes you think at the entire forwarding database table and you are actually defining only one entry. [BridgeFDBEntry] makes you think at just one entry in that table. Hmm So it can grow quite large with multiple entries along with all the other bridging features. At this point in time I'm actually wondering if it would not be better to introduce type .bridge networkd file to cover all current and future bridge features ( for example you probably want to be able to define that 802.1ad tag in an [Bridge] section as well right? ) as opposed to be cluttering the .network file with all of those options. Do you have any number of how many various type bridge entries will need to be supported by networkd in the long run? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add FDB support
On Fri, Dec 12, 2014 at 04:07:23PM +0100, Lennart Poettering wrote: 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. I don't think it's widely established. E.g. compared to VLAN, it certainly isn't. FDB is also pretty much non-googlable. ForwardingDatabase is imho much nicer and easier to search for. Also, it's not like you type those things by hand every day, so saving a few characters should not be a consideration. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add FDB support
The in the field problem is that after what firmware 1.7 changes with Intel network drivers or what not things broke due to the fact that network interfaces settings did not get inherited to the bridge interface and we need to avoid that problem, which is why I think we need to redefine how we fundamentally are defining type network devices On Sat, Dec 13, 2014, 00:20 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Fri, Dec 12, 2014 at 04:07:23PM +0100, Lennart Poettering wrote: 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. I don't think it's widely established. E.g. compared to VLAN, it certainly isn't. FDB is also pretty much non-googlable. ForwardingDatabase is imho much nicer and easier to search for. Also, it's not like you type those things by hand every day, so saving a few characters should not be a consideration. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Add FDB support
Signed-off-by: Alin Rauta alin.ra...@intel.com
---
Makefile.am | 1 +
man/systemd.network.xml | 31 +++
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 | 37
src/network/networkd-network-gperf.gperf | 3 +
src/network/networkd-network.c | 13 ++
src/network/networkd.h | 32 +++
src/systemd/sd-rtnl.h| 4 +
10 files changed, 539 insertions(+), 10 deletions(-)
create mode 100644 src/network/networkd-fdb.c
diff --git a/Makefile.am b/Makefile.am
index 6f02c74..02dd273 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -5252,6 +5252,7 @@ libsystemd_networkd_core_la_SOURCES = \
src/network/networkd-address.c \
src/network/networkd-route.c \
src/network/networkd-manager.c \
+ src/network/networkd-fdb.c \
src/network/networkd-address-pool.c
nodist_libsystemd_networkd_core_la_SOURCES = \
diff --git a/man/systemd.network.xml b/man/systemd.network.xml
index 1edaa0b..9d44641 100644
--- a/man/systemd.network.xml
+++ b/man/systemd.network.xml
@@ -249,6 +249,15 @@
/listitem
/varlistentry
varlistentry
+
termvarnameFDBControlled=/varname/term
+listitem
+paraA boolean. When true,
deletes existing FDB entries
+and configures those specified
in [FDBEntry] section. Defaults
+to false.
+/para
+/listitem
+/varlistentry
+varlistentry
termvarnameLLMNR=/varname/term
listitem
paraA boolean or
literalresolve/literal. When true, enables
@@ -549,6 +558,28 @@
/refsect1
refsect1
+title[FDBEntry] Section Options/title
+paraThe literal[FDBEntry]/literal section
accepts the following keys. Specify
+several literal[FDBEntry]/literal sections to
configure several static MAC table entries./para
+
+variablelist class='network-directives'
+varlistentry
+
termvarnameMACAddress=/varname/term
+listitem
+paraAs in the
literal[Network]/literal section. This key is mandatory./para
+/listitem
+/varlistentry
+varlistentry
+termvarnameVLAN=/varname/term
+listitem
+paraThe VLAN for the new
static MAC table entry.
+If omitted, no VLAN info is
appended to the new static MAC table entry./para
+/listitem
+/varlistentry
+/variablelist
+/refsect1
+
+refsect1
titleExample/title
example
title/etc/systemd/network/50-static.network/title
diff --git a/src/libsystemd/sd-rtnl/rtnl-message.c
b/src/libsystemd/sd-rtnl/rtnl-message.c
index 165e84d..9099440 100644
--- a/src/libsystemd/sd-rtnl/rtnl-message.c
+++ b/src/libsystemd/sd-rtnl/rtnl-message.c
@@ -220,6 +220,58 @@ int sd_rtnl_message_new_route(sd_rtnl *rtnl,
sd_rtnl_message **ret,
return 0;
}
+int sd_rtnl_message_neigh_set_flags(sd_rtnl_message *m, uint8_t flags) {
+struct ndmsg *ndm;
+
+assert_return(m, -EINVAL);
+assert_return(m-hdr, -EINVAL);
+assert_return(rtnl_message_type_is_neigh(m-hdr-nlmsg_type), -EINVAL);
+
+ndm = NLMSG_DATA(m-hdr);
+ndm-ndm_flags |= flags;
+
+return 0;
+}
+
+int sd_rtnl_message_neigh_set_state(sd_rtnl_message *m, uint16_t state) {
+struct ndmsg *ndm;
+
+assert_return(m, -EINVAL);
+assert_return(m-hdr, -EINVAL);
+assert_return(rtnl_message_type_is_neigh(m-hdr-nlmsg_type), -EINVAL);
+
+ndm = NLMSG_DATA(m-hdr);
+ndm-ndm_state |= state;
+
+return 0;
+}
+
+int sd_rtnl_message_neigh_get_flags(sd_rtnl_message *m, uint8_t *flags) {
+struct ndmsg *ndm;
+
+assert_return(m, -EINVAL);
+assert_return(m-hdr, -EINVAL);
+
[systemd-devel] [PATCH] Add FDB support
Hi, I've added support for handling the forwarding database table for a port. FDB entries can be configured statically through the .network files. To resume, - I've added a new boolean for the main network structure, named FDBControlled which is read from the .network file and defaults to false. - I've added a new section FDBEntry accepting 2 key-value pairs: -MACAddress (mandatory) -VLAN (optional) When FDBControlled is set to yes in the network section, networkd: - gets the FDB entries for current port; - clears them - configures those specified in the [FDBEntry] section. Configuration example: [Network] DHCP=v4 FDBControlled=yes [FDBEntry] MACAddress=44:44:12:34:56:71 VLAN=9 [FDBEntry] MACAddress=44:44:12:34:56:72 VLAN=10 Thanks, Alin Alin Rauta (1): Add FDB support Makefile.am | 1 + man/systemd.network.xml | 31 +++ 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 | 37 src/network/networkd-network-gperf.gperf | 3 + src/network/networkd-network.c | 13 ++ src/network/networkd.h | 32 +++ src/systemd/sd-rtnl.h| 4 + 10 files changed, 539 insertions(+), 10 deletions(-) create mode 100644 src/network/networkd-fdb.c -- 1.9.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add FDB support
On Thu, 11.12.14 08:07, Alin Rauta (alin.ra...@intel.com) wrote: Hi, I've added support for handling the forwarding database table for a port. FDB entries can be configured statically through the .network files. To resume, - I've added a new boolean for the main network structure, named FDBControlled which is read from the .network file and defaults to false. - I've added a new section FDBEntry accepting 2 key-value pairs: -MACAddress (mandatory) -VLAN (optional) When FDBControlled is set to yes in the network section, networkd: - gets the FDB entries for current port; - clears them - configures those specified in the [FDBEntry] section. Configuration example: [Network] DHCP=v4 FDBControlled=yes [FDBEntry] MACAddress=44:44:12:34:56:71 VLAN=9 [FDBEntry] MACAddress=44:44:12:34:56:72 VLAN=10 Hmm, quick thoughts regarding the naming: can we find a better name than [FDBEntry] for this? At least I cannot really make much sense of this. Could you improve the man page a bit, explaining what fdb actually is? Currently VLANs are configured in a [VLAN] section, with an Id= setting to configure the id. Maybe following this naming the setting you introduce above should be called VLANId? What happens if FDBControlled is no, but still FDBEntrys specified? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add FDB support
On 12/11/2014 04:07 PM, Alin Rauta wrote: [Network] DHCP=v4 FDBControlled=yes [FDBEntry] MACAddress=44:44:12:34:56:71 VLAN=9 [FDBEntry] MACAddress=44:44:12:34:56:72 VLAN=10 Any reason why you are adding a boolean variable here -- FDBControlled=yes -- It should be safe to assume if any type network unit contains [FDBEntry] it is being FDBControlled If that is not sufficient it arguably should be split into it's own network type unit instead. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add FDB support
On 12/11/2014 04:16 PM, Lennart Poettering wrote: What happens if FDBControlled is no, but still FDBEntrys specified? Cant we simply address those no/yes cases by extending the [Install] section to cover all those [foo] entries Something like.. [Network] DHCP=v4 [FDB] MACAddress=44:44:12:34:56:71 VLAN=9 [Install] Enable=FDB With no [Install] section meaning it's not enabled if the existence of those [Foo] entries are not enough? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add FDB support
Hi Lennart, Thanks for your quick response. Regarding the naming FDBEntry. My inspiration was the bridge tool command. To add an entry using bridge command: bridge fdb add 44:44:12:34:56:73 dev em1 vlan 10 If FDBControlled is no (default value) then the forwarding database table for current port is not touched even if we have entries in the [FDBEntry] section of the file. The reason behind introducing FDBControlled is that we want to have the table cleared even if we don't want to add entries. So, if FDBControlled is set to yes, networkd clears the existing entries (if any) and adds those specified in the FDBEntry section(if any). Do you have any other suggestion for [FDBEntry] ? Best Regards, Alin -Original Message- From: Lennart Poettering [mailto:lenn...@poettering.net] Sent: Thursday, December 11, 2014 4:16 PM To: Rauta, Alin Cc: systemd-devel@lists.freedesktop.org; Kinsella, Ray Subject: Re: [systemd-devel] [PATCH] Add FDB support On Thu, 11.12.14 08:07, Alin Rauta (alin.ra...@intel.com) wrote: Hi, I've added support for handling the forwarding database table for a port. FDB entries can be configured statically through the .network files. To resume, - I've added a new boolean for the main network structure, named FDBControlled which is read from the .network file and defaults to false. - I've added a new section FDBEntry accepting 2 key-value pairs: -MACAddress (mandatory) -VLAN (optional) When FDBControlled is set to yes in the network section, networkd: - gets the FDB entries for current port; - clears them - configures those specified in the [FDBEntry] section. Configuration example: [Network] DHCP=v4 FDBControlled=yes [FDBEntry] MACAddress=44:44:12:34:56:71 VLAN=9 [FDBEntry] MACAddress=44:44:12:34:56:72 VLAN=10 Hmm, quick thoughts regarding the naming: can we find a better name than [FDBEntry] for this? At least I cannot really make much sense of this. Could you improve the man page a bit, explaining what fdb actually is? Currently VLANs are configured in a [VLAN] section, with an Id= setting to configure the id. Maybe following this naming the setting you introduce above should be called VLANId? What happens if FDBControlled is no, but still FDBEntrys specified? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add FDB support
would this work the same for VXLAN? On Thu Dec 11 2014 at 11:59:05 AM Rauta, Alin alin.ra...@intel.com wrote: Hi Lennart, Thanks for your quick response. Regarding the naming FDBEntry. My inspiration was the bridge tool command. To add an entry using bridge command: bridge fdb add 44:44:12:34:56:73 dev em1 vlan 10 If FDBControlled is no (default value) then the forwarding database table for current port is not touched even if we have entries in the [FDBEntry] section of the file. The reason behind introducing FDBControlled is that we want to have the table cleared even if we don't want to add entries. So, if FDBControlled is set to yes, networkd clears the existing entries (if any) and adds those specified in the FDBEntry section(if any). Do you have any other suggestion for [FDBEntry] ? Best Regards, Alin -Original Message- From: Lennart Poettering [mailto:lenn...@poettering.net] Sent: Thursday, December 11, 2014 4:16 PM To: Rauta, Alin Cc: systemd-devel@lists.freedesktop.org; Kinsella, Ray Subject: Re: [systemd-devel] [PATCH] Add FDB support On Thu, 11.12.14 08:07, Alin Rauta (alin.ra...@intel.com) wrote: Hi, I've added support for handling the forwarding database table for a port. FDB entries can be configured statically through the .network files. To resume, - I've added a new boolean for the main network structure, named FDBControlled which is read from the .network file and defaults to false. - I've added a new section FDBEntry accepting 2 key-value pairs: -MACAddress (mandatory) -VLAN (optional) When FDBControlled is set to yes in the network section, networkd: - gets the FDB entries for current port; - clears them - configures those specified in the [FDBEntry] section. Configuration example: [Network] DHCP=v4 FDBControlled=yes [FDBEntry] MACAddress=44:44:12:34:56:71 VLAN=9 [FDBEntry] MACAddress=44:44:12:34:56:72 VLAN=10 Hmm, quick thoughts regarding the naming: can we find a better name than [FDBEntry] for this? At least I cannot really make much sense of this. Could you improve the man page a bit, explaining what fdb actually is? Currently VLANs are configured in a [VLAN] section, with an Id= setting to configure the id. Maybe following this naming the setting you introduce above should be called VLANId? What happens if FDBControlled is no, but still FDBEntrys specified? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add FDB support
Hi Johann, If FDBControlled is no then we don't want to touch the forwarding database table for this port. If it's yes, then we want to control the FDB table (delete existing entries). [Install] section can be an alternative. What about FDB=enable ? - in case we want to add something else to the install section (SMTH=enable). Best Regards, Alin -Original Message- From: systemd-devel [mailto:systemd-devel-boun...@lists.freedesktop.org] On Behalf Of Jóhann B. Guðmundsson Sent: Thursday, December 11, 2014 4:57 PM To: systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] [PATCH] Add FDB support On 12/11/2014 04:16 PM, Lennart Poettering wrote: What happens if FDBControlled is no, but still FDBEntrys specified? Cant we simply address those no/yes cases by extending the [Install] section to cover all those [foo] entries Something like.. [Network] DHCP=v4 [FDB] MACAddress=44:44:12:34:56:71 VLAN=9 [Install] Enable=FDB With no [Install] section meaning it's not enabled if the existence of those [Foo] entries are not enough? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add FDB support
On 12/11/2014 05:07 PM, Rauta, Alin wrote: Hi Johann, If FDBControlled is no then we don't want to touch the forwarding database table for this port. If it's yes, then we want to control the FDB table (delete existing entries). [Install] section can be an alternative. What about FDB=enable ? - in case we want to add something else to the install section (SMTH=enable). [Install] Enable=foo is more generic and could potential cover the requirements requested in the networkd link state thread earlier in this month If you want to enable more in the install section you simple add Also=SMTH or more Enable= entries as in... [Install] Enable=FDB Also=SMTH Or [Install] Enable=FDB Enable=SMTH This would make this more consistent with other type systemd units JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
