Как долго соблюдается (принимается) перенаправление ICMP и как я могу сократить это время?

Если хост Linux получает и принимает перенаправление ICMP (accept_redirects=1 на рассматриваемом интерфейсе), как долго этот маршрут кешируется и отслеживается? Могу я уменьшить это время?

Я спрашиваю, потому что у меня есть несколько систем, отравленных поддельным маршрутом, который, скорее всего, связан с неудачным перенаправлением 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>

и они просто не забывая о перенаправлении, даже> 12 часов после получения последнего перенаправления ICMP! Я должен сделать вручную ip route flush cache чтобы удалить запись и восстановить правильный маршрут:

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

Я знаю, как и почему перенаправление ICMP было отправлено, получено и принято в первую очередь, этот вопрос не об этом.

Думаю, это не относится к вопросу, но вот некоторые подробности:

У нас есть внутренняя сеть, скажем 10.1.0.0/16. Одна из машин 10.1.1.1 - это сервер OpenVPN с удаленными клиентами, которым назначаются адреса в пределах 10.2.0.0/16. Остальные внутренние машины имеют статический маршрут 10.0.0.0/8 -> 10.1.1.1. Он намеренно шире, чем 10.2.0.0/16, потому что в будущем VPN-сервер может обслуживать больше клиентов.

К сожалению, наше управление конфигурацией проталкивает более широкий статический маршрут 10/8 -> 10.1.1.1 также на сам сервер VPN, где он устанавливается как 10/8 -> eth0. Этот ненужный маршрут обычно не действует.

В нормальных условиях эта установка работает нормально. Но потом случилось следующее:

• VPN-сервер 10.1.1.1 перезагружается
• Другой внутренний хост (скажем, 10.1.1.2) пытается связаться с VPN-клиентом (скажем, 10.2.2.2) так же, как у VPN-сервера есть свой IP-стек, но до того, как OpenVPN будет запущен, поэтому маршруты к 10.2.0.0/16 не еще установлен
• На сервере VPN есть send_redirects=1 на своем внутреннем интерфейсе eth0, и из-за неудачного маршрута 10 / 8-> eth0 он отправляет соответствующее перенаправление ICMP обратно на 10.1.1.2
• 10.1.1.2 имеет accept_redirects=1 на своем внутреннем интерфейсе и кэширует маршрут, объявленный в перенаправлении ICMP, и отчаянно отправляет ARP-запросы для 10.2.2.2 во внутреннюю сеть:

Вскоре после этого VPN-сервер устанавливает свои VPN-маршруты и перестает отправлять перенаправления, а все другие VPN-соединения работают нормально.

Все идет нормально. Я думаю, что понимаю, что произошло и почему, и знаю различные способы исправить краткосрочные (ip route flush cache на внутреннем хосте) и долгосрочный (конечно, избавьтесь от более широкого маршрута на VPN-сервере; но также мы могли бы установить accept_redirects=0 на внутренних хостах; или установить send_redirects=0 на сервере VPN), так что не мой вопрос.

Ноты:

• Ядро Ubuntu 3.13.0-141
• Ядро Ubuntu 4.4.0-116, похоже, ведет себя иначе: оно также принимает перенаправление ICMP (если accept_redirects=1), поскольку он также начинает отправлять локальные запросы ARP для пункта назначения. Но, по крайней мере, пока они остаются без ответа, он продолжает отправлять IP-пакеты на исходный следующий переход, и ip route get 10.2.2.2 по-прежнему показывает исходный неперенаправленный следующий переход.
• В соответствии с https://vincent.bernat.im/en/blog/2011-ipv4-route-cache-linux, net.ipv4.route.gc_interval могло регулировать это до 2.6.38 (2011), но не с тех пор.