Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
zabbal opened this issue Jul 13, 2015 · 14 comments

Comments

@zabbal
Copy link

commented Jul 13, 2015

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.

@zonque zonque added the network label Jul 13, 2015
@poettering

This comment has been minimized.

Copy link
Member

commented Jul 24, 2015

"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

This comment has been minimized.

Copy link
Author

commented Jul 24, 2015

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

This comment has been minimized.

Copy link
Author

commented Jul 24, 2015

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

@poettering

This comment has been minimized.

Copy link
Member

commented Jul 24, 2015

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.

@poettering poettering changed the title link degraded for no apparent reason document what the "degraded" state of network interfaces precisely means Jul 24, 2015
@zabbal

This comment has been minimized.

Copy link
Author

commented Sep 29, 2015

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

This comment has been minimized.

Copy link
Contributor

commented Dec 11, 2015

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

This comment has been minimized.

Copy link
Author

commented Dec 11, 2015

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

This comment has been minimized.

Copy link
Contributor

commented Dec 12, 2015

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

This comment has been minimized.

Copy link
Contributor

commented Dec 12, 2015

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

@ghost

This comment has been minimized.

Copy link

commented Dec 1, 2016

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...

@q2dg

This comment has been minimized.

Copy link

commented Feb 20, 2018

I have exactly the same error, @urzds. In my case it's a Qemu machine inside Gns3

@julian-klode

This comment has been minimized.

Copy link
Contributor

commented Aug 31, 2018

There should really be some documentation what the states are in networkctl(8). Even just adding the comment from the source code in there would be useful:

/* Get operational state from ifindex.
 * Possible states:
 *   off: the device is powered down
 *   no-carrier: the device is powered up, but it does not yet have a carrier
 *   dormant: the device has a carrier, but is not yet ready for normal traffic
 *   carrier: the link has a carrier
 *   degraded: the link has carrier and addresses valid on the local link configured
 *   routable: the link has carrier and routable address configured
@srd424

This comment has been minimized.

Copy link

commented Aug 31, 2018

Please consider this a +1 for changing the "degraded" to something else for a bridge situation. One of the things I like about systemd is being able to quickly check if a system is "OK", would be nice to eliminate this false positive. If the "LinkLocalAddressing=no" still works (will try when it's convenient to mess with my server's interfaces) that seems like it might be a reasonable work around.

@julian-klode

This comment has been minimized.

Copy link
Contributor

commented Sep 5, 2018

I'll try to come up with a pull request to document those things in networkctl manpage.

julian-klode added a commit to julian-klode/systemd that referenced this issue Sep 7, 2018
The manpage gives example outputs with the states, but it never
explains what the states are.

Fixes systemd#575
keszybz added a commit that referenced this issue Sep 7, 2018
The manpage gives example outputs with the states, but it never
explains what the states are.

Fixes #575
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
7 participants
You can’t perform that action at this time.