A network interface losing and regaining signal can have additional effects (in Linux)

January 25, 2020

My office at work features a dearth of electrical sockets and as a result a profusion of power bars and other means of powering a whole bunch of things from one socket. The other day I needed to reorganize some of the mess, and as part of that I wound up briefly unplugging the power supply for my 8-port Ethernet switch that my office workstation is plugged into. Naturally this meant that the network interface lost signal for a bit (twice, because I wound up shuffling the power connection twice). Nothing on my desktop really noticed, including all of the remote X stuff I do, so I didn't think more about it. However, when I got home, parts of my Wireguard tunnel didn't work. I eventually fixed the problem by restarting the work end of my Wireguard setup, which does a number of things that including turning on IP(v4) forwarding on my workstation's main network interface.

I already knew that deleting and then recreating an interface entirely can have various additional effects (as happens periodically when my PPPoE DSL connection goes away and comes back). However this is a useful reminder to me that simply unplugging a machine from the network and then plugging it in can have some effects too. Unfortunately I'm not sure what the complete list of effects is, which is somewhat of a problem. Clearly it includes resetting IP forwarding, but there may be other things.

(All of this also depends on your system's networking setup. For instance, NetworkManager will deconfigure an interface that goes down, while I believe that without it, the interface's IP address remains set and so on.)

I'm not sure if there's any good way to fix this so that these settings are automatically re-applied when an interface comes up again. Based on this Stackexchange question and answer, the kernel doesn't emit a udev event on a change in network link status (it does emit a netlink event, which is probably how NetworkManager notices these things). Nor is there any sign in the networkd documentation that it supports doing something on link status changes.

(Possibly I need to set 'IgnoreCarrierLoss=true' in my networkd settings for this interface.)

My unfortunate conclusion here is that if you have a complex networking setup and you lose link carrier on one interface, the simplest way to restore everything may be to reboot the machine. If this is not a good option, you probably should experiment in advance to figure out what you need to do and perhaps how to automate it.

(Another option is to work out what things are cleared or changed in your environment when a network interface loses carrier and then avoid using them. If I turned on IP forwarding globally and then relied on a firewall to block undesired forwarding, my life would probably be simpler.)


Comments on this page:

From 193.219.181.253 at 2020-01-25 05:42:44:

For instance, NetworkManager will deconfigure an interface that goes down,

Current versions do it after 4 seconds delay, which annoys me sometimes, but has the advantage of surviving short link flaps.

I'm not sure if there's any good way to fix this so that these settings are automatically re-applied when an interface comes up again.

If you want to perform these actions immediately on link-up, then ifplugd should do. (If you are using systemd-networkd, looks like networkd-dispatcher can react to carrier-up as well.)

If you'd rather wait until NetworkManager/networkd has finished setting up IP addresses and such, then place a script under /etc/NetworkManager/dispatcher.d or use networkd-dispatcher in a similar way.

Yes, unfortunately "doing things on status change" with networkd is currently a third-party project...

If I turned on IP forwarding globally and then relied on a firewall to block undesired forwarding, my life would probably be simpler

It probably would, in particular because that's how forwarding is already controlled for IPv6 – as far as I've managed to figure out, the per-interface ipv6.conf.forwarding knobs do not actually enable/disable packet forwarding itself, they merely enable/disable "router behavior" (such as ignoring incoming RAs by default). So having nft/iptables rules is already unavoidable with IPv6.

Written on 25 January 2020.
« Go compared to Python for small scale system administration scripts and tools
How big our Prometheus setup is (as of January 2020) »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sat Jan 25 00:24:59 2020
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.