Por quanto tempo um redirecionamento ICMP (aceito) é observado e como posso reduzir esse tempo?

Question

Se um host Linux receber e aceitar um redirecionamento de ICMP ( accept_redirects=1 na interface em questão), por quanto tempo esse caminho será armazenado em cache e observado? Posso diminuir esse tempo?

Estou perguntando porque tenho vários sistemas que são envenenados com uma rota falsa que provavelmente deriva de um infeliz redirecionamento ICMP:

$ 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>

e eles estão simplesmente não esquecendo o redirecionamento, mesmo > 12h depois que o último redirecionamento ICMP foi recebido ! Eu preciso fazer manualmente ip route flush cache para remover a entrada e restabelecer a rota correta:

$ ip route get 10.2.2.2 10.2.2.2 via 10.1.1.1 dev eth0 src 10.1.1.2 cache

Eu sei como e porque o redirecionamento ICMP foi enviado, recebido e aceito em primeiro lugar, essa questão não é sobre isso.

Acho que não é relevante para a pergunta, mas aqui estão alguns detalhes:

Temos uma rede interna, digamos 10.1.0.0/16. Uma das máquinas 10.1.1.1 é um servidor OpenVPN com clientes remotos recebendo endereços designados em 10.2.0.0/16. As outras máquinas internas têm uma rota estática 10.0.0.0/8 - > 10.1.1.1. É deliberadamente maior que 10.2.0.0/16 porque o servidor VPN pode servir mais clientes no futuro.

Infelizmente, nosso gerenciamento de configuração impulsiona a rota estática mais ampla 10/8 - > 10.1.1.1 também para o próprio servidor VPN, onde é estabelecido como 10/8 - > eth0. Esta rota desnecessária geralmente não está tendo efeito algum.

Em condições normais, esta configuração funciona bem. Mas então isso aconteceu:

• O servidor VPN 10.1.1.1 é reinicializado
• Algum outro host interno (por exemplo, 10.1.1.2) tenta entrar em contato com um cliente VPN (por exemplo, 10.2.2.2) assim como o servidor VPN tem seu IP stack, mas antes que o OpenVPN esteja ativo, as rotas para 10.2.0.0/ 16 ainda não estão estabelecidos
• O servidor VPN tem send_redirects=1 em sua interface interna eth0, e por causa da infeliz rota 10 / 8- > eth0 ele envia um redirecionamento de acordo com o ICMP de volta para 10.1.1.2
• 10.1.1.2 tem accept_redirects=1 em sua interface interna e armazena em cache a rota anunciada no redirecionamento de ICMP e envia desesperadamente solicitações de ARP para 10.2.2.2 para a rede interna:

Pouco depois, o servidor VPN estabelece suas rotas VPN e para de enviar redirecionamentos, e todas as outras conexões VPN funcionam bem.

Até aí tudo bem. Eu acho que entendo o que aconteceu e por que, e eu sei várias maneiras de remediar a curto prazo ( ip route flush cache no host interno) e de longo prazo (Claro, se livrar da rota mais ampla no servidor VPN; mas também poderíamos definir accept_redirects=0 nos hosts internos ou defina send_redirects=0 no servidor VPN), de modo que não minha pergunta.

Notas:

• Ubuntu kernel 3.13.0-141
• O kernel do Ubuntu 4.4.0-116 parece se comportar de maneira diferente: ele também aceita o redirecionamento de ICMP (se accept_redirects=1 ) na medida em que ele também começa a enviar solicitações ARP locais para o destino. Mas, pelo menos enquanto esses não forem atendidos, ele continuará enviando os pacotes IP para o próximo salto original e ip route get 10.2.2.2 ainda mostrará o próximo salto original não redirecionado.
• De acordo com o link , net.ipv4.route.gc_interval pode ter governado este pré-2,6 .38 (2011), mas não desde.