Re: [systemd-devel] networkd: dbus API for networkd reconfiguration at run-time
Yes. It makes sence. Thanks, Alin -Original Message- From: Tom Gundersen [mailto:t...@jklm.no] Sent: Thursday, May 21, 2015 3:20 PM To: Rauta, Alin Cc: Lennart Poettering; systemd-devel@lists.freedesktop.org; Belkind, Nadav Subject: Re: networkd: dbus API for networkd reconfiguration at run-time On Tue, May 19, 2015 at 10:40 AM, Rauta, Alin alin.ra...@intel.com wrote: Hi Lennart, Thanks for the answers. One more questions. Just a curiosity of mine. Currently, a user has to write scripts if he wants to save the run-time configuration in networkd format or to use a configuration management tool like chef for example. Even with the latter, the user still needs to write scripts. What about saving the run-time configuration in networkd format with networkctl maybe ? Something like networkctl save or networkctl save config with extensions to provide per port configuration saving, output directory for saved configuration and so on ... ? Not entirely sure I understand the question, but this is what I have in mind: we support three config sources at the moment: stuff in /lib which is shipped by packages, stuff in /etc that is provided by the admin and is persistent between reboots and stuff in /run which is lost on reboot. Our future API should have a switch allowing the config we apply to either be persistent (written out to /etc) or ephemeral (written out to /run), so that any config in networkd is backed by a config file somewhere. Does that make sense? Does it answer your question, or is there some other type of config you would like to write out? Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd: dbus API for networkd reconfiguration at run-time
Hi Lennart, Thanks for the answers. One more questions. Just a curiosity of mine. Currently, a user has to write scripts if he wants to save the run-time configuration in networkd format or to use a configuration management tool like chef for example. Even with the latter, the user still needs to write scripts. What about saving the run-time configuration in networkd format with networkctl maybe ? Something like networkctl save or networkctl save config with extensions to provide per port configuration saving, output directory for saved configuration and so on ... ? Best Regards, Alin -Original Message- From: Lennart Poettering [mailto:lenn...@poettering.net] Sent: Friday, May 15, 2015 7:34 PM To: Rauta, Alin Cc: systemd-devel@lists.freedesktop.org; Tom Gundersen; Belkind, Nadav Subject: Re: networkd: dbus API for networkd reconfiguration at run-time On Thu, 30.04.15 12:57, Rauta, Alin (alin.ra...@intel.com) wrote: Hi Tom, Lennart, I have some questions regarding dbus API and run-time networkd configuration. I would really appreciate your answers/suggestions. First, when upstreaming BridgeFDB support in networkd, I had (in the first place) a patch composed of 2 parts: - One part for clearing existing configuration; - One part for setting new FDB entries; Since networkd doesn't currently clear existing configuration, only the first part of the patch was accepted. At that time you said that: 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. Do you have any updates or more information on dbus API (how would this be actually done, how would work) ? Not really, nobody hasbeen working on adding any API for this yet. Given the delays around kdbus I think we should start adding an API for this now however, but this requires careful consideration I figure. I'll try to get this process started with Tom. What extensions to existing networkd functionality would the dbus API bring ? Well, initially it will just open up what we already have. i.e. it will carry an API for creating .netdev interface, and for applying .link and .network files to interfaces. Second, regarding BindCarrier= functionality, would dbus API make it possible to modify the string content or the bind carrier functionality at run-time ? Yes, but I think this would be the second step... Moreover, we currently have the case where networkd is running and has some ports involved in BindCarrier= dependencies. Then some of this ports are run-time added to a team (link aggregation) device (maybe through command line). In this case the carrier dependencies affect the team device functionality creating confusion at one point in time (team tries to get the childs up/down, but the functionality is affected by the carrier dependencies between childs or between childs and other ports outside of the team device). Would dbus API be of any help in this case ? or Do you have any suggestions on how to avoid these cases ? well, sure, if we make BindCarrier= dynamically settable, then you should be able to cover this nicely... 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] networkd: dbus API for networkd reconfiguration at run-time
Hi guys, Any updates on this one ? Thanks, Alin From: Rauta, Alin Sent: Thursday, April 30, 2015 1:57 PM To: systemd-devel@lists.freedesktop.org; Tom Gundersen; lenn...@poettering.net Cc: Belkind, Nadav Subject: networkd: dbus API for networkd reconfiguration at run-time Hi Tom, Lennart, I have some questions regarding dbus API and run-time networkd configuration. I would really appreciate your answers/suggestions. First, when upstreaming BridgeFDB support in networkd, I had (in the first place) a patch composed of 2 parts: - One part for clearing existing configuration; - One part for setting new FDB entries; Since networkd doesn't currently clear existing configuration, only the first part of the patch was accepted. At that time you said that: 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. Do you have any updates or more information on dbus API (how would this be actually done, how would work) ? What extensions to existing networkd functionality would the dbus API bring ? Second, regarding BindCarrier= functionality, would dbus API make it possible to modify the string content or the bind carrier functionality at run-time ? Moreover, we currently have the case where networkd is running and has some ports involved in BindCarrier= dependencies. Then some of this ports are run-time added to a team (link aggregation) device (maybe through command line). In this case the carrier dependencies affect the team device functionality creating confusion at one point in time (team tries to get the childs up/down, but the functionality is affected by the carrier dependencies between childs or between childs and other ports outside of the team device). Would dbus API be of any help in this case ? or Do you have any suggestions on how to avoid these cases ? Thank you in advance, Alin Rauta Software Applications Engineer +353 (0) 87 101 8449 Intel Shannon Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 Business address: Dromore House, East Park, Shannon, Co. Clare ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] networkd: dbus API for networkd reconfiguration at run-time
Hi Tom, Lennart, I have some questions regarding dbus API and run-time networkd configuration. I would really appreciate your answers/suggestions. First, when upstreaming BridgeFDB support in networkd, I had (in the first place) a patch composed of 2 parts: - One part for clearing existing configuration; - One part for setting new FDB entries; Since networkd doesn't currently clear existing configuration, only the first part of the patch was accepted. At that time you said that: 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. Do you have any updates or more information on dbus API (how would this be actually done, how would work) ? What extensions to existing networkd functionality would the dbus API bring ? Second, regarding BindCarrier= functionality, would dbus API make it possible to modify the string content or the bind carrier functionality at run-time ? Moreover, we currently have the case where networkd is running and has some ports involved in BindCarrier= dependencies. Then some of this ports are run-time added to a team (link aggregation) device (maybe through command line). In this case the carrier dependencies affect the team device functionality creating confusion at one point in time (team tries to get the childs up/down, but the functionality is affected by the carrier dependencies between childs or between childs and other ports outside of the team device). Would dbus API be of any help in this case ? or Do you have any suggestions on how to avoid these cases ? Thank you in advance, Alin Rauta Software Applications Engineer +353 (0) 87 101 8449 Intel Shannon Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 Business address: Dromore House, East Park, Shannon, Co. Clare ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] libsystemd doesn't handle properly empty messages from kernel
Hi Tom, Nice. Thanks, Alin -Original Message- From: Tom Gundersen [mailto:t...@jklm.no] Sent: Monday, March 23, 2015 9:45 PM To: Rauta, Alin Cc: systemd Mailing List; Kinsella, Ray Subject: Re: [systemd-devel] [PATCH] libsystemd doesn't handle properly empty messages from kernel Hi Alin, Thanks for the fix! I made some changes to it, but kept the commit message and authorship as the idea is unchanged. Please take a look that this still solves your problem. Cheers, Tom On Wed, Mar 18, 2015 at 1:06 PM, Alin Rauta alin.ra...@intel.com wrote: Hi, Systemd strips out NLMSG_DONE piece from a multi-part message adding into the receive queue only the messages containing actual data. If we send a request to the kernel for getting the forwarding database table (just an example), the response will be a multi-part message like below: 1. FDB entry 1; 2. FDB entry 2; 3. NLMSG_DONE; libsystemd strips out 3. NLMSG_DONE; part and places into the receive queue a pointer to 1. FDB entry 1;. But if the FDB table is empty, the respose from the kernel will look like below: 1. NLMSG_DONE; libsystemd strips out 1. NLMSG_DONE; part and since there is no actual data got, it continues waiting until reaching timeout. Therefore, a call to sd_rtnl_call to send and wait for a response from kernel will exit with timeout which is interpreted as error in communication. The patch I've attached, adds 1. NLMSG_DONE; to the receive queue only when getting empty response from kernel. This way, a call like sd_rtnl_call will not block anymore. It works fine, but it may be just an workaround. Let me know what you think. Alin Rauta (1): libsystemd doesn't handle properly empty messages from kernel src/libsystemd/sd-rtnl/rtnl-message.c | 4 +++- src/libsystemd/sd-rtnl/rtnl-types.c | 1 + src/libsystemd/sd-rtnl/sd-rtnl.c | 14 ++ 3 files changed, 18 insertions(+), 1 deletion(-) -- 1.9.3 ___ 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 v4] Added support for Uplink Failure Detection using BindCarrier
Thank you.
/Alin
-Original Message-
From: Tom Gundersen [mailto:t...@jklm.no]
Sent: Friday, February 27, 2015 7:05 PM
To: Rauta, Alin
Cc: systemd-devel@lists.freedesktop.org; Kinsella, Ray
Subject: Re: [systemd-devel] [PATCH v4] Added support for Uplink Failure
Detection using BindCarrier
Hi Alin,
On Fri, Feb 27, 2015 at 6:44 AM, Rauta, Alin alin.ra...@intel.com wrote:
Can we please draw a conclusion in this case ?
Sorry for the long time it has taken to get this patchset reviewed.
I have just gone through it now, and it looks great. You are right that the
LINK_STATE_DOWN can be done separately. Pushed.
Thanks for all your work on this. Much appreciated!
Cheers,
Tom
-Original Message-
From: systemd-devel
[mailto:systemd-devel-boun...@lists.freedesktop.org] On Behalf Of
Rauta, Alin
Sent: Friday, February 20, 2015 10:37 AM
To: Tom Gundersen
Cc: Kinsella, Ray; systemd-devel@lists.freedesktop.org
Subject: Re: [systemd-devel] [PATCH v4] Added support for Uplink
Failure Detection using BindCarrier
Hi Tom,
Thank you. Please let me know if you have any questions regarding the
implementation.
We can have another patch for the DOWN logic. It's a little bit complicated
since we don't have UP either and since during UP operation we don't know the
previous port state so that we get back to it.
Best Regards,
Alin
-Original Message-
From: Tom Gundersen [mailto:t...@jklm.no]
Sent: Friday, February 20, 2015 10:27 AM
To: Rauta, Alin
Cc: lenn...@poettering.net; zbys...@in.waw.pl;
systemd-devel@lists.freedesktop.org; Kinsella, Ray
Subject: Re: [PATCH v4] Added support for Uplink Failure Detection
using BindCarrier
On Fri, Feb 20, 2015 at 10:50 AM, Rauta, Alin alin.ra...@intel.com wrote:
Hi Tom, Lennart, Zbyszek,
Did you have any chance to look at this patch version ?
I hope to review it this weekend. I might go ahead and implement the DOWN
logic independently if that is still an issue (saw your question, but didn't
yet look at how you dealt with it in the patch). We need that anyway for
manually UP/DOWN of networks.
-Original Message-
From: Rauta, Alin
Sent: Tuesday, February 17, 2015 12:07 PM
To: t...@jklm.no; lenn...@poettering.net; zbys...@in.waw.pl
Cc: systemd-devel@lists.freedesktop.org; Kinsella, Ray; Rauta, Alin
Subject: [PATCH v4] Added support for Uplink Failure Detection using
BindCarrier
---
man/systemd.network.xml | 11 +
src/libsystemd/sd-network/sd-network.c | 8 +
src/network/networkctl.c | 43 ++--
src/network/networkd-link.c | 394
+--
src/network/networkd-link.h | 3 +
src/network/networkd-network-gperf.gperf | 1 +
src/network/networkd-network.c | 1 +
src/network/networkd.h | 2 +-
src/systemd/sd-network.h | 6 +
9 files changed, 438 insertions(+), 31 deletions(-)
diff --git a/man/systemd.network.xml b/man/systemd.network.xml index
485876b..60252e5 100644
--- a/man/systemd.network.xml
+++ b/man/systemd.network.xml
@@ -280,6 +280,17 @@
/listitem
/varlistentry
varlistentry
+ termvarnameBindCarrier=/varname/term
+ listitem
+paraA port or a list of ports. When set, controls the
+behaviour of the current interface. When all ports in the list
+are in an operational down state, the current interface is
brought
+down. When at least one port has carrier, the current interface
+is brought up.
+/para
+ /listitem
+/varlistentry
+varlistentry
termvarnameAddress=/varname/term
listitem
paraA static IPv4 or IPv6 address and its prefix
length, diff --git a/src/libsystemd/sd-network/sd-network.c
b/src/libsystemd/sd-network/sd-network.c
index c4713fe..fb5152c 100644
--- a/src/libsystemd/sd-network/sd-network.c
+++ b/src/libsystemd/sd-network/sd-network.c
@@ -264,6 +264,14 @@ _public_ int sd_network_link_get_domains(int ifindex,
char ***ret) {
return network_get_link_strv(DOMAINS, ifindex, ret); }
+_public_ int sd_network_link_get_carrier_bound_to(int ifindex, char ***ret)
{
+return network_get_link_strv(CARRIER_BOUND_TO, ifindex,
+ret); }
+
+_public_ int sd_network_link_get_carrier_bound_by(int ifindex, char ***ret)
{
+return network_get_link_strv(CARRIER_BOUND_BY, ifindex,
+ret); }
+
_public_ int sd_network_link_get_wildcard_domain(int ifindex) {
int r;
_cleanup_free_ char *p = NULL, *s = NULL; diff --git
a/src/network/networkctl.c b/src/network/networkctl.c index
aa83f32..0637513 100644
--- a/src/network/networkctl.c
+++ b/src/network/networkctl.c
@@ -508,6 +508,8 @@ static int link_status_one(
const char *driver = NULL, *path = NULL, *vendor = NULL, *model =
NULL, *link
Re: [systemd-devel] [PATCH v4] Added support for Uplink Failure Detection using BindCarrier
Can we please draw a conclusion in this case ?
Regards,
Alin
-Original Message-
From: systemd-devel [mailto:systemd-devel-boun...@lists.freedesktop.org] On
Behalf Of Rauta, Alin
Sent: Friday, February 20, 2015 10:37 AM
To: Tom Gundersen
Cc: Kinsella, Ray; systemd-devel@lists.freedesktop.org
Subject: Re: [systemd-devel] [PATCH v4] Added support for Uplink Failure
Detection using BindCarrier
Hi Tom,
Thank you. Please let me know if you have any questions regarding the
implementation.
We can have another patch for the DOWN logic. It's a little bit complicated
since we don't have UP either and since during UP operation we don't know the
previous port state so that we get back to it.
Best Regards,
Alin
-Original Message-
From: Tom Gundersen [mailto:t...@jklm.no]
Sent: Friday, February 20, 2015 10:27 AM
To: Rauta, Alin
Cc: lenn...@poettering.net; zbys...@in.waw.pl;
systemd-devel@lists.freedesktop.org; Kinsella, Ray
Subject: Re: [PATCH v4] Added support for Uplink Failure Detection using
BindCarrier
On Fri, Feb 20, 2015 at 10:50 AM, Rauta, Alin alin.ra...@intel.com wrote:
Hi Tom, Lennart, Zbyszek,
Did you have any chance to look at this patch version ?
I hope to review it this weekend. I might go ahead and implement the DOWN logic
independently if that is still an issue (saw your question, but didn't yet look
at how you dealt with it in the patch). We need that anyway for manually
UP/DOWN of networks.
-Original Message-
From: Rauta, Alin
Sent: Tuesday, February 17, 2015 12:07 PM
To: t...@jklm.no; lenn...@poettering.net; zbys...@in.waw.pl
Cc: systemd-devel@lists.freedesktop.org; Kinsella, Ray; Rauta, Alin
Subject: [PATCH v4] Added support for Uplink Failure Detection using
BindCarrier
---
man/systemd.network.xml | 11 +
src/libsystemd/sd-network/sd-network.c | 8 +
src/network/networkctl.c | 43 ++--
src/network/networkd-link.c | 394
+--
src/network/networkd-link.h | 3 +
src/network/networkd-network-gperf.gperf | 1 +
src/network/networkd-network.c | 1 +
src/network/networkd.h | 2 +-
src/systemd/sd-network.h | 6 +
9 files changed, 438 insertions(+), 31 deletions(-)
diff --git a/man/systemd.network.xml b/man/systemd.network.xml index
485876b..60252e5 100644
--- a/man/systemd.network.xml
+++ b/man/systemd.network.xml
@@ -280,6 +280,17 @@
/listitem
/varlistentry
varlistentry
+ termvarnameBindCarrier=/varname/term
+ listitem
+paraA port or a list of ports. When set, controls the
+behaviour of the current interface. When all ports in the list
+are in an operational down state, the current interface is
brought
+down. When at least one port has carrier, the current interface
+is brought up.
+/para
+ /listitem
+/varlistentry
+varlistentry
termvarnameAddress=/varname/term
listitem
paraA static IPv4 or IPv6 address and its prefix
length, diff --git a/src/libsystemd/sd-network/sd-network.c
b/src/libsystemd/sd-network/sd-network.c
index c4713fe..fb5152c 100644
--- a/src/libsystemd/sd-network/sd-network.c
+++ b/src/libsystemd/sd-network/sd-network.c
@@ -264,6 +264,14 @@ _public_ int sd_network_link_get_domains(int ifindex,
char ***ret) {
return network_get_link_strv(DOMAINS, ifindex, ret); }
+_public_ int sd_network_link_get_carrier_bound_to(int ifindex, char ***ret) {
+return network_get_link_strv(CARRIER_BOUND_TO, ifindex,
+ret); }
+
+_public_ int sd_network_link_get_carrier_bound_by(int ifindex, char ***ret) {
+return network_get_link_strv(CARRIER_BOUND_BY, ifindex,
+ret); }
+
_public_ int sd_network_link_get_wildcard_domain(int ifindex) {
int r;
_cleanup_free_ char *p = NULL, *s = NULL; diff --git
a/src/network/networkctl.c b/src/network/networkctl.c index
aa83f32..0637513 100644
--- a/src/network/networkctl.c
+++ b/src/network/networkctl.c
@@ -508,6 +508,8 @@ static int link_status_one(
const char *driver = NULL, *path = NULL, *vendor = NULL, *model =
NULL, *link = NULL;
const char *on_color_operational, *off_color_operational,
*on_color_setup, *off_color_setup;
+_cleanup_strv_free_ char **carrier_bound_to = NULL;
+_cleanup_strv_free_ char **carrier_bound_by = NULL;
struct ether_addr e;
unsigned iftype;
int r, ifindex;
@@ -606,12 +608,15 @@ static int link_status_one(
sd_network_link_get_network_file(ifindex, network);
+sd_network_link_get_carrier_bound_to(ifindex, carrier_bound_to);
+sd_network_link_get_carrier_bound_by(ifindex,
+ carrier_bound_by);
+
printf(%s%s%s %i: %s\n, on_color_operational
Re: [systemd-devel] [PATCH v4] Added support for Uplink Failure Detection using BindCarrier
Hi Tom,
Thank you. Please let me know if you have any questions regarding the
implementation.
We can have another patch for the DOWN logic. It's a little bit complicated
since we don't have UP either and since during UP operation we don't know the
previous port state so that we get back to it.
Best Regards,
Alin
-Original Message-
From: Tom Gundersen [mailto:t...@jklm.no]
Sent: Friday, February 20, 2015 10:27 AM
To: Rauta, Alin
Cc: lenn...@poettering.net; zbys...@in.waw.pl;
systemd-devel@lists.freedesktop.org; Kinsella, Ray
Subject: Re: [PATCH v4] Added support for Uplink Failure Detection using
BindCarrier
On Fri, Feb 20, 2015 at 10:50 AM, Rauta, Alin alin.ra...@intel.com wrote:
Hi Tom, Lennart, Zbyszek,
Did you have any chance to look at this patch version ?
I hope to review it this weekend. I might go ahead and implement the DOWN logic
independently if that is still an issue (saw your question, but didn't yet look
at how you dealt with it in the patch). We need that anyway for manually
UP/DOWN of networks.
-Original Message-
From: Rauta, Alin
Sent: Tuesday, February 17, 2015 12:07 PM
To: t...@jklm.no; lenn...@poettering.net; zbys...@in.waw.pl
Cc: systemd-devel@lists.freedesktop.org; Kinsella, Ray; Rauta, Alin
Subject: [PATCH v4] Added support for Uplink Failure Detection using
BindCarrier
---
man/systemd.network.xml | 11 +
src/libsystemd/sd-network/sd-network.c | 8 +
src/network/networkctl.c | 43 ++--
src/network/networkd-link.c | 394
+--
src/network/networkd-link.h | 3 +
src/network/networkd-network-gperf.gperf | 1 +
src/network/networkd-network.c | 1 +
src/network/networkd.h | 2 +-
src/systemd/sd-network.h | 6 +
9 files changed, 438 insertions(+), 31 deletions(-)
diff --git a/man/systemd.network.xml b/man/systemd.network.xml index
485876b..60252e5 100644
--- a/man/systemd.network.xml
+++ b/man/systemd.network.xml
@@ -280,6 +280,17 @@
/listitem
/varlistentry
varlistentry
+ termvarnameBindCarrier=/varname/term
+ listitem
+paraA port or a list of ports. When set, controls the
+behaviour of the current interface. When all ports in the list
+are in an operational down state, the current interface is
brought
+down. When at least one port has carrier, the current interface
+is brought up.
+/para
+ /listitem
+/varlistentry
+varlistentry
termvarnameAddress=/varname/term
listitem
paraA static IPv4 or IPv6 address and its prefix
length, diff --git a/src/libsystemd/sd-network/sd-network.c
b/src/libsystemd/sd-network/sd-network.c
index c4713fe..fb5152c 100644
--- a/src/libsystemd/sd-network/sd-network.c
+++ b/src/libsystemd/sd-network/sd-network.c
@@ -264,6 +264,14 @@ _public_ int sd_network_link_get_domains(int ifindex,
char ***ret) {
return network_get_link_strv(DOMAINS, ifindex, ret); }
+_public_ int sd_network_link_get_carrier_bound_to(int ifindex, char ***ret) {
+return network_get_link_strv(CARRIER_BOUND_TO, ifindex,
+ret); }
+
+_public_ int sd_network_link_get_carrier_bound_by(int ifindex, char ***ret) {
+return network_get_link_strv(CARRIER_BOUND_BY, ifindex,
+ret); }
+
_public_ int sd_network_link_get_wildcard_domain(int ifindex) {
int r;
_cleanup_free_ char *p = NULL, *s = NULL; diff --git
a/src/network/networkctl.c b/src/network/networkctl.c index
aa83f32..0637513 100644
--- a/src/network/networkctl.c
+++ b/src/network/networkctl.c
@@ -508,6 +508,8 @@ static int link_status_one(
const char *driver = NULL, *path = NULL, *vendor = NULL, *model =
NULL, *link = NULL;
const char *on_color_operational, *off_color_operational,
*on_color_setup, *off_color_setup;
+_cleanup_strv_free_ char **carrier_bound_to = NULL;
+_cleanup_strv_free_ char **carrier_bound_by = NULL;
struct ether_addr e;
unsigned iftype;
int r, ifindex;
@@ -606,12 +608,15 @@ static int link_status_one(
sd_network_link_get_network_file(ifindex, network);
+sd_network_link_get_carrier_bound_to(ifindex, carrier_bound_to);
+sd_network_link_get_carrier_bound_by(ifindex,
+ carrier_bound_by);
+
printf(%s%s%s %i: %s\n, on_color_operational,
draw_special_char(DRAW_BLACK_CIRCLE), off_color_operational, ifindex,
name);
-printf( Link File: %s\n
- Network File: %s\n
- Type: %s\n
- State: %s%s%s (%s%s%s)\n,
+printf( Link File: %s\n
+ Network File: %s\n
+ Type: %s\n
+ State: %s%s%s (%s
Re: [systemd-devel] [PATCH v4] Added support for Uplink Failure Detection using BindCarrier
Hi Tom, Lennart, Zbyszek,
Did you have any chance to look at this patch version ?
Best Regards,
Alin
-Original Message-
From: Rauta, Alin
Sent: Tuesday, February 17, 2015 12:07 PM
To: t...@jklm.no; lenn...@poettering.net; zbys...@in.waw.pl
Cc: systemd-devel@lists.freedesktop.org; Kinsella, Ray; Rauta, Alin
Subject: [PATCH v4] Added support for Uplink Failure Detection using BindCarrier
---
man/systemd.network.xml | 11 +
src/libsystemd/sd-network/sd-network.c | 8 +
src/network/networkctl.c | 43 ++--
src/network/networkd-link.c | 394 +--
src/network/networkd-link.h | 3 +
src/network/networkd-network-gperf.gperf | 1 +
src/network/networkd-network.c | 1 +
src/network/networkd.h | 2 +-
src/systemd/sd-network.h | 6 +
9 files changed, 438 insertions(+), 31 deletions(-)
diff --git a/man/systemd.network.xml b/man/systemd.network.xml index
485876b..60252e5 100644
--- a/man/systemd.network.xml
+++ b/man/systemd.network.xml
@@ -280,6 +280,17 @@
/listitem
/varlistentry
varlistentry
+ termvarnameBindCarrier=/varname/term
+ listitem
+paraA port or a list of ports. When set, controls the
+behaviour of the current interface. When all ports in the list
+are in an operational down state, the current interface is brought
+down. When at least one port has carrier, the current interface
+is brought up.
+/para
+ /listitem
+/varlistentry
+varlistentry
termvarnameAddress=/varname/term
listitem
paraA static IPv4 or IPv6 address and its prefix length, diff
--git a/src/libsystemd/sd-network/sd-network.c
b/src/libsystemd/sd-network/sd-network.c
index c4713fe..fb5152c 100644
--- a/src/libsystemd/sd-network/sd-network.c
+++ b/src/libsystemd/sd-network/sd-network.c
@@ -264,6 +264,14 @@ _public_ int sd_network_link_get_domains(int ifindex, char
***ret) {
return network_get_link_strv(DOMAINS, ifindex, ret); }
+_public_ int sd_network_link_get_carrier_bound_to(int ifindex, char ***ret) {
+return network_get_link_strv(CARRIER_BOUND_TO, ifindex, ret);
+}
+
+_public_ int sd_network_link_get_carrier_bound_by(int ifindex, char ***ret) {
+return network_get_link_strv(CARRIER_BOUND_BY, ifindex, ret);
+}
+
_public_ int sd_network_link_get_wildcard_domain(int ifindex) {
int r;
_cleanup_free_ char *p = NULL, *s = NULL; diff --git
a/src/network/networkctl.c b/src/network/networkctl.c index aa83f32..0637513
100644
--- a/src/network/networkctl.c
+++ b/src/network/networkctl.c
@@ -508,6 +508,8 @@ static int link_status_one(
const char *driver = NULL, *path = NULL, *vendor = NULL, *model =
NULL, *link = NULL;
const char *on_color_operational, *off_color_operational,
*on_color_setup, *off_color_setup;
+_cleanup_strv_free_ char **carrier_bound_to = NULL;
+_cleanup_strv_free_ char **carrier_bound_by = NULL;
struct ether_addr e;
unsigned iftype;
int r, ifindex;
@@ -606,12 +608,15 @@ static int link_status_one(
sd_network_link_get_network_file(ifindex, network);
+sd_network_link_get_carrier_bound_to(ifindex, carrier_bound_to);
+sd_network_link_get_carrier_bound_by(ifindex,
+ carrier_bound_by);
+
printf(%s%s%s %i: %s\n, on_color_operational,
draw_special_char(DRAW_BLACK_CIRCLE), off_color_operational, ifindex, name);
-printf( Link File: %s\n
- Network File: %s\n
- Type: %s\n
- State: %s%s%s (%s%s%s)\n,
+printf( Link File: %s\n
+ Network File: %s\n
+ Type: %s\n
+ State: %s%s%s (%s%s%s)\n,
strna(link),
strna(network),
strna(t),
@@ -619,13 +624,13 @@ static int link_status_one(
on_color_setup, strna(setup_state), off_color_setup);
if (path)
-printf(Path: %s\n, path);
+printf(Path: %s\n, path);
if (driver)
-printf( Driver: %s\n, driver);
+printf( Driver: %s\n, driver);
if (vendor)
-printf( Vendor: %s\n, vendor);
+printf( Vendor: %s\n, vendor);
if (model)
-printf( Model: %s\n, model);
+printf( Model: %s\n, model);
if (have_mac) {
_cleanup_free_ char *description = NULL; @@ -634,23 +639,29 @@
static int link_status_one(
ieee_oui(hwdb, e, description);
if (description)
-printf( HW Address: %s (%s)\n,
ether_addr_to_string(e
Re: [systemd-devel] [PATCH v3] Added support for Uplink Failure Detection using BindCarrier
Hi Tom,
Regarding your request:
Hm, we need to introduce a new administrative state here I think
(LINK_STATE_DOWN), and then make sure we don't accidentally leave
it in case we get some other event after bringing the interface down.
This is a little bit tricky.
When we bring the link down it would be easy to change the state to
LINK_STATE_DOWN, but when we bring the port up I don’t know how to restore it
to the previous state unless I use an additional variable in the link structure
to retain the previous state of the port, but this will not look nice I think.
Would this be acceptable ?
Currently, when a link becomes down, it will have the operational state off.
See State: off (configured) below:
Would this suffice since however we don't have a corresponding LINK_STATE_UP
and from current behavior it seems acceptable to have the port down
(operational off) and configured.
# networkctl status sw0p3
● 5: sw0p3
Link File: /usr/lib/systemd/network/99-default.link
Network File: /etc/systemd/network/sw0p3.network
Type: ether
State: off (configured)
Driver: fm6k
MTU: 1500
Carrier Bound To: sw0p2
sw0p1
#
Best Regards,
Alin
-Original Message-
From: Zbigniew Jędrzejewski-Szmek [mailto:zbys...@in.waw.pl]
Sent: Saturday, February 14, 2015 3:34 PM
To: Rauta, Alin
Cc: Tom Gundersen; Lennart Poettering; systemd Mailing List; Kinsella, Ray
Subject: Re: [PATCH v3] Added support for Uplink Failure Detection using
BindCarrier
On Sat, Feb 14, 2015 at 03:26:00PM +, Rauta, Alin wrote:
Hi guys,
Thanks for your input on this. Much appreciated.
I'll try handle your remarks in the next patch.
Please find my comments below.
Best Regards,
Alin
-Original Message-
From: Tom Gundersen [mailto:t...@jklm.no]
Sent: Saturday, February 14, 2015 2:50 PM
To: Zbigniew Jędrzejewski-Szmek
Cc: Rauta, Alin; Lennart Poettering; systemd Mailing List; Kinsella,
Ray
Subject: Re: [PATCH v3] Added support for Uplink Failure Detection
using BindCarrier
On Sat, Feb 14, 2015 at 3:05 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
On Fri, Feb 13, 2015 at 10:27:07PM +0100, Tom Gundersen wrote:
Hi Alin,
Thanks for the patch. This is starting to look pretty good now.
I still have some questions/requests regarding some implementation
details (below), but hopefully we can get this merged after the
next release (trying to stabilize things at the moment).
On Tue, Feb 10, 2015 at 12:30 PM, Alin Rauta alin.ra...@intel.com wrote:
---
man/systemd.network.xml | 11 ++
src/libsystemd/sd-network/sd-network.c | 4 +
src/network/networkctl.c | 211
---
src/network/networkd-link.c | 123 +-
src/network/networkd-link.h | 1 +
src/network/networkd-manager.c | 7 +
src/network/networkd-network-gperf.gperf | 1 +
src/network/networkd-network.c | 10 ++
src/network/networkd.h | 2 +-
src/systemd/sd-network.h | 3 +
10 files changed, 355 insertions(+), 18 deletions(-)
diff --git a/man/systemd.network.xml b/man/systemd.network.xml
index 9b3a92d..8b2ca4e 100644
--- a/man/systemd.network.xml
+++ b/man/systemd.network.xml
@@ -270,6 +270,17 @@
/listitem
/varlistentry
varlistentry
+ termvarnameBindCarrier=/varname/term
+ listitem
+paraA port or a list of ports. When set, controls the
+behaviour of the current interface. When all ports in the
list
+are operational down, the failure is propagated to
+ the current
operational down does not follow normal grammar rules. are in an
operational down state?
+interface. When at least one port has carrier, the current
+interface is brought up.
+/para
Maybe we should make it clear that this is not necessarily a
failure (the uplink may be down on purpose), and that the way we
propagate it is to set the downlink administrative down.
Alin:
I will think of something else here. Some other way to describe this.
+ /listitem
+/varlistentry
+varlistentry
termvarnameAddress=/varname/term
listitem
paraA static IPv4 or IPv6 address and its prefix
length, diff --git a/src/libsystemd/sd-network/sd-network.c
b/src/libsystemd/sd-network/sd-network.c
index c735cac..b574d19 100644
--- a/src/libsystemd/sd-network/sd-network.c
+++ b/src/libsystemd/sd-network/sd-network.c
@@ -264,6 +264,10 @@ _public_ int sd_network_link_get_domains(int
ifindex, char ***ret) {
return network_get_link_strv(DOMAINS, ifindex, ret);
}
+_public_ int
Re: [systemd-devel] [PATCH v3] Added support for Uplink Failure Detection using BindCarrier
Hi guys,
Thanks for your input on this. Much appreciated.
I'll try handle your remarks in the next patch.
Please find my comments below.
Best Regards,
Alin
-Original Message-
From: Tom Gundersen [mailto:t...@jklm.no]
Sent: Saturday, February 14, 2015 2:50 PM
To: Zbigniew Jędrzejewski-Szmek
Cc: Rauta, Alin; Lennart Poettering; systemd Mailing List; Kinsella, Ray
Subject: Re: [PATCH v3] Added support for Uplink Failure Detection using
BindCarrier
On Sat, Feb 14, 2015 at 3:05 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
On Fri, Feb 13, 2015 at 10:27:07PM +0100, Tom Gundersen wrote:
Hi Alin,
Thanks for the patch. This is starting to look pretty good now.
I still have some questions/requests regarding some implementation
details (below), but hopefully we can get this merged after the next
release (trying to stabilize things at the moment).
On Tue, Feb 10, 2015 at 12:30 PM, Alin Rauta alin.ra...@intel.com wrote:
---
man/systemd.network.xml | 11 ++
src/libsystemd/sd-network/sd-network.c | 4 +
src/network/networkctl.c | 211
---
src/network/networkd-link.c | 123 +-
src/network/networkd-link.h | 1 +
src/network/networkd-manager.c | 7 +
src/network/networkd-network-gperf.gperf | 1 +
src/network/networkd-network.c | 10 ++
src/network/networkd.h | 2 +-
src/systemd/sd-network.h | 3 +
10 files changed, 355 insertions(+), 18 deletions(-)
diff --git a/man/systemd.network.xml b/man/systemd.network.xml
index 9b3a92d..8b2ca4e 100644
--- a/man/systemd.network.xml
+++ b/man/systemd.network.xml
@@ -270,6 +270,17 @@
/listitem
/varlistentry
varlistentry
+ termvarnameBindCarrier=/varname/term
+ listitem
+paraA port or a list of ports. When set, controls the
+behaviour of the current interface. When all ports in the list
+are operational down, the failure is propagated to the
+ current
operational down does not follow normal grammar rules. are in an
operational down state?
+interface. When at least one port has carrier, the current
+interface is brought up.
+/para
Maybe we should make it clear that this is not necessarily a failure
(the uplink may be down on purpose), and that the way we propagate it
is to set the downlink administrative down.
Alin:
I will think of something else here. Some other way to describe this.
+ /listitem
+/varlistentry
+varlistentry
termvarnameAddress=/varname/term
listitem
paraA static IPv4 or IPv6 address and its prefix
length, diff --git a/src/libsystemd/sd-network/sd-network.c
b/src/libsystemd/sd-network/sd-network.c
index c735cac..b574d19 100644
--- a/src/libsystemd/sd-network/sd-network.c
+++ b/src/libsystemd/sd-network/sd-network.c
@@ -264,6 +264,10 @@ _public_ int sd_network_link_get_domains(int ifindex,
char ***ret) {
return network_get_link_strv(DOMAINS, ifindex, ret); }
+_public_ int sd_network_link_get_carriers(int ifindex, char ***ret) {
+return network_get_link_strv(CARRIERS, ifindex, ret); }
I don't find get_carriers() very clear. At least call it
get_carrier_bound_to() or something like that. I must say I agree
with Lennart and Zbigniew, we should introduce the API in both
directions, and then we can worry about the performance if that turns
out to be a problem (worst case all the processing could be hidden in
the sd-network library, but I don't think that will be necessary to
be honest).
Alin:
I will change the name and provide functions in both directions.
_public_ int sd_network_link_get_wildcard_domain(int ifindex) {
int r;
_cleanup_free_ char *p = NULL, *s = NULL; diff --git
a/src/network/networkctl.c b/src/network/networkctl.c index
aa83f32..ffb38e8 100644
--- a/src/network/networkctl.c
+++ b/src/network/networkctl.c
@@ -22,6 +22,7 @@
#include stdbool.h
#include getopt.h
#include net/if.h
+#include fnmatch.h
#include sd-network.h
#include sd-rtnl.h
@@ -393,6 +394,161 @@ static int get_gateway_description(
return -ENODATA;
}
+static bool is_carrier(const char *ifname,
+ char **carriers) {
+ char **i;
+
+ STRV_FOREACH(i, carriers)
+ if (fnmatch(*i, ifname, 0) == 0)
+ return true;
+
+ return false;
+}
+
+/* get the links that are bound to this port. */ static int
+get_downlinks(const char *name,
+ sd_rtnl_message *m,
+ LinkInfo **downlinks,
+ int *down_count
Re: [systemd-devel] [PATCH v3] Added support for Uplink Failure Detection using BindCarrier
Hi Tom,
Any news on this ?
Best Regards,
Alin
-Original Message-
From: Lennart Poettering [mailto:lenn...@poettering.net]
Sent: Wednesday, February 11, 2015 6:03 PM
To: Rauta, Alin
Cc: zbys...@in.waw.pl; t...@jklm.no; systemd-devel@lists.freedesktop.org;
Kinsella, Ray
Subject: Re: [PATCH v3] Added support for Uplink Failure Detection using
BindCarrier
On Wed, 11.02.15 17:44, Rauta, Alin (alin.ra...@intel.com) wrote:
Hi Lennart,
+_public_ int sd_network_link_get_carriers(int ifindex, char ***ret) {
+return network_get_link_strv(CARRIERS, ifindex, ret); }
+
I think it would be better to have two calls here:
int sd_network_link_get_carrier_bound_to(int ifindex, int **others);
int sd_network_link_get_carrier_bound_by(int ifindex, int
**others);
In terms of functionality, sd_network_link_get_carriers is
actually sd_network_link_get_carrier_bound_to and is applicable to
bound to links just like BindCarrier= is available only for bound
to links. I wanted to save to systemd run files just minimum info.
If I add sd_network_link_get_carrier_bound_by, then each time
link_save is called for a link I should query BindCarrier=s for
all interfaces to print each link that bounds the current interface.
Then, if I rename a link I should call link_save for all available
links because the BindCarrier= can be interpreted in another way due
to wildcards.
Well, one option could be to keep a set of bound_by and bound_to links around
for each link, and then just update that each time an interface comes, goes, or
changes names. That way you always have direct access to the bound links, and
don't have to resolve the globs each time you need them, but only when they
actually change?
The reason why I figured having two calls for this would be useful is simply to
make it easy to write tools like networkctl, which wants to show this
information in both directions for each interface...
+/* get the links that are bound to this port. */ static int
+get_downlinks(const char *name,
+ sd_rtnl_message *m,
+ LinkInfo **downlinks,
+ int *down_count) {
Regarding get_uplinks and get_downlinks I can rename them to
get_links_bound_to and get_links_bound_by. Would this be fine ?
Sure!
But before you rework any of this, let's see what Tom has to say, he's the
networkd maintainer...
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 v3] Added support for Uplink Failure Detection using BindCarrier
Well, one option could be to keep a set of bound_by and bound_to links
around for each link, and then just update that each time an interface
comes, goes, or changes names.
Yes, but the updates need to be done for all links and I'm not sure adding this
is a good thing.
I'm now having 64 links on the switch and I need the failure detection in
networkd to be quite fast because however even now it's probably slower due to
evaluating dynamically the BindCarrier strings when comparing this with the
previous solution with an UFD group monitoring some interfaces and with some
internal counters knowing exactly when to issue link_down for an interface.
So adding bound_by and bound_to makes the solution even slower.
Besides this, having only one function sd_network_link_get_carrier_bound_to
makes also sense because only the behavior of bond_to links is controlled by
this feature. bound_by means almost nothing for an interface. A tool like
networkctl may take into account to display only the bound_to links because
that's what's relevant. The fact that networkctl displays both bound_to and
bound_by it's a good thing, but it doesn't mean each tool should do that.
/Alin
-Original Message-
From: Lennart Poettering [mailto:lenn...@poettering.net]
Sent: Wednesday, February 11, 2015 6:03 PM
To: Rauta, Alin
Cc: zbys...@in.waw.pl; t...@jklm.no; systemd-devel@lists.freedesktop.org;
Kinsella, Ray
Subject: Re: [PATCH v3] Added support for Uplink Failure Detection using
BindCarrier
On Wed, 11.02.15 17:44, Rauta, Alin (alin.ra...@intel.com) wrote:
Hi Lennart,
+_public_ int sd_network_link_get_carriers(int ifindex, char ***ret) {
+return network_get_link_strv(CARRIERS, ifindex, ret); }
+
I think it would be better to have two calls here:
int sd_network_link_get_carrier_bound_to(int ifindex, int **others);
int sd_network_link_get_carrier_bound_by(int ifindex, int
**others);
In terms of functionality, sd_network_link_get_carriers is
actually sd_network_link_get_carrier_bound_to and is applicable to
bound to links just like BindCarrier= is available only for bound
to links. I wanted to save to systemd run files just minimum info.
If I add sd_network_link_get_carrier_bound_by, then each time
link_save is called for a link I should query BindCarrier=s for
all interfaces to print each link that bounds the current interface.
Then, if I rename a link I should call link_save for all available
links because the BindCarrier= can be interpreted in another way due
to wildcards.
Well, one option could be to keep a set of bound_by and bound_to links around
for each link, and then just update that each time an interface comes, goes, or
changes names. That way you always have direct access to the bound links, and
don't have to resolve the globs each time you need them, but only when they
actually change?
The reason why I figured having two calls for this would be useful is simply to
make it easy to write tools like networkctl, which wants to show this
information in both directions for each interface...
+/* get the links that are bound to this port. */ static int
+get_downlinks(const char *name,
+ sd_rtnl_message *m,
+ LinkInfo **downlinks,
+ int *down_count) {
Regarding get_uplinks and get_downlinks I can rename them to
get_links_bound_to and get_links_bound_by. Would this be fine ?
Sure!
But before you rework any of this, let's see what Tom has to say, he's the
networkd maintainer...
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 v3] Added support for Uplink Failure Detection using BindCarrier
Hi Lennart,
+_public_ int sd_network_link_get_carriers(int ifindex, char ***ret) {
+return network_get_link_strv(CARRIERS, ifindex, ret); }
+
I think it would be better to have two calls here:
int sd_network_link_get_carrier_bound_to(int ifindex, int **others);
int sd_network_link_get_carrier_bound_by(int ifindex, int **others);
In terms of functionality, sd_network_link_get_carriers is actually
sd_network_link_get_carrier_bound_to and is applicable to bound to links
just like BindCarrier= is available only for bound to links. I wanted to
save to systemd run files just minimum info.
If I add sd_network_link_get_carrier_bound_by, then each time link_save is
called for a link I should query BindCarrier=s for all interfaces to print
each link that bounds the current interface.
Then, if I rename a link I should call link_save for all available links
because the BindCarrier= can be interpreted in another way due to wildcards.
I would prefer using only one function and change the name as you suggested
sd_network_link_get_carrier_bound_to. Do you agree ?
+/* get the links that are bound to this port. */ static int
+get_downlinks(const char *name,
+ sd_rtnl_message *m,
+ LinkInfo **downlinks,
+ int *down_count) {
Regarding get_uplinks and get_downlinks I can rename them to
get_links_bound_to and get_links_bound_by. Would this be fine ?
Best Regards,
Alin
-Original Message-
From: Lennart Poettering [mailto:lenn...@poettering.net]
Sent: Wednesday, February 11, 2015 4:54 PM
To: Rauta, Alin
Cc: zbys...@in.waw.pl; t...@jklm.no; systemd-devel@lists.freedesktop.org;
Kinsella, Ray
Subject: Re: [PATCH v3] Added support for Uplink Failure Detection using
BindCarrier
On Tue, 10.02.15 03:30, Alin Rauta (alin.ra...@intel.com) wrote:
---
man/systemd.network.xml | 11 ++
src/libsystemd/sd-network/sd-network.c | 4 +
src/network/networkctl.c | 211
---
src/network/networkd-link.c | 123 +-
src/network/networkd-link.h | 1 +
src/network/networkd-manager.c | 7 +
src/network/networkd-network-gperf.gperf | 1 +
src/network/networkd-network.c | 10 ++
src/network/networkd.h | 2 +-
src/systemd/sd-network.h | 3 +
10 files changed, 355 insertions(+), 18 deletions(-)
diff --git a/man/systemd.network.xml b/man/systemd.network.xml index
9b3a92d..8b2ca4e 100644
--- a/man/systemd.network.xml
+++ b/man/systemd.network.xml
@@ -270,6 +270,17 @@
/listitem
/varlistentry
varlistentry
+ termvarnameBindCarrier=/varname/term
+ listitem
+paraA port or a list of ports. When set, controls the
+behaviour of the current interface. When all ports in the list
+are operational down, the failure is propagated to the current
+interface. When at least one port has carrier, the current
+interface is brought up.
+/para
+ /listitem
+/varlistentry
+varlistentry
termvarnameAddress=/varname/term
listitem
paraA static IPv4 or IPv6 address and its prefix
length, diff --git a/src/libsystemd/sd-network/sd-network.c
b/src/libsystemd/sd-network/sd-network.c
index c735cac..b574d19 100644
--- a/src/libsystemd/sd-network/sd-network.c
+++ b/src/libsystemd/sd-network/sd-network.c
@@ -264,6 +264,10 @@ _public_ int sd_network_link_get_domains(int ifindex,
char ***ret) {
return network_get_link_strv(DOMAINS, ifindex, ret); }
+_public_ int sd_network_link_get_carriers(int ifindex, char ***ret) {
+return network_get_link_strv(CARRIERS, ifindex, ret); }
+
I think it would be better to have two calls here:
int sd_network_link_get_carrier_bound_to(int ifindex, int **others);
int sd_network_link_get_carrier_bound_by(int ifindex, int **others);
This would then allow querying the list of interfaces currently bound to the
carrier of the interface you specify, as well as the list of interfaces the
network currently applied to the interface you specify is bound to.
+/* get the links that are bound to this port. */ static int
+get_downlinks(const char *name,
+ sd_rtnl_message *m,
+ LinkInfo **downlinks,
+ int *down_count) {
Hmm, maybe we should agree on one nomenclature here.
So far I kinda preferred calling these things bound by and bound to. I
figure the terms downlinks and uplink are common too. We should really
stick to one set of terms here. I personally find bound by and bound to
more descriptive I must say.
I'll leave the rest to Tom.
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel
Re: [systemd-devel] [PATCH] Added UFD (Uplink failure detection) support to networkd
Yes, since the concept of UFD group is not exposed. /Alin -Original Message- From: Lennart Poettering [mailto:lenn...@poettering.net] Sent: Monday, February 2, 2015 5:24 PM To: Rauta, Alin Cc: Andrei Borzenkov; Tom Gundersen; Kinsella, Ray; systemd Mailing List Subject: Re: [systemd-devel] [PATCH] Added UFD (Uplink failure detection) support to networkd On Thu, 29.01.15 11:20, Rauta, Alin (alin.ra...@intel.com) wrote: heya, Regarding the networkctl update to show the UFD groups in a user friendly fashion, what about that ? Well, I am not particularly convinced we should expose the concept of an UFD group at all. However, I think it would make a ton of sense to show which interfaces are downlinks to an uplink interface, and which interface is an uplink for a downlink interface, all based on the relation expressed with BindCarrier=. # networkctl ufd 1 ● UFD Group: 1 State: configured Uplinks: → 12: sw0p10 Downlinks: → 51: sw0p49 → 53: sw0p51 → 7: sw0p5 → 9: sw0p7 For this example, I think networkctl should show: # networkctl status sw0p10 ... Carrier Bound By: sw0p49 sw0p51 sw0p5 sw0p7 ... # netwokctl status sw0p49 ... Carrier Bound To: sw0p10 ... If that makes sense? 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] Added UFD (Uplink failure detection) support to networkd
Hi Lennart, I agree that BindCarrier= should suffice. Best Regards, Alin -Original Message- From: Lennart Poettering [mailto:lenn...@poettering.net] Sent: Tuesday, February 3, 2015 10:50 AM To: Rauta, Alin Cc: Andrei Borzenkov; Tom Gundersen; Kinsella, Ray; systemd Mailing List Subject: Re: [systemd-devel] [PATCH] Added UFD (Uplink failure detection) support to networkd On Tue, 03.02.15 09:05, Rauta, Alin (alin.ra...@intel.com) wrote: Yes, since the concept of UFD group is not exposed. Does this mean we have agreement that the simply BindCarrier= option I proposed would be sufficient for your usecases? That would be great! 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] Added UFD (Uplink failure detection) support to networkd
Hi Lennart, I'll do some testing today with BindCarrier= and check if it covers all usecases. Regarding the networkctl update to show the UFD groups in a user friendly fashion, what about that ? Let's take a simple example. If I have a configuration file like below: #cat sw0p10.network [Match] Name=sw0p10 [Network] BindCarrier=sw0p49 sw0p51 sw0p5 sw0p7 In the background, networkd will create monitor an UFD group with ID, let's say 1. Then networkctl would give following output to the user: # networkctl ufd ● UFD Group: 1 # and # networkctl ufd 1 ● UFD Group: 1 State: configured Uplinks: → 12: sw0p10 Downlinks: → 51: sw0p49 → 53: sw0p51 → 7: sw0p5 → 9: sw0p7 # Of course networkd ufd -a would also work. How does it sound ? Best Regards, Alin -Original Message- From: Lennart Poettering [mailto:lenn...@poettering.net] Sent: Wednesday, January 28, 2015 6:59 PM To: Rauta, Alin Cc: Andrei Borzenkov; Tom Gundersen; Kinsella, Ray; systemd Mailing List Subject: Re: [systemd-devel] [PATCH] Added UFD (Uplink failure detection) support to networkd On Wed, 28.01.15 17:18, Rauta, Alin (alin.ra...@intel.com) wrote: Hi Lennart, Tom, We should also be able to add virtual devices to UFD groups, like Andrei mentioned in his email. In this case, do you think BindCarrier= and Tag= in .network files would still work ? Again, my latest proposal does away with the Tag= concept entirely. I am not sure what a virtual device is supposed to be. If it has a linux network interface, then it has a name and all I am saying is that with a simple Concept like BindCarrier= taking a list of globs of interface names I think that you can cover what you need. If we think about LAG (link aggregation) and if I am right, it's mapped to the kernel as a virtual device and contains multiple links. This way, it makes sense to have groups of links as netdevs. The only difference in case of UFD is that is not mapped to the kernel, but it's mapped inside networkd. I networkd, there are: 1) network interfaces created automatically by some kernel driver, because the hardware was discovered. To these we apply one .link file via udev, plus maybe a .network file, when we actually use it to connect to a network. 2) network interfaces that have to be created explicitly, via some kernel API. These are configured via .netdev files. From the point on they are created by networkd they are like any other network interface, i.e. exactly like the ones described in #1, i.e. on top of the .netdev file a .link file is then applied, and finally maybe a .network file. Now, all I am saying is that i think it would suffice if the .network files for the downlinks for contain BindCarrier= globs referring to their respective uplinks. And that should already suffice. TO make this work nciely all that is necessary then is that the network interfaces get pretty names, either right from the .netdev, or from the .link files. Another thing is that maybe later on we want to provide some properties for an UFD group, maybe to change to way we consider an uplink as failing. This would be easy if we have a netdev for the UFD group. Also, defining a netdev, we don't lose the identity of the feature nor we mask it. But this could also be another setting of the .network file of that is applied to the downlink. Example: in the .network file of the downlink we could have: BindCarrier=foo[1-7] BindCarrierMode=need-all Or so, which could mean: bring the downlink up only if there's a carrier on all network interfaces that match the glob foo[1-7]. The default for BindCarrierMode= would be need-any or so, which would mean, that the carrier is propagated when at least one of the network interfaces has a carrier. Wouldn't that cover your usecase? 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] Added UFD (Uplink failure detection) support to networkd
Hi Andrei, Please find my answers below: How do you distinguish between groups? By interface list in BindCarrier statement? Yes, first list of BindCarriers will represent the uplinks for group ID 1; Second different list of BindCarriers wiil represent the uplinks for group ID 2. And one more thing to mention: you should not have a link that is part of 2 UFD groups. How can it be in unconfigured state? This looks redundant and confusing in this case. Either there is BindCarrier and group, or there is no BindCarrier and hence no group. It can be only in configured state. That's right. It tells the user the group is configured, because maybe someone list the groups in the system and is wondering: is this group configured ? However, I don't mind if we take the line out. Best Regards, Alin -Original Message- From: Andrei Borzenkov [mailto:arvidj...@gmail.com] Sent: Thursday, January 29, 2015 12:14 PM To: Rauta, Alin Cc: Lennart Poettering; Tom Gundersen; Kinsella, Ray; systemd Mailing List Subject: Re: [systemd-devel] [PATCH] Added UFD (Uplink failure detection) support to networkd On Thu, Jan 29, 2015 at 2:20 PM, Rauta, Alin alin.ra...@intel.com wrote: Hi Lennart, I'll do some testing today with BindCarrier= and check if it covers all usecases. Regarding the networkctl update to show the UFD groups in a user friendly fashion, what about that ? Let's take a simple example. If I have a configuration file like below: #cat sw0p10.network [Match] Name=sw0p10 [Network] BindCarrier=sw0p49 sw0p51 sw0p5 sw0p7 In the background, networkd will create monitor an UFD group with ID, let's say 1. Then networkctl would give following output to the user: # networkctl ufd ● UFD Group: 1 How do you distinguish between groups? By interface list in BindCarrier statement? # and # networkctl ufd 1 ● UFD Group: 1 State: configured How can it be in unconfigured state? This looks redundant and confusing in this case. Either there is BindCarrier and group, or there is no BindCarrier and hence no group. Uplinks: → 12: sw0p10 Downlinks: → 51: sw0p49 → 53: sw0p51 → 7: sw0p5 → 9: sw0p7 # Of course networkd ufd -a would also work. How does it sound ? Best Regards, Alin -Original Message- From: Lennart Poettering [mailto:lenn...@poettering.net] Sent: Wednesday, January 28, 2015 6:59 PM To: Rauta, Alin Cc: Andrei Borzenkov; Tom Gundersen; Kinsella, Ray; systemd Mailing List Subject: Re: [systemd-devel] [PATCH] Added UFD (Uplink failure detection) support to networkd On Wed, 28.01.15 17:18, Rauta, Alin (alin.ra...@intel.com) wrote: Hi Lennart, Tom, We should also be able to add virtual devices to UFD groups, like Andrei mentioned in his email. In this case, do you think BindCarrier= and Tag= in .network files would still work ? Again, my latest proposal does away with the Tag= concept entirely. I am not sure what a virtual device is supposed to be. If it has a linux network interface, then it has a name and all I am saying is that with a simple Concept like BindCarrier= taking a list of globs of interface names I think that you can cover what you need. If we think about LAG (link aggregation) and if I am right, it's mapped to the kernel as a virtual device and contains multiple links. This way, it makes sense to have groups of links as netdevs. The only difference in case of UFD is that is not mapped to the kernel, but it's mapped inside networkd. I networkd, there are: 1) network interfaces created automatically by some kernel driver, because the hardware was discovered. To these we apply one .link file via udev, plus maybe a .network file, when we actually use it to connect to a network. 2) network interfaces that have to be created explicitly, via some kernel API. These are configured via .netdev files. From the point on they are created by networkd they are like any other network interface, i.e. exactly like the ones described in #1, i.e. on top of the .netdev file a .link file is then applied, and finally maybe a .network file. Now, all I am saying is that i think it would suffice if the .network files for the downlinks for contain BindCarrier= globs referring to their respective uplinks. And that should already suffice. TO make this work nciely all that is necessary then is that the network interfaces get pretty names, either right from the .netdev, or from the .link files. Another thing is that maybe later on we want to provide some properties for an UFD group, maybe to change to way we consider an uplink as failing. This would be easy if we have a netdev for the UFD group. Also, defining a netdev, we don't lose the identity of the feature nor we mask it. But this could also be another setting of the .network file of that is applied to the downlink. Example: in the .network file
Re: [systemd-devel] [PATCH] Added UFD (Uplink failure detection) support to networkd
What if we don't use the * for now and document BindCarrier accordingly to be a list of port names and no wildcard ? Then, if it's the case we can add such * support for BindCarrier and think about all those corner cases ? /Alin -Original Message- From: Andrei Borzenkov [mailto:arvidj...@gmail.com] Sent: Thursday, January 29, 2015 12:20 PM To: Lennart Poettering Cc: Rauta, Alin; Kinsella, Ray; systemd Mailing List Subject: Re: [systemd-devel] [PATCH] Added UFD (Uplink failure detection) support to networkd On Wed, Jan 28, 2015 at 3:40 PM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 28.01.15 10:13, Rauta, Alin (alin.ra...@intel.com) wrote: Lennart, on a switch I should be able to configure more than one UFD group. What precisely does this mean? WOuld those groups be orthogonal? I really would like to avoid introdcuing the tags concept for now. Would a solution where you give the uplinks appropriate names (like uplink0, uplinkXYZ, uplink_waldo and so on) suffice, when you can then refer to them in a .network file you apply to the downlinks as BindCarrier=uplink*? This has interesting corner case. Let's say you have one interface uplink0 and one interface downstream0 that has BindCarrier=uplink*. So we bind downstream0 to uplink0 on startup. Later (online) we add second interface uplink1 and downstream1 which also has BindCarrier=uplink*. But now this one is suddenly bound to *two* interfaces instead of one; so they both behave differently. Could also happen if interface fails on startup and is hotswaped or otherwise repaired replaced later. As such concept of uplink group abstracts away direct connection between down- and upstream. Each operation would then implicitly iterate over interfaces in group; when new interface is added, it provides natural place to adjust group monitoring (like set watch for it etc). Not so easy with your proposal. BindCarrier= would take a list of interface names, possibly with globs. If you want to up and down a link foo if at least one of the links bar, quux, piep, miau1, miau2 are up, you could write this as BindCarrier=bar quux piep miau*. What would introducing the tag concept give you beyond this very simple schreme described above? 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] Added UFD (Uplink failure detection) support to networkd
Hi Tom, Lennart, Thanks for the answers. The UFD is not only about configuration. It's about run-time monitoring of interfaces. The Uplink failure detection daemon listens for RTM_NEWLINK and RTM_DELLINK events from kernel the same way networkd manager listens. Then by run-time monitoring the uplinks, the daemon controls the downlinks. When all uplinks are down, the failure is propagated to the downlinks (the interfaces are brought down). When at least one uplink has carrier, the downlinks are brought up. Due to monitoring functionality, I think I should bind the interfaces to something, for example to a netdev. It's not mapped to the kernel, but it's mapped to systemd internally. Then for uplinks, I should use Tag= in the .network files and for downlinks BindCarrier=. So, an implementation according to your comments would look like: For the netdev: [NetDev] Name=ufd1 Kind=tag [Tag] Id=45 For an uplink mapped to ufd1, I'll need to add in the .network file: [Network] Tag=ufd1 For a downlink mapped to ufd1, I'll need to add in the .network file: [Network] BindCarrier=ufd1 Am I right or do I miss something ? Still the configuration of the group is spread through different files which makes it heavier to read and create. To comment on Holger's email about BFD, UFD and BFD can coexist on switches, I've checked some release notes on internet. Moreover, BFD is a layer 3 feature (protocol). Could you comment a bit on how you decide when an uplink should be considered failed? Is it jut when it does not have a carrier? Is this the end of the story, or do you imagine extending this with other notions in the future? A link is considered failed when it's operational down (has no carrier) or it's admin down (interface down). About future extensions, I don't know about any plans right now, but you never know. Maybe someone else will want to add something more. Lennart, on a switch I should be able to configure more than one UFD group. This being said and also due to the monitoring functionality of the UFD daemon, do you still think we can use only BindCarrier= ? Please let me know what you think. Best Regards, Alin -Original Message- From: Lennart Poettering [mailto:lenn...@poettering.net] Sent: Tuesday, January 27, 2015 9:26 PM To: Tom Gundersen Cc: Rauta, Alin; Kinsella, Ray; systemd Mailing List Subject: Re: [systemd-devel] [PATCH] Added UFD (Uplink failure detection) support to networkd On Tue, 27.01.15 19:54, Tom Gundersen (t...@jklm.no) wrote: Hi Alin, Thanks for working on this. I think the main concepts here make sense, but I have some comments on the implementation. So the main ideas are: 1) a notion of groups of links 2) a notion of up- and downlinks 3) configuring downlinks if and only if at least one uplink in the group has a carrier Comments: Maybe we should not restrict the naming to UFD, as the grouping may be useful for other things in the future (would be great if you could comment on Holger's email for instance). In fact Lennart suggested we introduce the concept of 'tags' instead of groups, and these will be similar to tags in udev rules. Taking this one step further we could even simplify further: maybe the entire concept of tags our groups is unnecessary. Instead, let's just introduce a single new setting: BindCarrier= Which takes a list of interface names, and supports globbing. Now, with this functionality in place, and a good naming regime we could implement such uplink/download behaviour too, right? I mean, let's say you name all your uplink interfaces uplink0, uplink1, uplink2, and your downlink interfaces downlink0, downlink1, and so on. Now, in the .network file for the downlink, we'd simply say BindCarrier=uplink*, which would then mean that the port is only configured if at least one interface matching that name, with a carrier is found. Alin, wouldn't this be sufficient for you? I kinda prefer this solution due to its simplicity, and as it does not introduce any new concepts, and only a single new setting... 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] Added UFD (Uplink failure detection) support to networkd
Hi Lennart, Tom, We should also be able to add virtual devices to UFD groups, like Andrei mentioned in his email. In this case, do you think BindCarrier= and Tag= in .network files would still work ? If we think about LAG (link aggregation) and if I am right, it's mapped to the kernel as a virtual device and contains multiple links. This way, it makes sense to have groups of links as netdevs. The only difference in case of UFD is that is not mapped to the kernel, but it's mapped inside networkd. Another thing is that maybe later on we want to provide some properties for an UFD group, maybe to change to way we consider an uplink as failing. This would be easy if we have a netdev for the UFD group. Also, defining a netdev, we don't lose the identity of the feature nor we mask it. The patch I've sent introduces NETDEV_CREATE_GROUP as a new netdev create_type that can be used for other groups also, not just UFDs. The UFD group creation is done by calling netdev-create which is an abstraction for an inside netdev_create_ufd_group, so it's generic. If, for example, I want to add a new kind of groups, not UFD, I have to define a new netdev kind (kind=new_group_kind) and to provide the corresponding create function in the netdev abstraction table. I don't know in which other way to configure the UFDs and handle all use cases (for both virtual physical devices). Please let me know what you think. Best Regards, Alin -Original Message- From: Lennart Poettering [mailto:lenn...@poettering.net] Sent: Wednesday, January 28, 2015 1:53 PM To: Andrei Borzenkov Cc: Rauta, Alin; Kinsella, Ray; systemd Mailing List Subject: Re: [systemd-devel] [PATCH] Added UFD (Uplink failure detection) support to networkd On Wed, 28.01.15 16:48, Andrei Borzenkov (arvidj...@gmail.com) wrote: On Wed, Jan 28, 2015 at 3:40 PM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 28.01.15 10:13, Rauta, Alin (alin.ra...@intel.com) wrote: Lennart, on a switch I should be able to configure more than one UFD group. What precisely does this mean? WOuld those groups be orthogonal? No. You have two different VLANs; uplink group 1 connects to to VLAN1, uplink group 2 connects to VLAN2. They are not orthogonal in any way and exist at the same time. If group 1 goes down, it does not affect group 2 in any way. Hmm, if they don't affect each other, then they *are* orthogonal. Now I am really confused... I really would like to avoid introdcuing the tags concept for now. Would a solution where you give the uplinks appropriate names (like uplink0, uplinkXYZ, uplink_waldo and so on) suffice, when you can then refer to them in a .network file you apply to the downlinks as BindCarrier=uplink*? BindCarrier= would take a list of interface names, possibly with globs. If you want to up and down a link foo if at least one of the links bar, quux, piep, miau1, miau2 are up, you could write this as BindCarrier=bar quux piep miau*. What would introducing the tag concept give you beyond this very simple schreme described above? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel 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 v3] Add FDB support
Hi Johann, Also, note that VlanId is optional. It makes more sense for switch ports. Regarding my “em1” (Ethernet management) interface, probably I should have send an example without VLANId. And “BridgeFDB”s are in the .network following the logic of routes. To be clear look at the outputs below: 1. for a normal port: bridge fdb show dev em1 44:44:12:34:56:70 self permanent 44:44:12:34:56:71 self permanent 33:33:00:00:00:01 self permanent 01:00:5e:00:00:01 self permanent 33:33:ff:8f:e7:3f self permanent 01:00:5e:00:00:fc self permanent 33:33:00:01:00:03 self permanent 2. for a switch port: bridge fdb show dev sw0p1 14:44:12:34:56:70 vlan 2 self permanent 14:44:12:34:56:71 vlan 10 self permanent /Alin From: systemd-devel [mailto:systemd-devel-boun...@lists.freedesktop.org] On Behalf Of Jóhann B. Guðmundsson Sent: Thursday, December 18, 2014 5:51 AM To: systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] [PATCH v3] Add FDB support On 12/17/2014 05:46 PM, Jóhann B. Guðmundsson wrote: On 12/17/2014 03:35 PM, Alin Rauta wrote: Hi Tom, I've formatted the patch based on our previous discussions. This one has support only for adding FDB entries. An example configuration is like below: [Match] Name=em1 [Network] DHCP=v4 [BridgeFDB] MACAddress=44:44:12:34:56:71 VLANId=9 [BridgeFDB] MACAddress=44:44:12:34:56:70 VLANId=2 br0 Please let me know what you think. Thanks, Alin If I start trying to match this with the entire type network files and their path ( feel free to correct me where I'm wrong here ) It would have to look like this... Ignore my mac address entry confusion with the bridge mac addresses in the MAC learning table and the interface mac address here ( em1 ) which somewhat would have been eliminated if we had [BridgePort] and arguably [BridgePortFDB] sections in the network file JBG JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v3] Add FDB support
Thanks Tom.
Much appreciated,
Alin
-Original Message-
From: Tom Gundersen [mailto:t...@jklm.no]
Sent: Thursday, December 18, 2014 2:46 PM
To: Rauta, Alin
Cc: systemd Mailing List; Lennart Poettering; Kinsella, Ray
Subject: Re: [PATCH v3] Add FDB support
Hi Alin,
Looks good. I changed the title a bit (addedd networkd:) and dropped the
signed off by, as we don't use that, and pushed it.
Thanks for your work!
Cheers,
Tom
On Wed, Dec 17, 2014 at 4:35 PM, Alin Rauta alin.ra...@intel.com wrote:
Signed-off-by: Alin Rauta alin.ra...@intel.com
---
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 | 252
+++
src/network/networkd-link.c | 19 +++
src/network/networkd-network-gperf.gperf | 2 +
src/network/networkd-network.c | 13 +-
src/network/networkd.h | 29
src/systemd/sd-rtnl.h| 4 +
10 files changed, 402 insertions(+), 11 deletions(-) create mode
100644 src/network/networkd-fdb.c
diff --git a/Makefile.am b/Makefile.am index ab07d3b..6896c4b 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -5281,6 +5281,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
79c7a23..360c57c 100644
--- a/man/systemd.network.xml
+++ b/man/systemd.network.xml
@@ -549,6 +549,28 @@
/refsect1
refsect1
+title[BridgeFDB] Section Options/title
+paraThe literal[BridgeFDB]/literal section
manages the forwarding database table of a port and accepts the following
keys. Specify
+several literal[BridgeFDB]/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
+
termvarnameVLANId=/varname/term
+listitem
+paraThe VLAN Id for the
new static MAC table entry.
+If omitted, no VLAN Id 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);
+assert_return(rtnl_message_type_is_neigh(m-hdr-nlmsg_type),
+ -EINVAL);
+
+ndm = NLMSG_DATA(m-hdr);
+*flags = ndm-ndm_flags;
+
+return 0;
+}
+
+int sd_rtnl_message_neigh_get_state(sd_rtnl_message *m, uint16_t *state) {
+struct ndmsg *ndm
Re: [systemd-devel] [PATCH v2] Add FDB support
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, Alin -Original Message- From: Tom Gundersen [mailto:t...@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. Cheers, Tom On Mon, Dec 15, 2014 at 11:20 AM, Alin Rauta alin.ra...@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@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 v2] Add FDB support
Sorry, between systemd restarts. /Alin -Original Message- From: Tom Gundersen [mailto:t...@jklm.no] Sent: Tuesday, December 16, 2014 3:56 PM To: Rauta, Alin Cc: Lennart Poettering; systemd Mailing List; Kinsella, Ray Subject: Re: [systemd-devel] [PATCH v2] Add FDB support On Tue, Dec 16, 2014 at 4:28 PM, Rauta, Alin alin.ra...@intel.com wrote: Regarding the flushing of entries that's done because we don't want to have dangling configuration between system restarts, You mean these settings are remembered by the hardware between reboots? Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
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
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
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
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
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
[systemd-devel] [PATCH] rtnl: kernel receive buffer overrun error
Hi, We got the following error when running systemd on a device with many ports: rtnl: kernel receive buffer overrun Event source 'rtnl-receive-message' returned error, disabling: No buffer space available I think the kernel socket receive buffer queue should be increased. The default value is taken from: /proc/sys/net/core/rmem_default, but we can overwrite it using SO_RCVBUF socket option. This is already done in networkd for other sockets. For example, the bus socket (sd-bus/bus-socket.c) has a receive queue of 8MB. In our case, the default is 208KB. Increasing the buffer receive queue for manager socket to 512KB should be enough to get rid of the above error. Please find the patch attached. Alin Rauta Software Applications Engineer +353 (0) 87 101 8449 Intel Shannon Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 Business address: Dromore House, East Park, Shannon, Co. Clare -- Intel Shannon Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 Business address: Dromore House, East Park, Shannon, Co. Clare This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. onp_1556.diff Description: onp_1556.diff ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
