Fc39 ping does not work anymore

Ask Fedora
1

Hello there

I have a weird issue which occurred over night with changing nothing. My fc39 desktop is connected to the network via two vlan-tagged interfaces (different subnets). This morning when I started the PC for working Fedora claimed that network on one (the main) interface could not be reached. According to ping I cannot ping my default GW or any resource outside my local LAN.

Two weird things: I can ping hosts within the interfaces same subnet, just not the default GW. Second and that makes is even more weird: although ping sez 100% paket loss when pinging the def GW, tcpdump on the default GW and my local PC sez that ping requests go out and ping replies are coming back. Just the ping command does not “see” the replies.

Any idea what is going wrong here? On the second interface I can ping the GW without issues. First thought it must be firewalld but then I should not see the ping replies in tcpdump, right? Currently I added a new default route via the second interface so I can work. Routing looks fine to me

0.0.0.0         10.66.100.1     0.0.0.0         UG    0      0        0 br860 <<-- second working interface
0.0.0.0         192.168.0.1     0.0.0.0         UG    20425  0        0 br840 <<-- main, non-working interface
10.0.0.0        10.66.100.1     255.0.0.0       UG    426    0        0 br860
10.66.100.0     0.0.0.0         255.255.255.0   U     426    0        0 br860
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
192.168.0.0     0.0.0.0         255.255.255.0   U     425    0        0 br840

Any idea what causes ping to not see the echo replies? And it’s not just icmp affected. With no protocol the replies can be seen, although the replies come in according to tcpdump on my host

07:26:38.545519 IP 192.168.0.17 > 192.168.0.1: ICMP echo request, id 13, seq 18, length 64
07:26:38.545834 IP 192.168.0.1 > 192.168.0.17: ICMP echo reply, id 13, seq 18, length 64
07:27:17.008265 IP 192.168.0.17 > 8.8.8.8: ICMP echo request, id 15, seq 1, length 64
07:27:17.011816 IP 8.8.8.8 > 192.168.0.17: ICMP echo reply, id 15, seq 1, length 64

tcpdump on my host sez internal and external ping replies are coming back but ping sez 100% loss.

Thanks for any hint where to search

tobi

2

This shows the pings are going out and coming back on the 192.168.0.17 interface.

You claim that they are going out and coming back properly on the other interface but show nothing to reveal that.

Please show, (with the commands) the output of ip address and ip route so we see exactly what you see – all interfaces, all routing, and all the details of each.

3

You claim that they are going out and coming back properly on the other interface but show nothing to reveal that.

Here we go with an external ping on the other intferface (when I changed default route)

06:51:12.100191 IP 10.66.100.17 > 8.8.8.8: ICMP echo request, id 3, seq 1, length 64
06:51:12.103977 IP 8.8.8.8 > 10.66.100.17: ICMP echo reply, id 3, seq 1, length 64
06:51:13.101417 IP 10.66.100.17 > 8.8.8.8: ICMP echo request, id 3, seq 2, length 64
06:51:13.105032 IP 8.8.8.8 > 10.66.100.17: ICMP echo reply, id 3, seq 2, length 64

and those replies are shown in ping command

Please show, (with the commands) the output of ip address and ip route…

# ip address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute 
       valid_lft forever preferred_lft forever
2: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 22:f0:0c:02:35:fc brd ff:ff:ff:ff:ff:ff permaddr 74:56:3c:4d:69:8c
3: wlo1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether fa:da:7e:73:ca:5e brd ff:ff:ff:ff:ff:ff permaddr 70:d8:23:5a:26:52
    altname wlp0s20f3
4: eth0.860@enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br860 state UP group default qlen 1000
    link/ether 22:f0:0c:02:35:fc brd ff:ff:ff:ff:ff:ff
5: eth0.840@enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br840 state UP group default qlen 1000
    link/ether 22:f0:0c:02:35:fc brd ff:ff:ff:ff:ff:ff
6: br840: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 22:f0:0c:02:35:fc brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.17/24 brd 192.168.0.255 scope global noprefixroute br840
       valid_lft forever preferred_lft forever
7: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether 02:42:f8:d1:34:dd brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
8: br860: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 74:56:3c:4d:69:8c brd ff:ff:ff:ff:ff:ff
    inet 10.66.100.17/24 brd 10.66.100.255 scope global noprefixroute br860
       valid_lft forever preferred_lft forever

# ip route
default via 10.66.100.1 dev br860 
default via 192.168.0.1 dev br840 proto static metric 20425 
10.0.0.0/8 via 10.66.100.1 dev br860 proto static metric 426 
10.66.100.0/24 dev br860 proto kernel scope link src 10.66.100.17 metric 426 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown 
192.168.0.0/24 dev br840 proto kernel scope link src 192.168.0.17 metric 425

only when I add the default via 10.66.100.1 the ping replies are seen by ping command. With just the default via 192.168.0.1 the ping replies are coming back to my host (as shown by tcpdump in my first post) but not seen by ping command. If I use arping I the replies can be seen

#arping 192.168.0.1
Unicast antworten von 192.168.0.1 [58:9C:FC:10:FF:9D]  0.768ms
Unicast antworten von 192.168.0.1 [58:9C:FC:10:FF:9D]  0.862ms
Unicast antworten von 192.168.0.1 [58:9C:FC:10:FF:9D]  0.802ms
Unicast antworten von 192.168.0.1 [58:9C:FC:10:FF:9D]  0.812ms
Unicast antworten von 192.168.0.1 [58:9C:FC:10:FF:9D]  0.742ms
Unicast antworten von 192.168.0.1 [58:9C:FC:10:FF:9D]  0.833ms
Unicast antworten von 192.168.0.1 [58:9C:FC:10:FF:9D]  0.756ms

# arp -n
192.168.0.100            ether   66:3f:d0:5d:00:4d   C                     br840
10.66.100.1              ether   58:9c:fc:10:ff:c9   C                     br860
192.168.0.1              ether   58:9c:fc:10:ff:9d   C                     br840
[...]

Is there any component that could filter out pakets that are coming in on the interface br840? That is what seems so weird to me: the pakets are coming back but not seen by the application (ex ping or the browsers)

4

Changing reverse path filtering is possible but not recommended.

It is best to create a default route for each upstream interface and then manage routing priorities with different metrics or PBR.

5

Seems the rp_filter is not the cause. Regardless of the value (0, 1 or 2) of rp_filter it does not work on this particular interface. As said the other interface (same setup, bridged VLAN interface) it always works regardless of the rp_filter value. I now connected my PC via WLAN (to the same subnet where it does not work on wired interface) and tada it works. I also tried to boot older kernels but with the same result: it does not work on br840 but it works on br860. So for the moment I use the WLAN interface. Does anyone have another idea where the problem could be? And also an idea why it works on one VLAN-tagged bridged interface but not on the other?

6

Found a “fix” for my problem: just deleted the bridge and the attached VLAN interface and created them new. Tada works again. Would still be interested what could have caused the issue, but as it works again that is not that important anymore :slight_smile: