uraso Опубликовано 21 сентября, 2017 (изменено) · Жалоба Привет всем!!!! Имеется безпроводная сеть. Клиенты подключены микротиками SXT2 и UBIQUITY разных типов . Все клиентские девайсы настроены в режиме роутеров. Сеть пока не сегментирована. Трафик распределятся с помощью RB750Gr3 . Прошивка v.6.37.5 (bugfix). На RB750Gr3 arp -таблицe заполняется мак-адресами = 00: 00: 00: 00: 00: 00. Это просходит преимущественно вечером, когда увеличивается потребление трафика и нагрузка на оборудование. Изменено 21 сентября, 2017 пользователем uraso Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Fint Опубликовано 22 сентября, 2017 · Жалоба Присоединяюсь к вопросу. Такая же проблема, но только в одном сегменте сети. 48 ip адресов при 14 абонентах. А хотя нет, вот в некоторых сетях еще есть. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nkusnetsov Опубликовано 23 сентября, 2017 · Жалоба Нули - это результат неразрешенного MAC-адреса. Неудачный ARP-запрос. Кто-то в сети или извне, возможно пытается сканировать сеть за роутером или флудит пакетами. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
uraso Опубликовано 23 сентября, 2017 · Жалоба Ну что же , так пока причины и не определил. Нашел по макам три клиентских SXT2 с включенным IPV6. Отключил эту службу. IPV6 перестал светится при торче на неиспользованных IP. Но протоколы 806 (arp) и 802.2 все равно продолжают атаковать ARP таблицу. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
uraso Опубликовано 24 сентября, 2017 · Жалоба Как я понял спасение утопающих -дело рук самих утопающих..... После многочасового копания в гогле собрал несколько разрозненную информацию об этой неисправности 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 Советуют проверить безпроводные мосты.... Офсайт ничего конкретно не предлагает... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
777BLOODER777 Опубликовано 24 сентября, 2017 · Жалоба беспроводные Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Барагоз Опубликовано 6 октября, 2017 · Жалоба В 23.09.2017 в 19:44, nkusnetsov сказал: Кто-то в сети или извне, возможно пытается сканировать сеть за роутером или флудит пакетами. Достаточно просто пропинговать отсутствующий IP из подсети, в которой микротик находится. В 24.09.2017 в 12:02, uraso сказал: После многочасового копания в гогле собрал несколько разрозненную информацию об этой неисправности Это вообще не неисправность микротика, это в 6 версии так отображается арп таблица ) Откуда у вас в сети трафик на оффлайн хосты - ну разбирайтесь, если есть желание, микротик тут не виноват. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
uraso Опубликовано 7 октября, 2017 · Жалоба Я согласен что это не неисправность микротика.... но как определить откуда идет трафик на эти оффлайн хосты ? Поставил традиционный reply-only на бридж. Трафик перестал отображаться. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 7 октября, 2017 · Жалоба Определить можно через торч на этом интерфейсе, он покажет от кого идут запросы. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
yKpon Опубликовано 20 февраля, 2018 · Жалоба апну! аналогичная вещь наблюдается в сети, преимущественно вечером, нулевые маки https://gyazo.com/22e46ac04daa61bfc797281b3df2719b stp везде отключен ip адреса существующие, начинаешь пинговать пару хопов анричибл, потом ок хелп!!! https://gyazo.com/efc01ced0c8ec4feb9f3926b91b89044 https://gyazo.com/165e0e840f663b5487cdf336e3fd7223 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
agent2011 Опубликовано 6 марта, 2018 · Жалоба В 20.02.2018 в 23:14, yKpon сказал: апну! аналогичная вещь наблюдается в сети, преимущественно вечером, нулевые маки https://gyazo.com/22e46ac04daa61bfc797281b3df2719b stp везде отключен ip адреса существующие, начинаешь пинговать пару хопов анричибл, потом ок хелп!!! https://gyazo.com/efc01ced0c8ec4feb9f3926b91b89044 https://gyazo.com/165e0e840f663b5487cdf336e3fd7223 Может быть у Вас коллизия МАК адресов? при большом кол-ве абонентов. Я столкнулся с этим недавно. Сеть у нас изолированная, каждый абонент видит только сервер доступа. Установили новую базу в новом сегменте локальном, база пустая была, но по статистике видели что какой-то непонятный трафик на нее летит по Езернет порту. Посмотрели снифером, оказалось что этот трафик каким то образом передают абоненты из другого локального сегмента. Изолированного причем. Написал тему на форуме микротиковском, показал схему сети, и оказалось что это была коллизия хэша мак адресов. Попробуйте покапать в эту сторону. Когда происходит эта коллизия трафик от этих абонентов начинает рассылаться на все порты коммутаторов превращая управляемый свич в тупой хаб. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
yKpon Опубликовано 6 марта, 2018 · Жалоба 55 минут назад, agent2011 сказал: Написал тему на форуме микротиковском, показал схему сети, и оказалось что это была коллизия хэша мак адресов. Попробуйте покапать в эту сторону. Когда происходит эта коллизия трафик от этих абонентов начинает рассылаться на все порты коммутаторов превращая управляемый свич в тупой хаб. честно говоря в голову тогда так и не пришли разумные решения, спустя 3 часа всё постепенно успокоилось само да я уверен что тут что-то на уровне маков, но как и чем копать? L2 влан управления 10.1.0.0/16 L3 подсеть 10.100.0.0/16, на ней OSPF, в Neighbors на данный момент 80 роутеров, это сектора и тики на многоквартирных домах терминирующие рррое Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
agent2011 Опубликовано 6 марта, 2018 (изменено) · Жалоба 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 вот тема с тестированием свичей длинка на предмет данной уязвимости. Я могу конечно ошибаться и показывать Вам не то направление куда нужно ковырять, но мало ли :-) Изменено 6 марта, 2018 пользователем agent2011 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
yKpon Опубликовано 20 марта, 2018 · Жалоба @agent2011 благодарю за столь подробный ответ свитчи DGS-1100-05 (08) пол часа назад самопроизвольно снова посыпалась сеть, на одном доступно свитче, который в зоне паражения на данный момент 800 маков Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
uraso Опубликовано 30 марта, 2018 · Жалоба В чем же все таки истинная причина возникновения этих коллизий? У меня на базах стоят микротики RB750UP и RB960PGS (hEX PoE) ... Есть ли подобная команда enable flood_fdb у микротиков? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
agent2011 Опубликовано 4 апреля, 2018 · Жалоба В 30.03.2018 в 07:35, uraso сказал: В чем же все таки истинная причина возникновения этих коллизий? У меня на базах стоят микротики RB750UP и RB960PGS (hEX PoE) ... Есть ли подобная команда enable flood_fdb у микротиков? Врятли, эти команды сделали на d-linkaх для выявления подобных проблем, и то только для проблемных моделей. Мне хотелось бы еще раз подчеркнуть тот факт, что это было лишь мое предположение по проблеме. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
