maverick5 Опубликовано 30 августа, 2020 Здравствуйте! Имеется часть неуправляемой сети куда еще не дошел апгрейд. Примерно в одно и тоже время в ней возникает жесткий флуд. У клиентов дикие потери пакетов. Как-то можно попытаться отследить флудящую абонентскую железку в этом куске (mac, ip)? Включил один порт сервера на линуксе в эту сетку. Запускаю tcpdump на этом интерфейсе но, честно говоря, не знаю толком что там смотреть и на что обратить внимание. Может посоветуете что? Спасибо! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
micol Опубликовано 30 августа, 2020 (изменено) iftop jnettop Изменено 30 августа, 2020 пользователем micol Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
maverick5 Опубликовано 30 августа, 2020 32 минуты назад, micol сказал: iftop jnettop Спасибо! Установил iftop. Флуд закончился к сожалению уже ))) К счастью! Каждый вечер примерно с 21 до 00 часов. Запускаю эту утилиту на нужном интерфейсе - вижу список соединений. А как самого флудера здесь увидеть? Если это конечно возможно... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pingz Опубликовано 31 августа, 2020 @maverick5 боль Сегмент сети большой? Схема сети? Бюджет на апгрейд если рассматривать 1 управляемый +1-2 не управляемых? Нужно уточнить флуд это или петля. Тут уже нужно понять, кто флудит клиент или сам коммутатор. Если железо позволяет, пограничное оборудование может сыпать в лог о петле. Либо включить stp на порту в который смотрит в сторону этого сегмента, либо смотреть онлайн на мак таблицу. Обычно в таких ситуациях ищю проблему по графикам загруженности портов. Если есть возможность заходить на оборудование, отключа исходящие порты либо физически нужно попасть. + Сеть сегментированна на куски сразу видно в каком р-не проблема. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
maverick5 Опубликовано 31 августа, 2020 1 час назад, pingz сказал: @maverick5 боль Сегмент сети большой? Схема сети? Бюджет на апгрейд если рассматривать 1 управляемый +1-2 не управляемых? Нужно уточнить флуд это или петля. Тут уже нужно понять, кто флудит клиент или сам коммутатор. Если железо позволяет, пограничное оборудование может сыпать в лог о петле. Либо включить stp на порту в который смотрит в сторону этого сегмента, либо смотреть онлайн на мак таблицу. Обычно в таких ситуациях ищю проблему по графикам загруженности портов. Если есть возможность заходить на оборудование, отключа исходящие порты либо физически нужно попасть. + Сеть сегментированна на куски сразу видно в каком р-не проблема. Сегодня вечером буду смотреть. Примерно в 9 вечера начинается... Апгрейд делаем, строим PON. Там частный сектор на мыльницах. Может кто и петлю делает (случайно или специально) Если бы железо, то наверное проявлялось бы постоянно... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pingz Опубликовано 31 августа, 2020 @maverick5 у меня было пару коммутаторов которые начинали флулить, когда на подгоревшем порту появлялся клиент, или появлялась нагрузка. То же стояли не управляемые, но я больше 1-3 не подключал в порт на управляемый. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ayf Опубликовано 31 августа, 2020 1 час назад, pingz сказал: @maverick5 у меня было пару коммутаторов которые начинали флулить, когда на подгоревшем порту появлялся клиент, или появлялась нагрузка. То же стояли не управляемые, но я больше 1-3 не подключал в порт на управляемый. Есть такое. И у роутеров-мыльниц тоже встречалось. ТС, есть путь долгий и короткий. Долгий - отключать компы по одному и следить. Короткий - поставить управляемый коммутатор, хотя бы на время. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 6 сентября, 2020 В 30.08.2020 в 23:41, maverick5 сказал: Как-то можно попытаться отследить флудящую абонентскую железку в этом куске (mac, ip)? Конечно, подключаете к сети микротик и во время флуда через торч смотрите что идет, а через снифер можно маки посмотреть. А если микротик поставить в разрыв, то можно увидеть откуда корни растут. Если взять вариант что не флуд полный что забивает порты, а что попроще, то при наличии флуда по АРП как раз и будут потери, хотя сам канал может быть и не загружен в полку. Тут нужно сделать так, что бы до сервера не прилетал этот мусор, вручную прибить арп записи клиентов, если используется IP для транспорта. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nemo_lynx Опубликовано 8 сентября, 2020 В 30.08.2020 в 23:41, maverick5 сказал: Включил один порт сервера на линуксе в эту сетку. Запускаю tcpdump на этом интерфейсе но, честно говоря, не знаю толком что там смотреть и на что обратить внимание. Может посоветуете что? Найдите того, кто знает на что смотреть в дампе трафика флуда. На самом деле, там вероятнее всего будет просто море пакетов с самыми разными МАС и IP, которые и спецу мало о чём скажут. Мусор, он и Африке мусор. Если у вас под рукой нет умного свича, самый простой способ вычислить источник беды - методично по порядку отключать порты и смотреть, остановился флуд или нет. Если сегмент имеет структуру ветвления, начинайте с отключения портов в свиче, самом близком к ядру (агрегация). Далее постепенно локализуете источник беды до крайнего свича на доступе. Источником может быть как сам свичь, так и абонент в его порту. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...