[systemd-devel] [PATCH] Added UFD (Uplink failure detection) support to networkd

[Rauta, Alin]

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:lennart at 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.rauta at 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