Arp -таблица в микротике с mac-address! = "00: 00: 00: 00: 00: 00"

[uraso]

   Привет всем!!!!

 Имеется  безпроводная сеть.  Клиенты подключены  микротиками SXT2 и   UBIQUITY  разных  типов . Все клиентские девайсы  настроены в режиме роутеров. Сеть пока не сегментирована. Трафик распределятся  с помощью RB750Gr3 .  Прошивка   v.6.37.5 (bugfix).   На  RB750Gr3 arp -таблицe заполняется   мак-адресами = 00: 00: 00: 00: 00: 00.

Это просходит преимущественно вечером, когда увеличивается  потребление трафика  и нагрузка на оборудование.

Edited September 21, 2017 by uraso

[Fint]

Присоединяюсь к вопросу. Такая же проблема, но только в одном сегменте сети. 48 ip адресов при 14 абонентах.

 

А хотя нет, вот в некоторых сетях еще есть.

[nkusnetsov]

Нули - это результат неразрешенного MAC-адреса. Неудачный ARP-запрос.
Кто-то в сети или извне, возможно пытается сканировать сеть за роутером или флудит пакетами.

[uraso]

Ну что же , так пока причины и не определил.  Нашел по макам три клиентских SXT2 с включенным IPV6.    Отключил эту  службу.  IPV6 перестал  светится при торче на неиспользованных IP.   Но  протоколы  806 (arp) и 802.2 все равно

продолжают атаковать ARP  таблицу.

[uraso]

Как я  понял  спасение утопающих -дело рук самих утопающих.....

После многочасового копания в гогле собрал несколько разрозненную информацию  об этой неисправности

 

https://local.com.ua/forum/topic/85623-проблема-с-динамическими-arp-записями/

 

https://forum.mikrotik.com/viewtopic.php?t=108196

https://translate.google.com.ua/translate?hl=ru&sl=en&u=https://forum.mikrotik.com/viewtopic.php%3Ft%3D108196&prev=search

 

Советуют проверить безпроводные мосты....  Офсайт ничего конкретно не предлагает...

[777BLOODER777]

беспроводные 

[Барагоз]

В 23.09.2017 в 19:44, nkusnetsov сказал:

Кто-то в сети или извне, возможно пытается сканировать сеть за роутером или флудит пакетами.

Достаточно просто пропинговать отсутствующий IP из подсети, в которой микротик находится.

 

В 24.09.2017 в 12:02, uraso сказал:

После многочасового копания в гогле собрал несколько разрозненную информацию  об этой неисправности

Это вообще не неисправность микротика, это в 6 версии так отображается арп таблица )

Откуда у вас в сети трафик на оффлайн хосты - ну разбирайтесь, если есть желание, микротик тут не виноват.

[uraso]

Я согласен что это  не неисправность микротика.... но как  определить откуда идет трафик на  эти оффлайн хосты ?

Поставил традиционный  reply-only  на бридж.  Трафик перестал отображаться.

 

 

[Saab95]

Определить можно через торч на этом интерфейсе, он покажет от кого идут запросы.

[yKpon]

апну! аналогичная вещь наблюдается в сети, преимущественно вечером, нулевые маки

https://gyazo.com/22e46ac04daa61bfc797281b3df2719b

 

stp везде отключен

 

ip адреса существующие, начинаешь пинговать пару хопов анричибл, потом ок

хелп!!!

 

https://gyazo.com/efc01ced0c8ec4feb9f3926b91b89044

 

https://gyazo.com/165e0e840f663b5487cdf336e3fd7223

[agent2011]

В 20.02.2018 в 23:14, yKpon сказал:

апну! аналогичная вещь наблюдается в сети, преимущественно вечером, нулевые маки

https://gyazo.com/22e46ac04daa61bfc797281b3df2719b

 

stp везде отключен

 

ip адреса существующие, начинаешь пинговать пару хопов анричибл, потом ок

хелп!!!

 

https://gyazo.com/efc01ced0c8ec4feb9f3926b91b89044

 

https://gyazo.com/165e0e840f663b5487cdf336e3fd7223

 

Может быть у Вас коллизия МАК адресов? при большом кол-ве абонентов. Я столкнулся с этим недавно.

Сеть у нас изолированная, каждый абонент видит только сервер доступа. Установили новую базу в новом сегменте локальном, база пустая была, но по статистике видели что какой-то непонятный трафик на нее летит по Езернет порту. Посмотрели снифером, оказалось что этот трафик каким то образом передают абоненты из другого локального сегмента. Изолированного причем.

Написал тему на форуме микротиковском, показал схему сети, и оказалось что это была коллизия хэша мак адресов.

Попробуйте покапать в эту сторону.

Когда происходит эта коллизия трафик от этих абонентов начинает рассылаться на все порты коммутаторов превращая управляемый свич в тупой хаб.

[yKpon]

55 минут назад, agent2011 сказал:

Написал тему на форуме микротиковском, показал схему сети, и оказалось что это была коллизия хэша мак адресов.

Попробуйте покапать в эту сторону.

Когда происходит эта коллизия трафик от этих абонентов начинает рассылаться на все порты коммутаторов превращая управляемый свич в тупой хаб.

честно говоря в голову тогда так и не пришли разумные решения, спустя 3 часа всё постепенно успокоилось само

да я уверен что тут что-то на уровне маков, но как и чем копать?

 

L2 влан управления 10.1.0.0/16

L3 подсеть 10.100.0.0/16, на ней OSPF, в Neighbors на данный момент 80 роутеров, это сектора и тики на многоквартирных домах терминирующие рррое

[agent2011]

11 часов назад, yKpon сказал:

честно говоря в голову тогда так и не пришли разумные решения, спустя 3 часа всё постепенно успокоилось само

да я уверен что тут что-то на уровне маков, но как и чем копать?

 

L2 влан управления 10.1.0.0/16

L3 подсеть 10.100.0.0/16, на ней OSPF, в Neighbors на данный момент 80 роутеров, это сектора и тики на многоквартирных домах терминирующие рррое

Есть ли у Вас свичи 3028 ? они самые уязвимые к этой проблеме.

И обычные мыльницы неуправляемые тоже.

Не видели таких проблем на коммутаторах серии DGS, даже на самых простых моделях.

 

Когда абонентов было не много, они у нас работали даже на магистралях, а когда маков на таком свиче переваливает за 60-80 - начинаются проблемы о которых я описал Выше.
Если есть 3028, подключитесь по телнету и введите:

enable flood_fdb

немного подождите, минутку например и введите

show flood_fdb

 

увидите таблицу вида:

 

1480 1 28-10-7B-BC-A8-DA * 398101
1480 1 6C-3B-6B-C6-0F-DF 398101
6391 1 00-13-49-E7-B8-26 * 398097
6391 1 6C-3B-6B-CE-9A-A0 398097
6589 1 68-72-51-4A-2F-D4 * 398098
6589 1 6C-3B-6B-3B-96-9F 398098

 

Те мак адреса, что НЕ помечены звездочкой и есть те адреса который рассылают трафик на все порты всей сети.

 

На другом форуме, сделав описание сети и нарисовав схему, буквально в течении часа подсказали мне в чем дело.

 

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

 

http://xcme.blogspot.ru/2014/11/hash.html вот тема с тестированием свичей длинка на предмет данной уязвимости.

 

Я могу конечно ошибаться и показывать Вам не то направление куда нужно ковырять, но мало ли :-)

Edited March 6, 2018 by agent2011

[yKpon]

@agent2011 благодарю за столь подробный ответ

свитчи DGS-1100-05 (08)

 

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

 

 

[uraso]

В чем же все таки истинная причина возникновения этих коллизий? У меня на базах стоят микротики  RB750UP и RB960PGS

(hEX PoE) ...   Есть ли подобная команда enable flood_fdb   у микротиков? 

[agent2011]

В 30.03.2018 в 07:35, uraso сказал:

В чем же все таки истинная причина возникновения этих коллизий? У меня на базах стоят микротики  RB750UP и RB960PGS

(hEX PoE) ...   Есть ли подобная команда enable flood_fdb   у микротиков? 

Врятли, эти команды сделали на d-linkaх для выявления подобных проблем, и то только для проблемных моделей.

 

Мне хотелось бы еще раз подчеркнуть тот факт, что это было лишь мое предположение по проблеме.