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
On Tue, 03.02.15 13:03, Rauta, Alin (alin.ra...@intel.com) wrote: Hi Lennart, I agree that BindCarrier= should suffice. Perfect! I have added this to the TODO list now, and of course we'd be happy to take a patch! 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
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
On Thu, 29.01.15 14:05, Rauta, Alin (alin.ra...@intel.com) wrote: What if we don't use the * for now and document BindCarrier accordingly to be a list of port names and no wildcard ? Note that checking wildcards is really easy with glibc's fnmatch(). In fact, it's easier to do the full globbing thing than shortcutting this only for * and strcmp()... 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
On Thu, 29.01.15 15:20, 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? 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. No. The matches should be reevaluated each time in full. Basically each time when we are ready to apply a .network file we should check the carrier of the interfaces that the .network's BindCarrier= matches. And each time an interface comes or goes, or changes its name, we must reevaluate the BindCarrier= settings of all other interfaces that might match now or might match no longer. This must be fully dynamic. 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. I don't see how an uplink group would get us anything here. There's effectively little difference between propagating carriers from interfaces to uplink groups to other interfaces, and propagating it directly from interfaces to other interfaces. We can do both fully dynamic, just one of them is much simpler conceptually than the other. I am still pretty convinced that a singular new option, that is BindsCarrier= would suffice to implement the usescases here. 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
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
On Thu, 29.01.15 16:19, Rauta, Alin (alin.ra...@intel.com) wrote: So, we have: 1. BindCarrier=list of uplink ports 2. Network.DownlinkCarrierGroup=1 in upstream interface Network.UplinkCarrierGroup=1 in downstream interface This would mean you have to create 2 new members for the Network structure. 3. If we are to add 2 members then we can also think of adding: Network.UFDGroup = 1; Network.UFDType = uplink/downlink; For the feature to be visible I would say 3, but I'm fine with any of them. #1 appears to be the simplest concept. To consider #2 or #3 I'd really like to hear about usecases that #1 cannot cover? 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
On Thu, 29.01.15 18:49, Andrei Borzenkov (arvidj...@gmail.com) wrote: В Thu, 29 Jan 2015 15:10:16 +0100 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl пишет: On Thu, Jan 29, 2015 at 02:05:10PM +, Rauta, Alin wrote: 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 ? What about interpreting the wildcard dynimically instead? If eth3 goes down, look at all interfaces which have BindCarrier set, and check with glob if their BindCarrier setting matches eth3, and act accordingly. This means that every time any interface (dis)appears you must go through all existing BindCarrier statements and check whether they apply. This is really ugly. For this reasons I believe uplink group should be first class citizen also internally. Well, I really don't see how this would be ugly. When we design interfaces we primarily should keep the user's PoV in mind, and only secondarily the ease of implementation. I mean, if you are concerned about scalability (because each new interface means we need to check O(n) other interfaces), then there are certainly better ways to optimize that (for example, via a prefix hash table or so). But either way, I doubt this is really worth it for now, it would be premature optimization. We are not talking 10K of ports here for now. And if we want to support that one day, then there's ample time to add such a prefix hash table by then... And how do you set properties for it? Which of BindCarrierMode statements in different link (or are they network?) files apply if they differ? What if you need to add more properties? I am pretty sure BindCarrier= and BindCarrierMode= should be .network properties. And they only apply to each specific link the .network file is applied on. And since we only apply a single .network file per link at any time there's no ambiguity here at all. What about DownlinkCarrierGroup=1 in upstream interface UplinkCarrierGroup=1 in downstream interface This creates uplink group 1 and binds interfaces to it. Now you only need to care if there is another interface definition that has the same group number. I fully agree with Zbginiew that numeric IDs as identifiers for user objects are a bad idea. But you still need ability to set group properties (although in practice every switch I have seen is using policy all - anyone can give compelling use case for using any?), so yes, we may need support configuration object for it. But the first step could be default to policy all which does not require any configuration. I fail to see what properties these groups would require that couldn't be better be just be .network file properties... But yeah, I am pretty sure that BindCarrier= would be the first step, and BindCarrierMode= only the next step should the default policy of all not be sufficient for all usecases... 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
On Thu, 29.01.15 17:00, Daniel Ankers (md1...@md1clv.com) wrote: The problem I see with this approach is that it allows bizarre configurations to be specified which don't make sense in practice: e.g. 1 - Loop: /etc/systemd/network/downlink0.network: BindCarrier=uplink* /etc/systemd/network/uplink0.network: BindCarrier=downlink* e.g. 2 - Chain /etc/systemd/network/downlink0.network: BindCarrier=uplink* /etc/systemd/network/uplink0.network: BindCarrier=thirdlink* I think this is not really an issue, since we'd bind the application of a .network file to the physical carrier sense of other interfaces, but not application of .network files to application of .network files. Since the the application of .network files and carrier sense are pretty much orthogonal creating a loop is not really doable, unless you actually involve physically or virtually looping back the carrier 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
On 29 January 2015 at 16:19, Rauta, Alin alin.ra...@intel.com wrote: So, we have: 1. BindCarrier=list of uplink ports 2. Network.DownlinkCarrierGroup=1 in upstream interface Network.UplinkCarrierGroup=1 in downstream interface This would mean you have to create 2 new members for the Network structure. 3. If we are to add 2 members then we can also think of adding: Network.UFDGroup = 1; Network.UFDType = uplink/downlink; For the feature to be visible I would say 3, but I'm fine with any of them. Hi all, As a sysadmin, my preference would be for option 1 - that is that you do the configuration in one place: the interface you are changing the behaviour of. I'd then imagine that networkctl could do something like: # networkctl ufd downlink0 UFD is configured on this interface Config File: /etc/systemd/network/downlink0.network Interface is UP because ANY uplink is UP Uplinks: uplink0 (DOWN) uplink1 (UP) # networkctl ufd uplink1 UFD is not configured on this interface or this interface is an uplink. The problem I see with this approach is that it allows bizarre configurations to be specified which don't make sense in practice: e.g. 1 - Loop: /etc/systemd/network/downlink0.network: BindCarrier=uplink* /etc/systemd/network/uplink0.network: BindCarrier=downlink* e.g. 2 - Chain /etc/systemd/network/downlink0.network: BindCarrier=uplink* /etc/systemd/network/uplink0.network: BindCarrier=thirdlink* All this is from a user point of view, without knowing what kind of code would be needed to support it. Regards, Dan ___ 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
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 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
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 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
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
В Thu, 29 Jan 2015 15:10:16 +0100 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl пишет: On Thu, Jan 29, 2015 at 02:05:10PM +, Rauta, Alin wrote: 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 ? What about interpreting the wildcard dynimically instead? If eth3 goes down, look at all interfaces which have BindCarrier set, and check with glob if their BindCarrier setting matches eth3, and act accordingly. This means that every time any interface (dis)appears you must go through all existing BindCarrier statements and check whether they apply. This is really ugly. For this reasons I believe uplink group should be first class citizen also internally. And how do you set properties for it? Which of BindCarrierMode statements in different link (or are they network?) files apply if they differ? What if you need to add more properties? What about DownlinkCarrierGroup=1 in upstream interface UplinkCarrierGroup=1 in downstream interface This creates uplink group 1 and binds interfaces to it. Now you only need to care if there is another interface definition that has the same group number. But you still need ability to set group properties (although in practice every switch I have seen is using policy all - anyone can give compelling use case for using any?), so yes, we may need support configuration object for it. But the first step could be default to policy all which does not require any configuration. ___ 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
On Thu, Jan 29, 2015 at 06:49:08PM +0300, Andrei Borzenkov wrote: В Thu, 29 Jan 2015 15:10:16 +0100 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl пишет: On Thu, Jan 29, 2015 at 02:05:10PM +, Rauta, Alin wrote: 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 ? What about interpreting the wildcard dynimically instead? If eth3 goes down, look at all interfaces which have BindCarrier set, and check with glob if their BindCarrier setting matches eth3, and act accordingly. This means that every time any interface (dis)appears you must go through all existing BindCarrier statements and check whether they apply. This is really ugly. For this reasons I believe uplink group should be first class citizen also internally. Well, how many can you have? Even with a 100 interfaces, it'll be very fast. In practice you would use a glob or a set of globi, so the check will be a few calls to fnmatch. And how do you set properties for it? Which of BindCarrierMode statements in different link (or are they network?) files apply if they differ? What if you need to add more properties? What about DownlinkCarrierGroup=1 in upstream interface UplinkCarrierGroup=1 in downstream interface Index numbers are horrible in a configuration interface. Zbyszek ___ 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
В Thu, 29 Jan 2015 16:19:14 + Rauta, Alin alin.ra...@intel.com пишет: So, we have: 1. BindCarrier=list of uplink ports 2. Network.DownlinkCarrierGroup=1 in upstream interface Network.UplinkCarrierGroup=1 in downstream interface This would mean you have to create 2 new members for the Network structure. 3. If we are to add 2 members then we can also think of adding: Network.UFDGroup = 1; Network.UFDType = uplink/downlink; For the feature to be visible I would say 3, but I'm fine with any of them. I like 3 as well. Thanks, Alin -Original Message- From: Andrei Borzenkov [mailto:arvidj...@gmail.com] Sent: Thursday, January 29, 2015 3:49 PM To: Zbigniew Jędrzejewski-Szmek Cc: Rauta, Alin; Lennart Poettering; Kinsella, Ray; systemd Mailing List Subject: Re: [systemd-devel] [PATCH] Added UFD (Uplink failure detection) support to networkd В Thu, 29 Jan 2015 15:10:16 +0100 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl пишет: On Thu, Jan 29, 2015 at 02:05:10PM +, Rauta, Alin wrote: 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 ? What about interpreting the wildcard dynimically instead? If eth3 goes down, look at all interfaces which have BindCarrier set, and check with glob if their BindCarrier setting matches eth3, and act accordingly. This means that every time any interface (dis)appears you must go through all existing BindCarrier statements and check whether they apply. This is really ugly. For this reasons I believe uplink group should be first class citizen also internally. And how do you set properties for it? Which of BindCarrierMode statements in different link (or are they network?) files apply if they differ? What if you need to add more properties? What about DownlinkCarrierGroup=1 in upstream interface UplinkCarrierGroup=1 in downstream interface This creates uplink group 1 and binds interfaces to it. Now you only need to care if there is another interface definition that has the same group number. But you still need ability to set group properties (although in practice every switch I have seen is using policy all - anyone can give compelling use case for using any?), so yes, we may need support configuration object for it. But the first step could be default to policy all which does not require any configuration. ___ 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
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. 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 ___ 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
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] 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
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*? 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
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] 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 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. I.e., introduce a new directive called Tag= in .network files, and this could then be used for different things in the future. I don't think we should introduce a netdev kind for groups, as this really does not correspond to a netdev in the kernel. And I don't think we should list the ifnames in the configuration of the groups, but rather configure the group name in the .network file (see how bonding and bridging currently works). It looks to me that we don't even need (yet) configuration files for the groups, they can just be made implicitly from their name as given in .network files. Using the idea of Tags should give you this. If possible we should not wait for all links to appear before handling a group, but be tolerant to not knowing upfront precisely which links will be on a system. It looks to me that this shouldn't be a problem, but maybe I missed something? Also here see how bridging and bonding currently works. 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? Lastly, Lennart also pointed out that there is not really a need for grouping the downlinks, only the uplinks. We could then simply have a new directive BindToCarrier= which is set in downlinks and which takes a list of tags, meaning that this link will only be configured once at least one tag has a link with a carrier. What do you think? Cheers, Tom ___ 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
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, While reading this I'm just thinking about RFC5880 ff. BFD support. Anybody in the networks universe already thinking about this? Holger - On 23 Jan, 2015, at 18:20, Alin Rauta alin.ra...@intel.com wrote: Hi, Uplink Failure Detection (UFD) is a key enhancement to networkd, that will provide support for the switch use case. The links can be configured as uplinks or as downlinks inside an UFD group. When all uplinks for a group are down, the failure is propagated to the downlinks, so the devices connected to them can take a defined action. When at least one uplink become available, the daemon tries to bring the downlink ports up. Multiple UFD groups can be configured through .netdev files. See below a configuration example: [NetDev] Name=group1 Kind=ufd [UFDGroup] Id=10 [UFDLink] Name=sw0p1,sw0p2 Type=uplink [UFDLink] Name=sw0p3 Type=downlink [UFDLink] Name=sw0p4 Type=downlink Few details on implementation: Networkd waits until all links are enumerated (either static configured or unmanaged). Only then it starts enumerating the groups. networkctl command was also updated to support listing of ufd groups configuration. See below a print-out: # networkctl ufd 10 ? UFD Group: 10 Config File: /etc/systemd/network/ufd_to_test.netdev State: configured Uplinks: ? 3: sw0p1 ? 4: sw0p2 Downlinks: ? 6: sw0p4 ? 5: sw0p3 Please let me know what you think. Thanks, Alin Alin Rauta (1): Added Uplink failure detection feature to networkd Makefile.am |4 + man/systemd.netdev.xml | 72 +- src/libsystemd/sd-network/sd-network.c | 117 +++ src/network/networkctl.c| 153 src/network/networkd-link.c | 35 + src/network/networkd-manager.c | 36 + src/network/networkd-netdev-gperf.gperf |3 + src/network/networkd-netdev-ufd-group.c | 298 +++ src/network/networkd-netdev-ufd-group.h | 85 ++ src/network/networkd-netdev.c | 36 + src/network/networkd-netdev.h |6 + src/network/networkd-ufd-daemon.c | 1321 +++ src/network/networkd-ufd-daemon.h | 34 + src/network/networkd.c |7 + src/network/networkd.h |6 + src/systemd/sd-network.h| 20 + 16 files changed, 2231 insertions(+), 2 deletions(-) create mode 100644 src/network/networkd-netdev-ufd-group.c create mode 100644 src/network/networkd-netdev-ufd-group.h create mode 100644 src/network/networkd-ufd-daemon.c create mode 100644 src/network/networkd-ufd-daemon.h -- 1.9.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Holger Winkelmann ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Added UFD (Uplink failure detection) support to networkd
Hi, Uplink Failure Detection (UFD) is a key enhancement to networkd, that will provide support for the switch use case. The links can be configured as uplinks or as downlinks inside an UFD group. When all uplinks for a group are down, the failure is propagated to the downlinks, so the devices connected to them can take a defined action. When at least one uplink become available, the daemon tries to bring the downlink ports up. Multiple UFD groups can be configured through .netdev files. See below a configuration example: [NetDev] Name=group1 Kind=ufd [UFDGroup] Id=10 [UFDLink] Name=sw0p1,sw0p2 Type=uplink [UFDLink] Name=sw0p3 Type=downlink [UFDLink] Name=sw0p4 Type=downlink Few details on implementation: Networkd waits until all links are enumerated (either static configured or unmanaged). Only then it starts enumerating the groups. networkctl command was also updated to support listing of ufd groups configuration. See below a print-out: # networkctl ufd 10 ? UFD Group: 10 Config File: /etc/systemd/network/ufd_to_test.netdev State: configured Uplinks: ? 3: sw0p1 ? 4: sw0p2 Downlinks: ? 6: sw0p4 ? 5: sw0p3 Please let me know what you think. Thanks, Alin Alin Rauta (1): Added Uplink failure detection feature to networkd Makefile.am |4 + man/systemd.netdev.xml | 72 +- src/libsystemd/sd-network/sd-network.c | 117 +++ src/network/networkctl.c| 153 src/network/networkd-link.c | 35 + src/network/networkd-manager.c | 36 + src/network/networkd-netdev-gperf.gperf |3 + src/network/networkd-netdev-ufd-group.c | 298 +++ src/network/networkd-netdev-ufd-group.h | 85 ++ src/network/networkd-netdev.c | 36 + src/network/networkd-netdev.h |6 + src/network/networkd-ufd-daemon.c | 1321 +++ src/network/networkd-ufd-daemon.h | 34 + src/network/networkd.c |7 + src/network/networkd.h |6 + src/systemd/sd-network.h| 20 + 16 files changed, 2231 insertions(+), 2 deletions(-) create mode 100644 src/network/networkd-netdev-ufd-group.c create mode 100644 src/network/networkd-netdev-ufd-group.h create mode 100644 src/network/networkd-ufd-daemon.c create mode 100644 src/network/networkd-ufd-daemon.h -- 1.9.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
