If a Linux host receives and accepts an ICMP redirect (accept_redirects=1 on the interface in question), how long is this route being cached for and observed? Can I lower that time?

I am asking because I have a number of systems that are poisoned with a bogus route that most likely stems from an unfortunate ICMP redirect:

$ ip route get via dev eth0 src cache <redirected>

and they are simply not forgetting the redirect, even >12h after the last ICMP redirect was received! I have to manually do ip route flush cache to remove the entry and reinstate the correct route:

$ ip route get via dev eth0 src cache

I know how and why the ICMP redirect was sent, received and accepted in the first place, this question is not about that.

I think it's not relevant to the question, but here is some detail:

We have an internal network, say One of the machines is a OpenVPN server with remote clients getting assigned addresses within The other internal machines have a static route --> It is deliberately wider than because the VPN server might serve more clients in the future.

Unfortunately, our config management pushes the wider static route 10/8--> also onto the VPN server itself, where it is established as 10/8-->eth0. This unnecessary route is usually not having any effect.

Under normal conditions this setup works just fine. But then this happened:

  • VPN server gets rebooted
  • Some other internal host (say tries to contact a VPN client (say just as the VPN server has its IP stack up, but before OpenVPN is up, so the routes to are not yet established
  • The VPN server has send_redirects=1 on its internal interface eth0, and because of the unfortunate route 10/8->eth0 it sends an according ICMP redirect back to
  • has accept_redirects=1 on its internal interface and caches the route announced in the ICMP redirect and desperately sends out ARP requests for into the internal network:

Shortly after, the VPN server establishes its VPN routes and stops sending redirects, and all other VPN connections work just fine.

So far so good. I think I understand what has happened and why, and I know various ways to remedy short term (ip route flush cache on the internal host) and long term (Of course get rid of the wider route on the VPN server; but also we could set accept_redirects=0 on internal hosts; or set send_redirects=0 on the VPN server), so that is not my question.


  • Ubuntu kernel 3.13.0-141
  • Ubuntu kernel 4.4.0-116 seems to behave differently: It also accepts the ICMP redirect (if accept_redirects=1) insofar as it also starts to send local ARP requests for the destination. But at least as long as those go unanswered, it keeps sending the IP packets to the original next-hop, and ip route get still shows the original, non-redirected next-hop.
  • According to https://vincent.bernat.im/en/blog/2011-ipv4-route-cache-linux, net.ipv4.route.gc_interval might have governed this pre 2.6.38 (2011), but not since.

1 Answer 1


The ICMP redirects are cached for the time specified by gc_timeout (/proc/sys/net/ipv4/gc_timeout). Note, however, that that the timeout starts from the last activity, so in some situations the fault can go on forever.

I am not sure if all Ubuntu distributions have this functionality.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .