I think NetworkManager has a bug. On a machine with several network interfaces, it seems to select one as the default without regard to whether it is ‘live’ or not. In my case, the router could see 192.168.0.109 (the machine’s enp9s0 NIC), but NetworkManager had decided to use enp8s0. Naturally, pings to the router would fail. I think it would be useful (and eliminate a lot of heartache) if NetworkManager selected the interface to use with more intelligence and/or somehow display what it was seeing.
To be honest, it looks like a misconfiguration, but you are free to open a feature request for L3 failover on the upstream issue tracker:
If you are referring to this Router sees network connections, but can't ping router - #3 by darksky
It looks to me that both interfaces are UP. Isn’t it?
Yes, they are.
You can use the command ip route show to see what the system has configured for routing.
It seems that usually the default route is set for the first interface configured during boot.
It also is known that having more than one interface active on the same subnet can cause issues since potentially the outgoing message may be on one interface but the reply may come to the other interface where there is no active connection.
Connecting multiple interfaces simultaneously is not a problem for NetworkManager, and you can easily confirm this using a Fedora VM.
But NetworkManager does not support OOTB load balancing or L3 failover that the OP is requesting.
Apparently, the original issue was caused by misconfigured upstream equipment.
I did have an edge router that I have since wired around if that’s what you mean by upstream equipment, but knowing which interface was selected and where it’s available on the outside of the machine aren’t obvious. NM picked enp8s0 which I now know maps to the bottom LAN port on the case; I had wired the top LAN port (which I now know is mapped to enp9s0) to the router. The cable was good, the router could see 192.168.0.109, but NM didn’t ‘notice’, because it ‘insisted’ on using enp8s0. I’m suggesting that NM could be smarter, maybe notice which port has a cable connected, perhaps one that returns a ping or some other ARP information. I don’t particularly care about load balancing or failover, just want not to have to figure out which interface devices map to ports on the case and some indication of what NM selected. I realize that ping indicates which address is originating the ping request, but everything needed for NM to behave more intelligently is present, why push that responsibility onto the user?
It should be pretty simple to identify by checking the lowest metric and using traceroute.
NetworkManager most likely noticed restricted connectivity as it performs active periodic connectivity checks using the default route with the lowest metric.
If you want to make a feature request, it is best to contact the NetworkManager devs directly on the relevant issue tracker.
That’s what failover is responsible for, and it works automatically for L1 and partially for L2/L3 when using DHCP.
This should be the responsibility of your network administrator to properly configure upstream equipment, so downstream clients don’t have to deal with this sort of issues.
In an ideal world, cool, but there’s no one here to kick the ball down the road to. Some ‘downstream’ clients must unwittingly be their own network administrator. Why lobby in support of less-than-ideal software that relies on smart people to fill in the gaps when smarter software is well within reach?
You should consider replacing the static configuration with DHCP as it can provide at least a partial solution to the discussed issue.
Which software supports the desired functionality?
NetworkManager’s next release.
1 Like
If that is the case then this is not kicking the ball down the road. The functionality seems not quite available as you indicate, though it may be in the works.