v5.2: stuck ipv4 redirects

v5.2: stuck ipv4 redirects

[Russell King - ARM Linux admin]

Hi,

I'm seeing a problem with ipv4 redirects seemingly not expiring.

I have:
- A VM running a 5.2 kernel, with IP address 192.168.0.251/23, default
  route 192.168.0.254.
- The main router at 192.168.0.254/23.
- A second router which was at 192.168.1.59/23, but which I moved to
  192.168.0.245/23.  Behind this is a subnet 192.168.253.252/30.

The VM at some point received a redirect from 192.168.0.254 for
192.168.253.254, telling it to redirect to 192.168.1.59.

Since the IP change of the second router, the VM has been unable to
contact 192.168.253.254, but can contact 192.168.253.253.  What I
see via tcpdump is:

11:34:48.549410 ARP, Request who-has 192.168.1.59 tell 192.168.0.251, length 28

I haven't found a way to view any information on the redirects that
the VM kernel has accepted.  The `ip' tool doesn't seem to have any
way to access that information (or I'm missing something.)

Any ideas what is going on, how to inspect the kernel's state from
userland wrt redirects, and how this can be solved without rebooting?

Thanks.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

Re: v5.2: stuck ipv4 redirects

[Russell King - ARM Linux admin]

On Thu, Dec 12, 2019 at 11:44:52AM +0000, Russell King - ARM Linux admin wrote:
> Hi,
> 
> I'm seeing a problem with ipv4 redirects seemingly not expiring.
> 
> I have:
> - A VM running a 5.2 kernel, with IP address 192.168.0.251/23, default
>   route 192.168.0.254.
> - The main router at 192.168.0.254/23.
> - A second router which was at 192.168.1.59/23, but which I moved to
>   192.168.0.245/23.  Behind this is a subnet 192.168.253.252/30.
> 
> The VM at some point received a redirect from 192.168.0.254 for
> 192.168.253.254, telling it to redirect to 192.168.1.59.
> 
> Since the IP change of the second router, the VM has been unable to
> contact 192.168.253.254, but can contact 192.168.253.253.  What I
> see via tcpdump is:
> 
> 11:34:48.549410 ARP, Request who-has 192.168.1.59 tell 192.168.0.251, length 28
> 
> I haven't found a way to view any information on the redirects that
> the VM kernel has accepted.  The `ip' tool doesn't seem to have any
> way to access that information (or I'm missing something.)
> 
> Any ideas what is going on, how to inspect the kernel's state from
> userland wrt redirects, and how this can be solved without rebooting?

It seems others have come across this as well:

http://commandline.ninja/2015/06/18/damn-you-icmp-redirect-or-rather-how-to-flush-a-cached-icmp-redirect-under-centos7linux/

and with that, I've a way to "solve" the problem - but it seems that
some redirects can get stuck:

$ ip -s route get 192.168.253.254
192.168.253.254 via 192.168.1.59 dev enp1s0 src 192.168.0.251 uid 1000
    cache <redirected> users 2
$ ip -s route get 192.168.253.253
192.168.253.253 via 192.168.0.245 dev enp1s0 src 192.168.0.251 uid 1000
    cache <redirected> expires 274sec users 2 age 24sec

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up