ARP Таймаут

Похоже, у нас наблюдается похожая проблема — но, кажется, она только-только началась. У нас настроен Cloud Core Router (CCR) как DHCP-сервер. Когда подключается новый клиент, ему назначается динамический IP-адрес из небольшого пула — с 10.10.20.30 по 10.10.20.50. Затем мы вручную заходим в таблицу DHCP-аренд, делаем аренду статической и назначаем конкретный IP-адрес, закреплённый за этим клиентом, например, 10.10.20.181. Клиентский роутер подхватывает этот адрес, как только истекает срок действия динамической аренды.

Сейчас у нас возникают проблемы, когда мы начинаем переводить клиентов с Wi-Fi на волоконные подключения. Мы используем HAP AC: просто вставляем SFP-модуль, отключаем Ethernet-кабель Wi-Fi от порта 1, перенастраиваем HAP AC на SFP и подключаем оптику.

В этом примере мы делаем так с роутером, который был настроен на 10.10.20.181. Теперь HAP AC получает новый IP из пула (например, 10.10.20.39) — всё работает, интернет доступен. На CCR мы удаляем старую статическую запись (10.10.20.181), делаем новую (динамическую) аренду статической и переназначаем её на 10.10.20.181.

Когда срок аренды истекает, HAP подхватывает новый IP, но сразу теряет интернет-соединение.

Проведя небольшое расследование... В ARP-таблице CCR всё ещё хранится старый MAC-адрес (тот, что соответствует Ethernet-порту на HAP), поэтому трафик идёт не на тот MAC. Несмотря на отсутствие активности на этом порту, запись не удаляется из ARP-таблицы — даже спустя несколько дней. Если мы удалим её вручную, новый MAC корректно сохранится. Таймаут ARP на всех интерфейсах установлен по умолчанию.

Есть идеи? Мы успешно проделали такой процесс для нескольких клиентов, переключённых на оптику, но последние пару недель эта проблема вылезает. Спасибо!

Я не могу воспроизвести это у себя. Даже если IP находится в неполном состоянии в таблице ARP, как только устройство получает свой IP от DHCP, запись в ARP обновляется, и устройство сразу же получает доступ к сети.

Не знаю, решалась ли уже эта проблема, у меня была похожая ситуация. У нас есть статическая подсеть 64.57.184.0/24 на LAN bridge1 роутера RB1100AHx2, с интерфейсом 64.57.184.1/24, который должен быть шлюзом по умолчанию для других устройств в этой же LAN. В таблице ARP все записи подсети были заполнены 00:00:00:00:00:00, кроме нескольких IP, которые реально использовались. Я добавил новую машину с адресом 64.57.184.105, и она нормально общалась со всеми устройствами в LAN, кроме 184.1.

Пинги с 184.105 на 184.1 отправлялись и возвращались от 184.1, tcpdump показывал, что ответы доходили до eth0 на 184.105, но в консоли они не отображались. Ни 184.1, ни 184.105 не могли пинговать друг друга, хотя tcpdump фиксировал отправленные и полученные пакеты на интерфейсах eth0 — сырые данные. Затем я использовал tcpdump -nn -e icmp, чтобы посмотреть MAC-адреса в пингах, и оказалось, что адрес назначения — 00:00:00:00:00:00. Это касалось пингов, которые отправлял Mikrotik с 184.1 на десктоп с 184.105.

Когда начинались пинги к 184.105, не происходило ARP-запроса для 184.105, пинги просто отправлялись с 184.1, доходили до 184.105 и там просто сбрасывались, скорее всего из-за неправильно указанного MAC! Я очистил ARP-запись для 184.105 на роутере 184.1, и всё снова заработало. Потом очистил всю таблицу ARP, и всё стало в порядке.

Вот что я наблюдаю: каждый IP во всех публичных подсетях постоянно и многократно запрашивается по ARP, я вижу это на всех машинах в одном широковещательном домене. Люди говорят, что это потому, что кто-то или что-то сканирует подсеть, но это неправда — torch, packet sniffer и tcpdump это однозначно показывают. Поскольку ответы на ARP по неиспользуемым IP не приходят, в таблице ARP появляется MAC 00:00:00:00:00:00.

Но до того, как я очистил всю таблицу, новые пинги на неиспользуемые IP вообще не инициировали ARP-запрос, а пинг отправлялся с MAC 00! Это просто нелепо. После очистки таблицы, даже если все неиспользуемые IP опять в таблице с MAC 00 из-за автоматических ARP-запросов по всей подсети, как только я пингаю 184.105 — сразу же отправляется ARP-запрос, и если IP занят, MAC 00 в таблице сразу заменяется на правильный адрес.

Выходит, что правильный порядок действий такой: если приходит пакет на нужный IP, а в таблице ARP для него стоит MAC 00, нужно заново сделать ARP-запрос, и если приходит ответ — записать правильный MAC и отправить пинг. Таймауты тут не так важны, потому что в теории они значимы только если к IP вообще нет входящих пакетов, независимо от того, занят он или нет.

Homer

Этот 00:00:00:00:00:00 в ARP-кеше — это ложная приманка, на самом деле он полезно указывает на другую проблему — а именно, что процесс ARP иногда не работает для некоторых хостов. В своей практике я периодически сталкивался с проблемами, связанными с arp. Классический случай — меняешь устройство, новое с той же конфигурацией, но с другим MAC-адресом. Другие узлы в сети могут некоторое время не очищать свои ARP-кеши и не понимать, что MAC для IP этого устройства поменялся. В этот промежуток всё «ломается». Назовём это «проблемой ARP-кеша». При такой проблеме в таблице ARP у вас будет неправильный MAC-адрес (он будет помечен как DC). Решение — просто удалить неправильную запись, и устройство начнёт заново отправлять ARP-запросы. Это быстро заставит Mikrotik узнать новый MAC для IP, чей хост изменился. (Конечно, в Windows аналогично можно выполнить arp -d x.x.x.x).

Если же это не «проблема ARP-кеша», то почти всегда проблема на нижнем уровне — 2-м или 1-м уровне. Например, Ethernet-коммутаторы что-то коверкают, или грязная линия плохо передает данные, и так далее. Все жалобы в этой ветке не соответствуют именно «проблеме ARP-кеша». Это потому, что неполная ARP-запись (MAC-адрес полностью из нулей) работает не так, как полная запись в ARP-кеше.

По сути, MAC из нулей в ARP-таблице — это просто удобство для администратора роутера. Он показывает, что Mikrotik сейчас пытается сделать ARP для какого-то IP, но ответа не получает. При этом Mikrotik продолжает попытки ARP-запроса для этого IP. Это удобно, потому что вы видите, что хост, который не пингуется, не ответил на ARP-запрос Mikrotik.

Я только что окончательно проверил это на Mikrotik с wireshark: запускаю ping на IP, которого точно нет в локальной сети. Mikrotik создаёт неполную ARP-запись (MAC из нулей) и начинает выводить «ping timed out». В то же время wireshark показывает постоянные ARP-запросы с MAC Mikrotik. Значит, Mikrotik продолжает отправлять ARP для неполной записи, и только полные записи останавливают отправку ARP-пакетов.

Если у вас есть неполные arp, и вы знаете, что IP существует в сети, значит, надо копать глубже: доходят ли ARP-броадкасты до устройства, которое не отправляет ARP? Отвечает ли оно? Достигают ли ответы Mikrotik? (Если да — я бы сильно удивился). Действительно ли на хосте настроен этот IP? (Завершилась ли корректно DHCP-транзакция на сервере и клиенте?) Работает ли смена IP на другой? И так далее...

Вся эта история с нулевым MAC — просто показывает, что ARP-запрос отправлен на определённый IP, но ответа так и не было.

Я немного поэкспериментировал и обнаружил, что если изменить MAC-адрес устройства, которое уже есть в ARP-кеше роутера Mikrotik, происходит следующее: Устройство и Mikrotik есть друг у друга в ARP-кеше. Пинги проходят без проблем — никаких ARP-запросов в сети нет. Я меняю MAC у устройства и пингую Mikrotik (IP не меняется, только MAC). Mikrotik отвечает на пинг, используя новый исходящий MAC. Затем Mikrotik отправляет ARP-запрос по этому IP. Устройство отвечает новым MAC. В таблице Mikrotik MAC-адрес обновляется. Тайминг этих событий может быть немного смещён, так как всё это я делаю в GNS3, но не представляю, как Wireshark мог бы получить пакеты в неправильном порядке. Интересно, что Cisco при смене MAC всегда отправляет gratuitous ARP-запросы (видимо, чтобы исключить дублирование IP). И только этого достаточно, чтобы Mikrotik обновил свой ARP-кеш на новый MAC (причём сам Mikrotik в этом случае даже свой ARP-запрос не отправляет).

Не знаю, может, Cisco уже исправила эту давнюю проблему в последних версиях… Но у Cisco всегда была такая штука: стандартное время ожидания ARP было очень большим (кажется, 6 часов). Роутер не обучался узнавать MAC-адреса удалённых устройств из входящих ARP-запросов — только из ответов на свои собственные исходящие запросы. В итоге, когда заменяешь устройство, подключённое к сети через Cisco-роутер, и присваиваешь новому устройству (с новым MAC) IP адрес старого, оно просто «зависает», как мёртвая утка, пока Cisco не решит обновить запись ARP и заново отправить ARP-запрос. А при стандартных настройках это могло занять часы.

Ну, это не мой опыт... ожидание таймаута ARP-таблицы в Cisco было для меня довольно обычным, когда мы ещё использовали Cisco (маршрутизаторы на базе IOS). Наверное, в коммутаторах всё иначе. Таблицы пересылки обновляются гораздо быстрее, и ARP-таблицы обычно сбрасываются при обрыве/восстановлении линка. Однако распространённый случай, когда за коммутатором стоит какое-то устройство, которое потом подключается к маршрутизатору, этого не покрывает: маршрутизатор не видит переключение линка при смене устройства. Думаю, ни один маршрутизатор не обновит ARP-таблицу только на основе IP-пакетов, но вполне обычно создать запись в ARP при входящем ARP-запросе (готовьтесь к ответу). Однако ОБНОВЛЕНИЕ записи в ARP на основе входящего ARP-запроса происходит не всегда (по моему опыту, точно не в Cisco IOS), вероятно потому, что это упростило бы перехват трафика в локальной сети.