Настройка времени ожидания ARP-времени

Ответ 1

Кэш-сосед в ядре Linux не так прост, как можно было бы подумать. Я попытаюсь объяснить некоторые из этих причуд.

Существуют незначительные различия между записью кэша соседей, полностью выпадающей из кэша или просто помеченной как устаревшая/недействительная. В какой-то момент между base_reachable_time/2 и 3 * base_reachable_time/2 запись будет по-прежнему находиться в кеше, но будет отмечена состояние STALE. Вы должны иметь возможность просматривать состояние с помощью "ip-s-соседа-шоу",

[email protected]:~$ ip -s neighbor list
192.168.42.1 dev eth0 lladdr 00:25:90:7d:7e:cd ref 2 used 184/184/139 probes 4 STALE
192.168.10.2 dev eth0 lladdr 00:1c:23:cf:0b:6a ref 3 used 33/28/0 probes 1 REACHABLE
192.168.10.1 dev eth0 lladdr 00:17:c5:d8:90:a4 ref 219 used 275/4/121 probes 1 REACHABLE

Когда в состоянии STALE, как показано выше, если я пинг 192.168.42.1, он сразу отправит пакет в 00: 25: 90: 7d: 7e: cd. Через секунду или около того он обычно отправляет запрос ARP для тех, у кого есть 192.168.42.1, чтобы обновить его обратно до состояния REACHABLE. НО, чтобы сделать вещи более запутанными, ядро ​​иногда меняет значения тайм-аута на основе положительной обратной связи от протоколов более высокого уровня. Это означает, что если я пинг 192.168.42.1 и он отвечает, то ядро ​​может не беспокоить отправку ARP-запроса, потому что предполагается, что понг означает, что запись в кеш ARP действительна. Если запись находится в состоянии STALE, она также будет обновляться незапрашиваемыми ответами ARP, которые, по-видимому, видны.

Теперь, в большинстве случаев, запись, находящаяся в состоянии STALE, - это все, о чем вам нужно беспокоиться. Зачем вам нужно полностью удалить запись из кэша? Ядро прилагает много усилий, чтобы не размахивать память, просто изменяя состояние записей кэша, а не фактически удаляя и добавляя их в кеш все время.

Если вы действительно настаиваете на том, что он не только будет отмечен как STALE, но и будет удален из хэш-карты, используемой кешем соседства, вы должны остерегаться нескольких вещей. Во-первых, если запись не была использована и устарела для gc_stale_time секунд, она должна быть удалена. Если gc_stale_time передано и помечено как запись, которую можно удалить, она будет удалена при запуске сборщика мусора (обычно после gc_interval секунд).

Теперь проблема заключается в том, что запись соседа не будет удалена, если на нее ссылаются. Главное, с чем вы столкнетесь, - это ссылка из таблицы ipv4 routing. Там много сложного сбора мусора, но важно отметить, что сборщик мусора для кеша маршрута истекает только каждые 5 минут (/proc/sys/net/ipv4/route/gc_timeout секунд) на большом количестве ядер. Это означает, что запись соседа должна быть отмечена как устаревшая (может быть, 30 секунд, в зависимости от base_reachable_time), затем нужно будет пропустить 5 минут до того, как кеш маршрута перестанет ссылаться на запись (если вы повезло), за которым следует некоторая комбинация gc_stale_time и gc_interval, проходящей до того, как она будет очищена (так, в общем, где-то между 5-10 минутами пройдет).

Сводка: вы можете попытаться уменьшить /proc/sys/net/ipv4/route/gc_timeout до более короткого значения, но есть много переменных, и им сложно управлять всеми ними. Там много усилий, чтобы сделать вещи работать хорошо, не удаляя записи в кеше слишком рано (но вместо этого просто отмечая их как STALE или даже FAILED).

Ответ 2

ip link set arp off dev eth0; ip link set arp on dev eth0

Ответ 3

Самый простой способ полностью очистить кеш файл arp - это привести интерфейс вниз, а затем снова. Очевидно, что это имеет гораздо больше последствий, например, возможно, нарушение текущих TCP-соединений, недостижимое на некоторое время и т.д. Но это, по-видимому, единственный способ действительно удалить запись из кэша arp в последних ядрах: (