Проблема с динамическими ARP-записями

[jcomm 6]

Доброго времени суток. Возникла проблема с RouterOS v6.35 x86. Добавляются динамически arp-записи для всех подсетей на микротике с маками 00:00:00:00:00:00. Естественно, убираются с помощью reply-only ARP на интерфейсах, но использовать не получается, в связи с использованием UHW. Трафик пользователей бегает без проблем, но эти записи настораживают. То же самое было до обновления с 6.3.5.

 

Что это может быть и как это побороть.

 

UPD: За микротиком стоит DES-3200-28F, думал какие-то защиты, но нет. Всё, что связано с DHCP отключено.

 

UPD: Микротик настроен DHCP-relay'ем на сервер. Из динамических подсетей только UHW, всё остальное статика.

Відредаговано 2016-04-18 14:59:05 jcomm

[Golthana 3]

Беспроводные мосты есть у Вас?

[jcomm 6]

Беспроводные мосты есть у Вас?

Есть. Перед сервером. Точка-точка на MikroTik RB411GL.

[Golthana 3]

А wds включен на Микротах? Если нет, то попробуйте включить

[jcomm 6]

А wds включен на Микротах? Если нет, то попробуйте включить

WDS включен. До этого, стоящий RB2011LS-IN не делал такой гадости.

[Golthana 3]

WDS включен.

Тогда затрудняюсь ответить. У меня такая проблема была решена с помощью wds

 

А 10.0.0.0 я так понимаю не гостевая сеть, а абонентская

Відредаговано 2016-04-18 15:13:10 Golthana

[jcomm 6]

А 10.0.0.0 я так понимаю не гостевая сеть, а абонентская

Да, абонентская. 10.0.0.0, 10.0.1.0, 10.0.2.0 и т.д - это абонентские и для всех подсетей создаются такие записи от 1 до 254.

Відредаговано 2016-04-18 15:18:17 jcomm

[Golthana 3]

Извините за такой вопрос, а wds точно поднимается?

[jcomm 6]

Извините за такой вопрос, а wds точно поднимается?

Точно. Мост работает без нареканий.

[jcomm 6]

Либо я что-то не понимаю, либо лыжи не едут. Вот changelog микротика.

What's new in 6.33.5 (2015-Dec-28 09:13):

...
*) arp - show incomplete ARP entries;
...

Объясните, пожалуйста, что такое неполные ARP-записи? Для чего они нужны? Суда по changelog'у оно так и должно показываться. Тогда почему на все пользовательские подсети такое появляется?

[jcomm 6]

Тогда почему на все пользовательские подсети такое появляется?

Да, и в этом разобрался. Лыжи поеали. Вот эти "incomplete ARP entries" появляются из-за вызова fullhostscan из remoteapi юбиллинга.

 

Вывод: так должно быть, надо было читать внимательнее changelog RouterOS.

 

Короче говоря, тема закрыта. Всем спасибо.

Відредаговано 2016-04-18 15:54:07 jcomm

[Golthana 3]

 

 

уда по changelog'у оно так и должно показываться.

 

Попробуйте откатить обратно и сравните результат

[jcomm 6]

Попробуйте откатить обратно и сравните результат

Очевидно же, что на версиях > 6.3.5 этой "фичи" не будет.

Відредаговано 2016-04-18 15:53:59 jcomm

[KaYot 3 705]

Вообще это больше похоже на unresolved ARP записи, кто-то из клиентов сканирует сеть и забивает мусором роутер.

 

p.s. прочитал ваш пост выше про 'arp - show incomplete ARP entries' - оно и есть. Просто раньше эти записи МТ не показывал вообще, а теперь показывает как 00:00

Бороться с этим нельзя, да и ничего лишние записи не делают - максимум ARP-таблицу могут забить, вот тогда надо будет лечить любителя сканеров.

Відредаговано 2016-04-18 15:51:10 KaYot

[jcomm 6]

кто-то из клиентов сканирует сеть и забивает мусором роутер.

Это не кто-то из клиентов, а вызов fullhostscan из remoteapi юбиллинга. А там nmap сканирует все пользовательские подсети на наличие живых душ.

Відредаговано 2016-04-18 15:55:31 jcomm

[KaYot 3 705]

вызов fullhostscan из remoteapi юбиллинга

Ну тогда это жесткая тупость в биллинге, нельзя так делать

А если подсеть будет /16? Легко можно переполнить ARP-table маршрутизаторам и иметь жестокие потери пакетов во время сканирования.

[Golthana 3]

 

 

fullhostscan из remoteapi юбиллинга.

 

Точно

[nightfly 1 237]

Белки истерички млять.

 

Обисняю доходчиво:

 

Ну бывают себе incomplete arp records. Да - это те, на которые не пришло ответа на arp request who-has.

$ arp -a | grep incomplete | tail -n 1
? (172.30.6.11) at (incomplete) on igb0 expired [ethernet]
$ arp -a | grep incomplete | wc -l
      65
$

Нет, на любой запрос не получивший в результате адекватного who-has reply - порождает одну такую incomplete arp запись. Да - это нормально.

Они устаревают на общих основаниях относительно net.link.ether.inet.max_age.

 

И нет, вызовы fullhostscan раз в час - строго опциональны, сканирование хостов (да, traffdiff там доминирующая парадигма) на живость там - тоже в общем-то тоже строго опционально. Фантазеры-теоретики рассказывающие о том как надо писать биллинги - перманентно идут наxyй. Их поучения и невъебенная концептуальность - все так же остаются никому не нужными, и не существующими в реальном мире фантазиями.

Відредаговано 2016-04-18 16:29:07 nightfly

[KaYot 3 705]

О, ссыкун-быдлокодер тут же нарисовался.

Угу, кривое и ненужное говно в биллинг должно быть и ничего плохого в нем нет. Все правильно.

[nightfly 1 237]

О, ссыкун-быдлокодер тут же нарисовался.

Угу, кривое и ненужное говно в биллинг должно быть и ничего плохого в нем нет. Все правильно.

Не. Походу тебя уебка нужно в твое же говно тыкать мордочкой ежегодно -  вот, пожалуйста.

[zubow12 0]

 

О, ссыкун-быдлокодер тут же нарисовался.

Угу, кривое и ненужное говно в биллинг должно быть и ничего плохого в нем нет. Все правильно.

Не. Походу тебя уебка нужно в твое же говно тыкать мордочкой ежегодно -  вот, пожалуйста.

 

Приветствую тебя Citizens (не общались с 2012г  )

проблемма анологичная (1 пост)

но ip с 0 маками не исчезают (основные - т.е. ip сервера и микротика)

последствия - через каждые 5-10мин у всех абонентов исчезает интернет.

[Golthana 3]

 

 

но ip с 0 маками не исчезают

Запускайте скрипт каждые 30 секунд, например, и удаляйте эти записи. 

[Dmitry2 2]

1. На свиче желательно настроить arp spoofing prevention

2. На свиче желательно настроить ACL, чтобы клиенты не могли слать ARP и IP запросы на другие клиентские IP

3. На свиче желательно настроить запрет пересылки паразитного broadcast, multicast и unicast трафика на микротик.

 

А также современные свичи отлично умеют dhcp snooping и dhcp screening

 

Простой пример.

У нас шлюз 192.168.0.1 с MAC адресом 00:11:22:33:44:55:66

 

Делаем правило, разрешающие в ARP запросах запрашивать MAC адрес только у IP 192.168.0.1 (MAC адрес пентагона нам не нужен)

Делаем правило, разрешающее посылку всех юникаст пакетов только на MAC адрес 00:11:22:33:44:55:66.

Відредаговано 2017-02-16 19:10:45 Dmitry2

[uraso 0]

Dmitry2

 

 

 

1. На свиче желательно настроить arp spoofing prevention 2. На свиче желательно настроить ACL, чтобы клиенты не могли слать ARP и IP запросы на другие клиентские IP 3. На свиче желательно настроить запрет пересылки паразитного broadcast, multicast и unicast трафика на микротик. А также современные свичи отлично умеют dhcp snooping и dhcp screening

 

Можно ето

 

Простой пример. У нас шлюз 192.168.0.1 с MAC адресом 00:11:22:33:44:55:66 Делаем правило, разрешающие в ARP запросах запрашивать MAC адрес только у IP 192.168.0.1 (MAC адрес пентагона нам не нужен) Делаем правило, разрешающее посылку всех юникаст пакетов только на MAC адрес 00:11:22:33:44:55:66.

Обьясните  пожалуйста чуть подробней. Можно эти  правила применить в Bridge Filters  для  Forvard на мосте.