http://mikrotik.moscow Новое в теме ARP Таймаут форума RouterOS на сайте Mikrotik.moscow [mikrotik.moscow] ru http://backend.userland.com/rss2 Thu, 13 Aug 2026 02:00:19 -0400 ARP Таймаут RouterOS в форуме RouterOS.
Возможно, я случайно обрызгал кофем всю клавиатуру, читая этот пост.
30.08.2017 18:06:00, ZeroByte.]]> http://mikrotik.moscow/forum/forum57/86876-arp-taymaut/message411227 http://mikrotik.moscow/forum/forum57/86876-arp-taymaut/message411227 Wed, 30 Aug 2017 18:06:00 -0400 RouterOS ARP Таймаут RouterOS в форуме RouterOS.
Привет! ARP жрёт пропускную способность на моих частичных T1 (для европейцев — E1)! И ещё потребляет ресурс процессора! Кто вообще таскает компьютер, они же огромные. Ой, подождите, на секунду вернулся в 1992 год! Вот откуда взялся длинный таймер кеша ARP. Это может сильно осложнить жизнь, если ты делаешь что-то, что не использует GARP, чтобы заставить устройства вверх по цепочке обновить свой ARP-кеш. Я часто сталкиваюсь с этим, когда меняю файрволы или роутеры за Cisco-оборудованием, управляемым провайдером. Наверное, за свою практику не раз «шевелил» штекеры питания на паре их коммутаторов уровня 3 от ATT, пытаясь объяснить их технарям, зачем нужно очистить ARP-кеш и как это сделать.
30.08.2017 14:12:00, idlemind.]]> http://mikrotik.moscow/forum/forum57/86876-arp-taymaut/message411226 http://mikrotik.moscow/forum/forum57/86876-arp-taymaut/message411226 Wed, 30 Aug 2017 14:12:00 -0400 RouterOS ARP Таймаут RouterOS в форуме RouterOS.
Ну, это не мой опыт... ожидание таймаута ARP-таблицы в Cisco было для меня довольно обычным, когда мы ещё использовали Cisco (маршрутизаторы на базе IOS). Наверное, в коммутаторах всё иначе. Таблицы пересылки обновляются гораздо быстрее, и ARP-таблицы обычно сбрасываются при обрыве/восстановлении линка. Однако распространённый случай, когда за коммутатором стоит какое-то устройство, которое потом подключается к маршрутизатору, этого не покрывает: маршрутизатор не видит переключение линка при смене устройства. Думаю, ни один маршрутизатор не обновит ARP-таблицу только на основе IP-пакетов, но вполне обычно создать запись в ARP при входящем ARP-запросе (готовьтесь к ответу). Однако ОБНОВЛЕНИЕ записи в ARP на основе входящего ARP-запроса происходит не всегда (по моему опыту, точно не в Cisco IOS), вероятно потому, что это упростило бы перехват трафика в локальной сети.
30.08.2017 13:56:00, pe1chl.]]> http://mikrotik.moscow/forum/forum57/86876-arp-taymaut/message411225 http://mikrotik.moscow/forum/forum57/86876-arp-taymaut/message411225 Wed, 30 Aug 2017 13:56:00 -0400 RouterOS ARP Таймаут RouterOS в форуме RouterOS.
Могу гарантировать, что Mikrotik не отправляет кадры по сети с MAC-адресом назначения, состоящим из одних нулей. MAC из одних нулей в таблице ARP — это признак того, что процесс ARP почему-то не работает. Это может быть связано с самим Mikrotik, с хостом или с чем-то в сети между ними. Но дело не в том, что Mikrotik считает MAC-адрес нулевым и использует его как адрес назначения на уровне 2. По моему опыту, чаще бывает наоборот. Я заметил, что Cisco-роутеры обычно очень быстро обновляют свои ARP-данные, несмотря на время кэширования. Мне кажется, они обновляют кэш ARP каждый раз, когда приходит новый пакет от того же IP, но с другим MAC-адресом. Я видел, как они создавали ARP-записи через каналы, которые не передавали данные в одном направлении — то есть ARP-запрос и ответ не могли пройти полностью. Иногда помогала очистка ARP-записей на роутере, но это чаще происходило в случаях, когда я менял топологию Ethernet, и коммутаторы посередине еще не обновили свои CAM-таблицы с правильными портами.
30.08.2017 13:44:00, ZeroByte.]]> http://mikrotik.moscow/forum/forum57/86876-arp-taymaut/message411224 http://mikrotik.moscow/forum/forum57/86876-arp-taymaut/message411224 Wed, 30 Aug 2017 13:44:00 -0400 RouterOS ARP Таймаут RouterOS в форуме RouterOS.
Не знаю, может, Cisco уже исправила эту давнюю проблему в последних версиях… Но у Cisco всегда была такая штука: стандартное время ожидания ARP было очень большим (кажется, 6 часов). Роутер не обучался узнавать MAC-адреса удалённых устройств из входящих ARP-запросов — только из ответов на свои собственные исходящие запросы. В итоге, когда заменяешь устройство, подключённое к сети через Cisco-роутер, и присваиваешь новому устройству (с новым MAC) IP адрес старого, оно просто «зависает», как мёртвая утка, пока Cisco не решит обновить запись ARP и заново отправить ARP-запрос. А при стандартных настройках это могло занять часы.
30.08.2017 08:46:00, pe1chl.]]> http://mikrotik.moscow/forum/forum57/86876-arp-taymaut/message411223 http://mikrotik.moscow/forum/forum57/86876-arp-taymaut/message411223 Wed, 30 Aug 2017 08:46:00 -0400 RouterOS ARP Таймаут RouterOS в форуме RouterOS.
Никто не спорит, что нормальное поведение роутера должно быть таким: пытаешься подключиться к IP несуществующего устройства — в ARP записывается MAC-адрес, состоящий из нулей. Подключаешь устройство с этим IP — при первом пакете Mikrotik видит пакет с исходным MAC (в нашем примере: 11:11:11:11:11:11) и обновляет ARP новыми данными. Проблема, с которой сталкиваются другие пользователи на этом форуме, в том, что даже когда появляется новое устройство с MAC 11:11:11:11:11:11, запись в таблице ARP не обновляется, и Mikrotik продолжает отправлять пакеты на MAC, состоящий из нулей. Наша же проблема была почти такая же, только ARP не заполнялся нулями, а реальным MAC каким-то устройством. По всей видимости, проблема в коде Mikrotik, который по какой-то причине в редких случаях не хочет переписывать запись MAC-адресом исходного MAC пакета, который он получает. По-моему, это баг. Не уверен, как это воспроизвести, если увижу снова — займусь более детальным разбором.
30.08.2017 08:34:00, aviper.]]> http://mikrotik.moscow/forum/forum57/86876-arp-taymaut/message411222 http://mikrotik.moscow/forum/forum57/86876-arp-taymaut/message411222 Wed, 30 Aug 2017 08:34:00 -0400 RouterOS ARP Таймаут RouterOS в форуме RouterOS.
Я немного поэкспериментировал и обнаружил, что если изменить 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-запрос не отправляет).
29.08.2017 22:57:00, ZeroByte.]]> http://mikrotik.moscow/forum/forum57/86876-arp-taymaut/message411221 http://mikrotik.moscow/forum/forum57/86876-arp-taymaut/message411221 Tue, 29 Aug 2017 22:57:00 -0400 RouterOS ARP Таймаут RouterOS в форуме RouterOS.
Наша проблема была немного другой — у нас был неверный MAC, а не только нули. Насколько я понимаю (без реального теста с wireshark), клиент отправлял пакет на шлюз, но шлюз отвечал с неправильным MAC. Правильное поведение — отправлять обратно пакет с dst MAC, который равен src MAC запроса, ЗА ИСКЛЮЧЕНИЕМ случая, когда для этого src IP есть статическая ARP-запись. Это решит нашу проблему и также проблему с нулями.
29.08.2017 22:09:00, aviper.]]> http://mikrotik.moscow/forum/forum57/86876-arp-taymaut/message411220 http://mikrotik.moscow/forum/forum57/86876-arp-taymaut/message411220 Tue, 29 Aug 2017 22:09:00 -0400 RouterOS ARP Таймаут RouterOS в форуме RouterOS.
Этот 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, но ответа так и не было.
29.08.2017 21:29:00, ZeroByte.]]> http://mikrotik.moscow/forum/forum57/86876-arp-taymaut/message411219 http://mikrotik.moscow/forum/forum57/86876-arp-taymaut/message411219 Tue, 29 Aug 2017 21:29:00 -0400 RouterOS ARP Таймаут RouterOS в форуме RouterOS.
У нас сегодня была похожая проблема. RB3011 с версией 6.39.1. Ноутбук подключался к точкам доступа и получал от DHCP-сервера IP 172.16.1.19 или 172.16.1.20. Клиент мог отправлять arping на 172.16.0.1, но пинга не было, и Mikrotik тоже отправлял arping клиенту без ответа (фаерволы были выключены). В какой-то момент я заметил, что мой arping возвращает другой MAC-адрес, чем в записях ARP, но тогда я этому не придал значения. Проблема решилась, когда ноутбуку дали статический IP 172.16.1.21. Через несколько часов я смог глубже разобраться и увидел, что для этих двух IP в ARP есть записи, но я проверил все L2-коммутаторы — ни на одном порту не было записей с этими двумя MAC-адресами. Я пытался пинговать их, arping’овать — без результата. После этого я отключил и включил мост, что в итоге очистило ARP-записи. В логах я увидел, что эти MAC-адреса запрашивали DHCP, и сервер выдал им .11 и .18. Я знаю, что эти MAC-адреса принадлежат техникам на объекте, так что это не какие-то посторонние устройства.
29.08.2017 20:25:00, aviper.]]> http://mikrotik.moscow/forum/forum57/86876-arp-taymaut/message411218 http://mikrotik.moscow/forum/forum57/86876-arp-taymaut/message411218 Tue, 29 Aug 2017 20:25:00 -0400 RouterOS ARP Таймаут RouterOS в форуме RouterOS.
Не знаю, решалась ли уже эта проблема, у меня была похожая ситуация. У нас есть статическая подсеть 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
29.08.2017 05:28:00, homerwsmith.]]> http://mikrotik.moscow/forum/forum57/86876-arp-taymaut/message411217 http://mikrotik.moscow/forum/forum57/86876-arp-taymaut/message411217 Tue, 29 Aug 2017 05:28:00 -0400 RouterOS ARP Таймаут RouterOS в форуме RouterOS.
Итак, немного дополнительной детективной работы. Мы настроили новый роутер, подключили его к сети, назначили статический IP-адрес 10.10.20.244. Запись появилась в ARP-таблице. Отключаем роутер. В первый раз, когда я это попробовал, запись исчезла. Во второй — запись осталась (с MAC-адресом), но через некоторое время флаг «C» (Complete) сбросился, и в итоге запись пропала из таблицы. Если теперь пропинговать 10.10.20.244, запись снова появляется в ARP-таблице, но уже с MAC-адресом 00:00:00:00:00:00 и пометкой «D» (Dynamic), но без «Complete».

Я считаю, что это нормальное поведение, и запись с 00:00:00:00:00:00 через примерно пять минут очищается службой сборщика мусора. В ARP-таблице есть 10.10.20.181 с прежним MAC-адресом, хотя этот роутер уже отключён.

Проверил пингом 10.10.20.181 с CCR — время ожидания истекло, либо «host unreachable». Вручную удаляю запись из таблицы — она сразу же появляется снова, с флагом «D» (Dynamic), но без «C» (Complete), а MAC теперь 00:00:00:00:00:00.

Так что кто-то пингует 10.10.20.181? И если да, то почему ARP-таблица держит старый MAC-адрес с флагом «C» (Complete), вместо того чтобы заменить его на 00:00:00:00:00:00?

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

CCR работает на версии 6.38.5. Планирую обновиться до 6.39.2 ночью.
23.07.2017 20:52:00, Bivvy.]]> http://mikrotik.moscow/forum/forum57/86876-arp-taymaut/message411216 http://mikrotik.moscow/forum/forum57/86876-arp-taymaut/message411216 Sun, 23 Jul 2017 20:52:00 -0400 RouterOS ARP Таймаут RouterOS в форуме RouterOS.
Я не могу воспроизвести это у себя. Даже если IP находится в неполном состоянии в таблице ARP, как только устройство получает свой IP от DHCP, запись в ARP обновляется, и устройство сразу же получает доступ к сети.
23.07.2017 19:29:00, Cha0s.]]> http://mikrotik.moscow/forum/forum57/86876-arp-taymaut/message411215 http://mikrotik.moscow/forum/forum57/86876-arp-taymaut/message411215 Sun, 23 Jul 2017 19:29:00 -0400 RouterOS ARP Таймаут RouterOS в форуме RouterOS.
Интересно, действительно ли это связано с DHCP. Похоже на то, но было бы здорово это доказать. Возможно, стоит попробовать запустить отдельный DHCP-сервер. Я использую ISC DHCP-сервер. У меня нет проблем с ARP, но и сеть у меня небольшая.
23.07.2017 19:08:00, acruhl.]]> http://mikrotik.moscow/forum/forum57/86876-arp-taymaut/message411214 http://mikrotik.moscow/forum/forum57/86876-arp-taymaut/message411214 Sun, 23 Jul 2017 19:08:00 -0400 RouterOS ARP Таймаут RouterOS в форуме RouterOS.
Похоже, у нас наблюдается похожая проблема — но, кажется, она только-только началась. У нас настроен 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 на всех интерфейсах установлен по умолчанию.

Есть идеи? Мы успешно проделали такой процесс для нескольких клиентов, переключённых на оптику, но последние пару недель эта проблема вылезает. Спасибо!
23.07.2017 13:08:00, Bivvy.]]> http://mikrotik.moscow/forum/forum57/86876-arp-taymaut/message411213 http://mikrotik.moscow/forum/forum57/86876-arp-taymaut/message411213 Sun, 23 Jul 2017 13:08:00 -0400 RouterOS ARP Таймаут RouterOS в форуме RouterOS.
Для тех, кому это нужно, вот ответ, который я получил от поддержки Mikrotik:

Поддержка:  
_В RouterOS, как и в других Linux-системах, неполные записи ARP появляются, когда с маршрутизатора нельзя достучаться до нужного IP-адреса. По поводу такой неполной записи нужно учитывать два разных таймаута. Если запись не использовалась и устарела в течение X секунд (arp-timeout), её можно удалить. Если прошло X секунд, и запись помечена как подлежащая удалению, она будет удалена, когда заработает сборщик мусора (обычно через Y секунд). Так работает идеально и удаляет неполные записи ARP за несколько секунд.  
Проблема в том, что запись соседа не удаляется, если на неё есть ссылка. Основная сложность — ссылка из IPv4 таблицы маршрутизации. Там много сложностей со сбором мусора, но важно понять, что сборщик мусора для кэша маршрутов удаляет записи только раз в 5 минут. В итоге ARP-запись исчезает только через 5–10 минут. Если вы хотите этого избежать, нужно в “IP/Settings” отключить route-cache и перезагрузить роутер. Хотя роутер выдал DHCP-аренду и ARP-таблица указывает на нулевой MAC, при начале общения запись ARP сразу обновляется с правильным MAC, и ни один пакет не идёт в никуда — это проверено._  

Вопрос: Вы говорите, что даже если никто и ничто не ссылается на конкретный IP (прошло X секунд) и запись ARP помечена к удалению, всё равно должно пройти Y секунд, прежде чем сборщик мусора в ОС действительно удалит запись?  

Поддержка: Да, именно так. Это помогает избежать лишней нагрузки на процессор, если таблица маленькая и особо в плане памяти это не помогает.  

Вопрос: …А если так, и это связано с кэшем маршрутов, то как это повлияет на общую производительность маршрутизации, если я попробую его отключить?  

Поддержка: Отключение кэша маршрутов не позволяет использовать функцию Fast Path, поэтому не рекомендуется. Нам не известно о каких-либо багах, связанных с этим.
31.05.2017 11:23:00, k007.]]> http://mikrotik.moscow/forum/forum57/86876-arp-taymaut/message411212 http://mikrotik.moscow/forum/forum57/86876-arp-taymaut/message411212 Wed, 31 May 2017 11:23:00 -0400 RouterOS ARP Таймаут RouterOS в форуме RouterOS.
Может, вопрос и глупый, но я всё же спрошу. Похоже, что таймаут ARP в настройках IP игнорируется. Сейчас стоит значение по умолчанию с завода — 30 секунд. Спрашиваю потому, что столкнулся с такой ситуацией:

CCR1016-12G, RouterOS 6.39 (stable), WAN на eth1, LAN на eth2 (srcnat, никаких правил файрвола еще нет). DHCP-сервер на eth2 с подсетью 192.168.0.x/24 (IP-пул ограничен 192.168.0.10–192.168.0.240), при этом есть несколько статических аренды. Интерфейс eth2 в режиме ARP "enabled", то же и eth1. В DHCP включена опция "Add ARP For Leases" (хотя, кажется, она особо не влияет на эту ситуацию).

Проблема в том, что один DHCP-клиент со статической арендой не получает внешнее соединение (WAN1, то есть нет интернета). Немного покопавшись, выяснил, что его статический IP из DHCP-аренды – .154, но в ARP-таблице для этого IP стоит MAC с нулями (00:00:00…). Очистка записи в ARP всё решила. Но я пошёл дальше и нашёл другие темы по этой проблеме (а может, это просто особенность) — например, "arp - show incomplete ARP entries" в версии 6.33.5 ROS.

Пинг с LAN на несуществующий IP создает в ARP-запись с MAC 00:00:00:00:00:00 — это нормально, так MikroTik сообщает, что такого IP нет в LAN (в отличие, скажем, от Cisco). Но моя главная проблема — как сделать так, чтобы ARP-запись исчезала гораздо быстрее, чем сейчас? Потому что сейчас, похоже, она живёт не секунды, а минуты, несмотря на то, что в IP->Settings->ARP Timeout указан 30 секунд.

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

Проверял с любым невыделенным IP — результат тот же, и я почти уверен, что в LAN нет внутреннего сканирования или прослушивания.

Статические ARP-записи и режим ARP reply-only для меня не выход. Хочу, чтобы работали статические DHCP-аренды и динамические, а также статические IP на LAN-клиентах.

Кто-нибудь может подсказать в правильном направлении? Что я упускаю? Почему RouterOS так долго очищает несуществующую IP-MAC ARP-запись и не делает это за 30 секунд, как указано в настройках?
15.05.2017 11:46:00, k007.]]> http://mikrotik.moscow/forum/forum57/86876-arp-taymaut/message411211 http://mikrotik.moscow/forum/forum57/86876-arp-taymaut/message411211 Mon, 15 May 2017 11:46:00 -0400 RouterOS