Inverted next hop

olegon · Tue Aug 04, 2020 5:12 pm

Hello, friends

I have configuration

PC1 (Linux) 192.168.88.2 - RB1 192.168.88.1 (static route) - RB2 192.168.88.254|192.168.10.1 - PC2 (Linux) 192.168.10.20

Very rarely (1 of 45 packets or less), while ping from PC to PC2, I got

64 bytes from tanya (192.168.10.20): icmp_seq=940 ttl=63 time=4.25 ms
64 bytes from tanya (192.168.10.20): icmp_seq=941 ttl=63 time=1.18 ms
64 bytes from tanya (192.168.10.20): icmp_seq=942 ttl=63 time=1.24 ms
From wall (192.168.88.1) icmp_seq=943 Redirect Host(New nexthop: 254.88.168.192 (254.88.168.192))
64 bytes from tanya (192.168.10.20): icmp_seq=943 ttl=63 time=1.08 ms
64 bytes from tanya (192.168.10.20): icmp_seq=944 ttl=63 time=0.994 ms

What is this? I never used 254.88.168.192, suppose it's inverted 192.168.88.254? But why it reversed?
route from RB1

4 A S  192.168.10.0/24    192.168.88.1    192.168.88.254            1
5 ADC  192.168.88.0/24    192.168.88.1    bridge                    0

olegon · Thu Aug 06, 2020 11:23 am

Sorry, any ideas?

sindy · Thu Aug 06, 2020 5:44 pm

The first Mikrotik (wall) sends an ICMP redirect when it receives a packet from someting in 192.168.88.0/24 (the linux PC) which is best routed via some other gateway device in the same subnet (the second Mikrotik). It is telling the Linux PC to use 192.168.88.254 instead of itself (the 192.168.88.1) as a gateway towards 192.168.10.0/24 (or maybe just 192.168.10.20, I rarely use this).

The question whether the reverse order of bytes is just a visualisation issue on the Linux machine or whether the Mikrotik really sends the gateway IP that way can only be answered by sniffing the traffic into a file using tcpdump (on the Linux PC) or /tool sniffer (on the first Mikrotik itself) and opening that file using Wireshark.

Yet another question is why the Linux PC ignores the redirect and keeps pinging via the static route's gateway instead of caching the new gateway from the redirect.

olegon · Thu Aug 06, 2020 5:54 pm

Thank you, sindy! I recheck configuration in direction, you said... Removed preferred source (192.168.88.1 before), and message disappeared.

olegon · Sat Aug 08, 2020 1:19 pm

Unfortunately, I was wrong. But why Mikrotik very unstable send this redirect packet? Sometimes it's very stable sent ping reply, sometimes - send redirect again and again.
Below replies while host is down.

[olegon@oops ~]$ ping tanya
PING tanya (192.168.10.20) 56(84) bytes of data.
From wall (192.168.88.1) icmp_seq=2 Redirect Host(New nexthop: 254.88.168.192 (254.88.168.192))
From wall (192.168.88.1) icmp_seq=3 Redirect Host(New nexthop: 254.88.168.192 (254.88.168.192))
From wall (192.168.88.1) icmp_seq=4 Redirect Host(New nexthop: 254.88.168.192 (254.88.168.192))
^C
--- tanya ping statistics ---
4 packets transmitted, 0 received, +3 errors, 100% packet loss, time 3049ms

Redirected packet in wireshark

sindy · Sat Aug 08, 2020 2:42 pm

I didn't really get why you've expected that removing pref-src should change anything, so I am not surprised it didn't work.

What you actually need to do is to set a route to 192.168.10.0/24 via 192.168.88.254 already on the Linux PC1.

As for the randomness, that's another point - try looking (using tcpdump) to what MAC address the pings are being sent. Maybe the linux sometimes accepts the redirect and sometimes not - if it does, the ping packets are leaving via the correct gateway (192.168.88.254), so no redirects are sent.

Wireshark shows that RouterOS sends the gateway address in proper format, so now the question is whether the network stack of the Linux handles it properly and only the ping application prints it out wrong, or whether already the network stack has an issue.

faljse · Sat Oct 10, 2020 4:33 pm

https://github.com/iputils/iputils/comm ... 9134e8da19

Inverted next hop

Inverted next hop

Re: Inverted next hop

Re: Inverted next hop

Re: Inverted next hop

Re: Inverted next hop

Re: Inverted next hop

Re: Inverted next hop

Who is online