Fedora 33 with two NICs for two Sub-C nets

Discussions in English on using Fedora
#1

I am using a PC which has two NICs for two different Sub-C nets:
One for the local LAN
one for the internet router.

It worked well under Fedora for some years, but since a few months it is almost no more usable.
With both being plugged in, it takes a long time to connect to a network drive in the local LAN, but no internet connection is available. Unplugging the LAN, internet connection works. Plugging LAN again it takes roughly a minute to connect to the LAN.
Then it may be possible to use both without noticeable delays, but that does not always work.
Unfortunately I did not notice from which on the problems started: F32 → F33 update or since a newer kernel version. The PC was updated regularly.

#2

Could it be related to
?

https://fedoraproject.org/wiki/Changes/systemd-resolved

2 Likes
#3

It could be, but frankly speaking I do not fully understand the entire description.
If it was a change made in Fedora 33, so it may fit to the time when the ‘problem’ started.

If you do not wish to use systemd-resolved, then manual intervention will be required to disable it:
Disable and stop systemd-resolved.service.
Delete /etc/resolv.conf
Restart the NetworkManager service. NetworkManager will then create a traditional /etc/resolv.conf. (If you are not using NetworkManager, you may create your own /etc/resolv.conf and configure it to your liking.)

That may be worth a try, but will systemd-resolved be used in the coming Fedora versions too and the problem then comes back?

#4

We aren’t planning on making it mandatory, so if you follow the above steps, that should persist. Also, if it does solve the problem, please file a bug because this use case should be supported.

2 Likes
#5

That will be

sudo systemctl disable systemd-resolved.service
sudo systemctl stop systemd-resolved.service
sudo rm /etc/resolv.conf
sudo systemctl restart NetworkManager

or is anything missing?

1 Like
#6

Try to isolate the issue when it happens.
Ping some hosts on the internet by their IP address and domain name.

#7

The issue always happens right after boot.
Do you agree with the set of commands as the entire set being needed?

#8

I have run the four commands above, rebooted with both being plugged in, but the issues is unchanged.

#9

try

# let the system know NetworkManager is back in charge
...
sudo rm /etc/resolv.conf
sudo ln -sf /run/NetworkManager/resolv.conf /etc/resolv.conf
...

# to prevent the service from being enabled without consent
...
sudo systemctl disable systemd-resolved.service
sudo systemctl mask systemd-resolved.service
...
4 Likes
#10

Made an upgrade to 5.11.9 this morning and rebooted a few times.

Both are plugged in: The first access to a network drive needs some seconds but then the access is as quick as to a local drive.
It is not possible to access a web site

Unplugged LAN: Internet access now working

Plugged in LAN: Both can be accessed.

Next I will try the suggestions of gus67

#11

I have run the 4 commands , but the the problem is still there.
I have to unplug LAN after boot to use the internet, and after first use, LAN can be plugged in again to use both.

#13

Well, in total there sould have been 6, but a reboot did the rest anyway :slight_smile:

AFAIK /etc/resolv.conf linking to NetworkManager was the default up to f33 so ‘old school’ tools like nslookup should work again.

If network resolution seems not to be the problem, maybe your routing table can shed some light to this.

Providing the output of

route

nslookup fqdn.of.your.router
nslookup fqdn.of.your.nas

# or the same with dig
dig fqdn.of.your.router
dig fqdn.of.your.nas

might help.

If the name-resolution via nslookup/dig works, it’s time to look elsewhere. Also the routing-table should reflect your network, providing entries for both your nic’s.

#14

Both plugged in, automatic DNS, after boot:

route:
default _gateway 0.0.0.0 UG 101 0 0 enp0s31f6
default _gateway 0.0.0.0 UG 102 0 0 enp13s0
192.168.13.0 0.0.0.0 255.255.255.0 U 101 0 0 enp0s31f6
192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0
192.168.167.0 0.0.0.0 255.255.255.0 U 100 0 0 enp0s20f0u5u1u2
192.168.178.0 0.0.0.0 255.255.255.0 U 102 0 0 enp13s0

192.168.13 being the LAN, 192.168.178 being the internet net

dig 192.168.178.5
; <<>> DiG 9.11.28-RedHat-9.11.28-1.fc33 <<>> 192.168.178.5
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 15948
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 2303d7fda18399a63981064160648b7591205a10aac45e74 (good)
;; QUESTION SECTION:
;192.168.178.5. IN A
;; AUTHORITY SECTION:
. 10800 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2021033100 1800 900 604800 86400
;; Query time: 17 msec
;; SERVER: 192.168.178.5#53(192.168.178.5)
;; WHEN: Mi MĂ€r 31 16:47:17 CEST 2021
;; MSG SIZE rcvd: 145

nslookup 192.168.178.5
** server can’t find 5.178.168.192.in-addr.arpa: NXDOMAIN

In network settings, DNS was set ‘automatic’
entering the router address instead doesn’t make a change

#15

Hmm, is 192.168.178.5 the DNS-server for your network, or are you using your fritzbox as dns-provider?

The output should look like this for the fqdn (fully qualified domain name)


nslookup fritz.box
Server:		192.168.333.1
Address:	192.168.333.1#53

Name:	fritz.box
Address: 192.168.178.1
dig fritz.box
...
;; QUESTION SECTION:
;fritz.box.			IN	A

;; ANSWER SECTION:
fritz.box.		60	IN	A	192.168.178.1
...
;; SERVER: 192.168.333.1#53(192.168.333.1)
...


or like this for the reverse lookup.

nslookup 192.168.178.1
1.178.168.192.in-addr.arpa	name = fritz.box.
dig -x 192.168.178.1 # <- you have to set -x for a reverse lookup!
...
;; QUESTION SECTION:
;1.178.168.192.in-addr.arpa.	IN	PTR

;; ANSWER SECTION:
1.178.168.192.in-addr.arpa. 60	IN	PTR	fritz.box.
...
;; SERVER: 192.168.333.1#53(192.168.333.1)
...

Using dig to querry for an ip instead of an fqdn (without the -x) will cause the dns server to treat the ip like an fqdn he can’t resolve, querry his root-servers and fail. But it shows that in your case 192.168.178.5 is the dns-server your host is using for dns-resolution.

In any case 192.168.178.5 does not have any dns informaton for your network it seems.

So you should either set the correct dns-server via dhcp or directly via /etc/resolv.conf, or make sure the dns-server has the appropriate information.

If 192.168.178.5 is the host itself, systemd-resolved still is active and not using the dns-server for your network


#16

dig cannot return any usable information on a private subnet. 192.168.0.0/16 is a private subnet so all parts are blocked from dig.

You really should only have one default route, and that should point to the device that leads to the internet. Having 2 default routes leads to trouble, especially since this one “default _gateway 0.0.0.0 UG 101 0 0 enp0s31f6” leads to the LAN
I have this

0.0.0.0/1 via 10.203.7.1 dev tun0 
default via 192.168.2.1 dev wlp4s0 proto dhcp metric 600 
10.203.7.0/24 dev tun0 proto kernel scope link src 10.203.7.8 
128.0.0.0/1 via 10.203.7.1 dev tun0 
192.168.2.0/24 dev wlp4s0 proto kernel scope link src 192.168.2.111 metric 600 
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown

when I have my vpn connected, but notice the metrics. The tunnel has no metric (metric 0) and my default route via the gateway router has metric 600 so it chooses the lowest metric first (tun0).

#17


well


I fully agree on that, but since the routing table is set by the system (I guess ?) that’s what we have to work with ATM. In theory if two routes for the same destination use different nics, the metric decides which one to try first. But since there is no connecton to the internet via the LAN-interface (?), the other route is used.

@benpack maybe

route -n

can shed a little more light on this.

#19

enp0s31f6 - 192.168.13.1 - is a NAS in the local LAN
enp13s0 - 192.168.178.5 - is a Router with firewall, connected to a FritzBox in Bridging mode.
enp0s20f0u5u1u2 - 192.168.167.0 - a programmer

enp13s0 - DSL: Gateway and DNS set to 192.168.178.5
enp0s31f6 and enp13s0 have static IP adresses

route -n
0.0.0.0 192.168.13.1 0.0.0.0 UG 101 0 0 enp0s31f6
0.0.0.0 192.168.178.5 0.0.0.0 UG 102 0 0 enp13s0
192.168.13.0 0.0.0.0 255.255.255.0 U 101 0 0 enp0s31f6
192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0
192.168.167.0 0.0.0.0 255.255.255.0 U 100 0 0 enp0s20f0u5u1u2
192.168.178.0 0.0.0.0 255.255.255.0 U 102 0 0 enp13s0
192.168.178.0 192.168.178.5 255.255.255.0 UG 102 0 0 enp13s0

#20

@benpack, customize the gateway configuration as follows:

nmcli connection modify id LAN \
ipv4.never-default yes ipv6.never-default yes
nmcli connection up id LAN

@computersavvy, the netmask takes precedence over the metric.
The metric matters if the routes have the same netmask.
Your case is the former, while the OP’s is the latter.

1 Like
#21

Gives an ‘unknown connection »enp0s31f6«’

1 Like
#22

Paste the output:

nmcli connection show