Linux – How long is an (accepted) ICMP redirect observed for, and how can I shorten that time

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 10.2.2.2
10.2.2.2 via 10.2.2.2 dev eth0 src 10.1.1.2
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 10.2.2.2
10.2.2.2 via 10.1.1.1 dev eth0 src 10.1.1.2
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 10.1.0.0/16. One of the machines 10.1.1.1 is a OpenVPN server with remote clients getting assigned addresses within 10.2.0.0/16. The other internal machines have a static route 10.0.0.0/8 –> 10.1.1.1. It is deliberately wider than 10.2.0.0/16 because the VPN server might serve more clients in the future.

Unfortunately, our config management pushes the wider static route 10/8–>10.1.1.1 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 10.1.1.1 gets rebooted
• Some other internal host (say 10.1.1.2) tries to contact a VPN client (say 10.2.2.2) just as the VPN server has its IP stack up, but before OpenVPN is up, so the routes to 10.2.0.0/16 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 10.1.1.2
• 10.1.1.2 has accept_redirects=1 on its internal interface and caches the route announced in the ICMP redirect and desperately sends out ARP requests for 10.2.2.2 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.

Notes:

• 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 10.2.2.2 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.