Складывается очередь записей ARP

Я только что увидел это на роутере без настроенного proxy-arp (даже с довольно простой конфигурацией), так что, похоже, связь с proxy-arp — это просто отвлекающий манёвр... Мне тоже пришлось добавить плановый скрипт, который каждый вечер очищает записи... Не идеально, но пока сойдет. Не могу поверить, что сотни людей здесь об этом не жалуются... Похоже, мне придется потратить немного времени, чтобы найти минимальную конфигурацию, на которой я смогу это надежно воспроизвести.

Все еще вижу это в версии 7.9.2 (сообщу, если в 7.10 эта проблема останется)…

Я тоже заметил это на нашем роутере после обновления до версии v7. Обошёл проблему, добавив запланированный скрипт, который ночью удаляет записи ARP. Действительно, мы используем local-proxy-arp, так что может быть связано, хотя на другом роутере без этого я тоже вижу много старых записей ARP…

Дело в том, что это действительно вызывает проблему на сайтах с высоким уровнем «текучки» пользователей. Когда на DHCP-сервере включено обнаружение конфликтов (а это всегда хорошая идея), сервер отправляет ARP-запрос на IP-адрес, который собирается выдать. Если такая запись уже есть в ARP-таблице, он даже не отправляет запрос — просто помечает этот IP как занятый и переходит к следующему.

Я считаю, что значение таймаута никак не связано с тем, сколько времени запись ARP хранится в кэше роутера. Скорее, это время, в течение которого пакеты, отправленные на интерфейс, остаются «в очереди», пока запись ARP не подтверждена (то есть не получен ответ). Если данные остаются в очереди дольше заданного таймаута, а запись ARP так и не подтверждена, эти данные просто удаляются (память освобождается). Если же ответ на ARP приходит раньше таймаута, то данные из очереди отправляются. Наверное, должен быть ещё какой-то параметр, который указывает, как долго подтверждённая запись ARP может находиться в таблице, прежде чем её удалят и нужно будет заново её сформировать. Но такого параметра нет, и я видел такую же проблему даже на обычных Linux-системах с новым ядром (много записей ARP для устройств, которые давно отсутствуют в сети). Как я уже говорил, можно обойти это, создав регулярный скрипт, который удаляет записи ARP. Можно начать с команды «/ip arp remove [ find where !complete ]», а если этого мало — использовать «/ip arp remove [ find ]».

Итак, создайте запланированный скрипт. Он работает и не вызывает никаких дополнительных проблем.

Как я уже писал, это то, что делает новый ядро Linux. Наверное, на это есть причина — может, так эффективнее или ещё почему-то.

Эти результаты ожидаемы и задокументированы, смотрите свойство max-neighbor-entries в настройках IP: Кэш ARP хранит ARP-записи, и если некоторые из них неполные, они могут там оставаться неопределённо долго. Это происходит только в том случае, если количество записей в кэше меньше четверти максимального разрешённого значения. Такая логика нужна, чтобы не запускать ненужный сборщик мусора, когда таблица ARP далеко не заполнена. Если это нежелательно, можно либо вручную очистить неполные записи, либо уменьшить значение max-neighbor-entries.

Многопоточный алгоритм поиска адресов не требует затрат при обращении к таблице ARP, жертвуя при этом производительностью вставки и удаления записей. Это вполне логично: маршрутизатор добавляет запись в ARP один раз, а потом может обращаться к ней миллион раз. Сборщик мусора блокирует всю таблицу ARP, полностью останавливая разрешение адресов. Хотя это занимает лишь долю секунды, это всё равно важно, учитывая гигабиты трафика. Вот почему мы сохраняем отключённые хосты в таблице ARP, если позволяет память (до max-neighbor-entries / 4). Изменение уже существующих записей ARP требует гораздо меньше ресурсов, чем их добавление или удаление (при изменении блокируется только запись, а не вся таблица). Если вы всё же хотите удалить неполные или недоступные записи ARP, можно запланировать выполнение скрипта: /ip/arp/remove [find where !complete]