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

[Rauta, Alin]

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:lennart at 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 (teg at 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