Перейти до

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


Рекомендованные сообщения

Доброго времени суток. Возникла проблема с 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, всё остальное статика.

post-24813-0-49315800-1460991244_thumb.png

Відредаговано jcomm
Ссылка на сообщение
Поделиться на других сайтах

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

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

Ссылка на сообщение
Поделиться на других сайтах
WDS включен.

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

 

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

Відредаговано Golthana
Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)

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

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

Відредаговано jcomm
Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)

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

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

 

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

 

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

Відредаговано jcomm
Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)

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

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

Відредаговано jcomm
Ссылка на сообщение
Поделиться на других сайтах

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

 

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

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

Відредаговано KaYot
Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)

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

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

Відредаговано jcomm
Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

Ну бывают себе 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й. Их поучения и невъебенная концептуальность - все так же остаются никому не нужными, и не существующими в реальном мире фантазиями.

Відредаговано nightfly
Ссылка на сообщение
Поделиться на других сайтах

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

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

Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Ссылка на сообщение
Поделиться на других сайтах
  • 9 months later...

 

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

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

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

 

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

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

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

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

Ссылка на сообщение
Поделиться на других сайтах
  • 2 weeks later...

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.

Відредаговано Dmitry2
Ссылка на сообщение
Поделиться на других сайтах
  • 2 months later...

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 на мосте.

Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Вхід

Уже зарегистрированы? Войдите здесь.

Войти сейчас
  • Зараз на сторінці   0 користувачів

    Немає користувачів, що переглядають цю сторінку.

  • Схожий контент

×
×
  • Створити нове...