document what the "degraded" state of network interfaces precisely means

[zabbal]

I've got very simple setup:

my.network:
[Match]
Name=eth1
[Network]
Bridge=xbr1

and the corresponding bridge entry:
externalbridge1.netdev
[NetDev]
Name=xbr1
Kind=bridge

However it's in degraded state:

networkctl
eth1 ether degraded configured

But systemd-networkd seems to have no complains about it:

systemctl status systemd-networkd
● systemd-networkd.service - Network Service
Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled; vendor preset: enabled)
Active: inactive (dead) since Mon 2015-07-13 15:33:53 CEST; 18min ago
Docs: man:systemd-networkd.service(8)
Process: 658 ExecStart=/lib/systemd/systemd-networkd (code=exited, status=0/SUCCESS)
Main PID: 658 (code=exited, status=0/SUCCESS)
Status: "Shutting down..."

...
Jul 13 15:33:19 xnode systemd-networkd[658]: Enumeration completed
Jul 13 15:33:19 xnode systemd-networkd[658]: eth1 : link configured
Jul 13 15:33:19 xnode systemd-networkd[658]: eth1 : gained carrier
Jul 13 15:33:19 xnode systemd[1]: Started Network Service.
...

The link is UP and is part of the bridge xbr1 according to "ip a" and "brctl show". How can I figure out why networkd mark this link as "degraded"?

Systemd version is 219-7ubuntu6 from latest ubuntu on x86_64.

Note: it might or might not be related to #425.

[poettering]

"degraded" means it is up but has no public IP addresses assigned (possibly link-local ones though). This means its not useful to reach the Internet.

what does "ip addr" show for that interface when this happens?

[zabbal]

Of course "degraded" link does not have an ip address - it's part of the bridge, so bridge interface is the one which have address:

ip a show xbr1:
7: xbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether de:87:58:55:42:60 brd ff:ff:ff:ff:ff:ff
inet 172.16.0.1/24 scope global xbr1
valid_lft forever preferred_lft forever
inet6 fe80::dc87:58ff:fe55:4260/64 scope link
valid_lft forever preferred_lft forever

ip a show eth1:
4: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master xbr1 state UP group default qlen 1000
link/ether 00:1a:4a:8b:eb:43 brd ff:ff:ff:ff:ff:ff
inet6 fe80::21a:4aff:fe8b:eb43/64 scope link
valid_lft forever preferred_lft forever

brctl show xbr1:
bridge name bridge id STP enabled interfaces
xbr1 8000.de8758554260 no eth1

networkctl:
networkctl
IDX LINK TYPE OPERATIONAL SETUP
1 lo loopback carrier unmanaged
4 eth1 ether degraded configured
7 xbr1 ether routable unmanaged

Note - some unrelated interfaces are omitted for clarity.

It's kinda cosmetic issue - the network works just fine but it's highly misleading and does not help (if not worse) with troubleshooting. I think networkctl should be smarter and distinguish between interfaces which are "not useful to reach the Internet" and those which are, albeit indirectly, with ip address assigned to the bridge to which they are assigned.

[zabbal]

A little note - in the comment above ip address was assigned to xbr1 manually, but having this assignment in .network file change nothing.

[poettering]

Well, how precisely the state is called is certainly a bikeshedding issue, and since its kinda API it's too late to change anyway. However, we should certainly document what this means to avoid further confusion. Turning this into a documentation bug hence.

[zabbal]

I have not found it in http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/ but even if it's API it doesn't have to be set in stone - sooner or later it'll be expanded. That would be perfect time to add "bridged" to the list of "unmanaged", "degraded", "configured" etc. Btw, I did not managed to find exhaustive list of possible states in "man networkctl" or wiki. So, if it's part of stable API - where is it documented?

[mvduin]

Tip: it seems you can change the state from the alarming "degraded" to the much more benign "carrier" by ensuring the interface has no configured addresses whatsoever, including link-local, e.g.:

[Match]
Name=eth0

[Network]
Bridge=br0
LinkLocalAddressing=no

A more interesting question is of course, since adding an interface to a bridge effectively claims the whole interface for the bridge alone, why is their special status not much more highly visible? Why does the kernel even allow configuring IPs on them?

[zabbal]

The point is not in coming up with workaround to hide the information - I think we should do exactly the opposite: expose the information to user of networkctl. And this information is available somewhere, there are interfaces to get it (look at brctl for instance) - it's just the matter of bringing it all together into one coherent tool.

[mvduin]

I agree, although it's still good to have a quick workaround to keep networkctl from yelling "SOMETHING IS WRONG" in my face, especially when actively fiddling with configuration which means something may very well indeed be wrong. (It was a bit fiddly to get the config right to make sure my MAC address to the outside world is still the same as it was before I inserted a bridge to accomodate containers.)

I agree all info should be there. In fact, I would hope the kernel very clearly marks interfaces in this state. An interface that has been added to a bridge is (or should be) unavailable for layer 3 protocols, and not be used directly for anything other than BPDUs, LLDP, etc. I don't understand why the kernel even allows configuring addresses on them, although there may be some justification / use case I'm overlooking.

In any case, the fact that link-local addresses get configured on a bridge slave by default is definitely a bug, and if that's fixed then the status will automagically cease to be "degraded".

[mvduin]

There's more crap being defined on bridge slave interfaces btw: I just ran into the problem of an app that failed to send an IPv6 multicast ("Cannot assign requested address"). The culprit turned out to be a route for the bridge slave interface: ff00::/8 dev eth0 table local

I have a network interface with an associated .network file like this:

[Match]
MACAddress=...
[Network]
Address=192.168.0.24/24

networkctl also lists this as "degraded":

[...]
  2 enp1s0f0         ether              degraded    configured
[...]

The status sub-command provides no further information, except that networkd indeed detected the related .network file:

# networkctl status enp1s0f0
● 2: enp1s0f0
       Link File: /usr/lib64/systemd/network/99-default.link
    Network File: /run/systemd/network/static-lan1.network
            Type: ether
           State: degraded (configured)
[...]

ip address shows that the link is up, has a link-local IPv6 address, but no IPv4 address at all:

[...]
2: enp1s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether ... brd ff:ff:ff:ff:ff:ff
    inet6 fe80::.../64 scope link
       valid_lft forever preferred_lft forever    
[...]

journalctl -b -u systemd-networkd shows nothing related, except that the link once had a DHCP address:

systemd[1]: Starting Network Service...
systemd-networkd[824]: Enumeration completed
systemd[1]: Started Network Service.
systemd-networkd[824]: lo: Configured
systemd-networkd[824]: enp1s0f0: Gained carrier
systemd-networkd[824]: enp1s0f0: DHCPv4 address 192.168.0.24/24 via 192.168.0.25
systemd[1]: Stopping Network Service...
systemd[1]: Stopped Network Service.
systemd[1]: Starting Network Service...
systemd-networkd[1082]: Enumeration completed
systemd[1]: Started Network Service.
systemd-networkd[1082]: lo: Configured
systemd-networkd[1082]: enp1s0f1: Gained carrier
systemd-networkd[1082]: enp1s0f0: Gained IPv6LL
systemd-networkd[1082]: enp1s0f1: Gained IPv6LL
[...]

I am so far unable to figure out why that happens, what "degraded" actually means in this case and why networkd thinks it does not have to respect the .network file and instead tries DHCP on the interface...