Найти источник флуда в подсети (ex. Диагноз по tracepath)
>Я пускал tracepath до своего домашнего компьютера
IP-адрес домашнего компьютера предлагается угадать? Зачем портишь выводы команд?
IP-адрес домашнего компьютера предлагается угадать? Зачем портишь выводы команд?
Я замаскировал только IP-адрес самой машины. Что даст адрес моего домашнего компа? Проблема явно не с той стороны, поскольку любые соединение во вне и из вне у машины в МГУ разрываются и/или замедляются. Это происходит нечасто, но регулярно уже несколько лет и не зависит от местоположения моего домашнего компа, которое уже не раз сменилось.
Я замаскировал только IP-адрес самой машины. Что даст адрес моего домашнего компа?Ты forumbgz.ru/positive читал?
Паранойя тут совсем не к месту.Ты forumbgz.ru/positive читал?Читал, конечно, правда давно. Ну я рассказываю именно то, что происходит, а не то, что не происходит. Изымаю только то, в чём я полностью уверен, что это лишнее. Так как проблема наблюдается во всей подсети, то конкретная машина не имеет значения.Паранойя тут совсем не к месту.
Вот трейс до яндекса, чтобы исключить мой домашний комп:
EXCLUDED
Изымаю только то, в чём я полностью уверен, что это лишнееТы ошибаешься в том, что считать лишним.
Для примера взять два твоих вывода - в одном tracepath каким-то образом возвращается на localhost, в другом - остается в глубинах Яндекса. Мелочь, казалось бы, а вот без IP-адреса назначения в первом примере ничего путного придумать не выйдет.
Ты не привел команды, которую запускаешь, а тем временем, это может быть важно, ибо
~>host www.yandex.ru
www.yandex.ru has address 213.180.204.3
www.yandex.ru has address 213.180.193.3
www.yandex.ru has address 93.158.134.3
Какой из этих 3 адресов в реальности тебе ответил? Да и вообще, показывать PTRы в диагностиках - крайне вредно.
Далее, если число 4066.625ms в
www.yandex.ru 4066.625ms
- это RTT, то это, конечно, ужасно. Все остальные цифры в tracepath, скорее всего, ничего не означают от слова совсем.
Почему у тебя во втором трейсе нет 93.180.50.193, которого ты называешь default gw?
Я пускал tracepath до своего домашнего компьютера, но он вернулся на локалхост (xxx в пунктах 1 и 11 - один и тот же).не вернулся на локалхост, а локалохост ответил о невозможности посылки пакета
скорее всего, это связано с тем, что ближайший шлюз не ответил на arp - это хорошо согласуется с временем в 2-3 секунды - примерно столько обычно ждут ответа от arp
тогда логично предположить, что увеличение пинга связано с тормозами этого же шлюза, а циклы в выводе tracepath намекают на то, что тормозить шлюз запросто может от перегруза трафиком, который ходит по кругу
А как ты увязал неотвеченность ARP роутера (т.е. де-факто отсутствие шлюза) с остальными хопами явно вне L2-сегмента?
с остальными хопами явно вне L2-сегмента?vlan25 - я думаю это и есть шлюз - или нет, там же сказано, что .50.193 шлюз, и он в выводе есть
надо конечно всегда использовать -n
а циклы в выводе tracepathА почему ты думаешь, что там циклы? Вроде на разных "глубинах" нет одинаковых адресов.
ok, я отредактировал свои посты добавил все адреса и команды.
Почему у тебя во втором трейсе нет EXCLUDED, которого ты называешь default gw?Он там есть, просто в виде dns-имени: vlan25.phys.msu.ru
EXCLUDED
надо конечно всегда использовать -nСейчас пинг гораздо лучше (к сожалению
), но всё равно неудовлетворительный. Вот вывод с -n:
EXCLUDED
вместо этой непонятной штуки можно просто начать с пинга шлюза
EXCLUDED
WiFi?
Нет, Ethernet обычный.
а админы есть там?
С такими симптомами - к админу этого самого default gw. Извне этот же адрес пингается нормально, так что либо это какая-то специальная настройка на шлюзе, либо проблемы в L2 сегменте вроде свалившегося в 10Mbit линка
Спасибо, будем значит выяснять кто за него ответственен.
L2-сегмент - это что? Подсеть EXCLUDED/26 или что-то другое?
L2-сегмент - это что? Подсеть EXCLUDED/26 или что-то другое?
L2-сегмент - это что?сегмент, доступный без маршрутизации на L3 (IP). В твоем случае да, подсеть 93.180.50.193/26.
Выяснилось, что ситуация следующая:
Сегмент физически состоит из двух частей, соединённых между собой оптикой. Шлюз находится в другой части и поэтому извне всегда хорошо пингуется. Проблема решается путём ребута конвертора с ethernet на оптику. Вышестоящие админы говорят, что у нас кто-то флудит. Пока ничего лучше не придумали, кроме как отключить от сети всё и подключать по одному устройству раз в несколько дней.
Но я вот думаю, может можно это как-то отследить... приходит в голову tcpdump - попробую глянуть что он говорит.
Сегмент физически состоит из двух частей, соединённых между собой оптикой. Шлюз находится в другой части и поэтому извне всегда хорошо пингуется. Проблема решается путём ребута конвертора с ethernet на оптику. Вышестоящие админы говорят, что у нас кто-то флудит. Пока ничего лучше не придумали, кроме как отключить от сети всё и подключать по одному устройству раз в несколько дней.
Но я вот думаю, может можно это как-то отследить... приходит в голову tcpdump - попробую глянуть что он говорит.
Взять и посмотреть трафик на порту свича, в который уходит медиаконвертер - неужели это так сложно?
если это мыльница - конечно сложно
Ещё можно заменить этот медиаконвертер на SFP в сам свитч. Свитчи с SFP в наши времена дёшевы 

по сравнению с зарплатой младшего инженера на 0,2 ставки, который там, может быть, админит, недёшевы
Всё настолько плохо?
ну да, 5700р, и таких надо два, и SFP-модули отдельно
а главное неясно: чем результат будет лучше нынешнего
а главное неясно: чем результат будет лучше нынешнего
С чего ты взял, что таких надо два? Мы пока знаем про один конвертер, с другой стороны может там как раз уже свитч с SFP стоит.
Модуль SFP на 1Gbit/s стоит 500р
А про лучше - никогда не любил конвертеры
Модуль SFP на 1Gbit/s стоит 500р
А про лучше - никогда не любил конвертеры

если это мыльница - конечно сложноМогу дать немыльницу в поюз, которой можно трафик послушать, самовывозом и самозавозом если. Но - там только два гигабитных порта, поэтому зеркалироваться будет на 100М порт, и, если трафика будет больше 100, часто в сниффер не попадет.
потом ходить с такой по дереву свитчей чтоб найти источник флуда
например висит под потолком ящик, ты стоишь на стремянке, одной рукой держишь мыльницу, второй ноут, третьей настраиваешь миррор - чудеса акробатики
например висит под потолком ящик, ты стоишь на стремянке, одной рукой держишь мыльницу, второй ноут, третьей настраиваешь миррор - чудеса акробатики
потолкомЯ бы в первом приближении воткнул его в разрыв линка к медиаконвертеру и посмотрел - есть ли флуд, с какого мака (если есть). Может оказаться достаточно.
в сетях на неуправлямых мыльницах флуд чаще всего не "с мака", а из-за петли или чего-то похожего на петлю
что-то похожее - это например сетевая карта глючит и возвращает пакеты
что-то похожее - это например сетевая карта глючит и возвращает пакеты
Пусть ТС обозначит сначала масштабы бедствия. Может, у него там один свич.
"Моя книга вышла тиражом одна книга"
А даже если все плохо - походить с моим свичем по мыльницам будет всяко быстрее, чем
"Моя книга вышла тиражом одна книга"
А даже если все плохо - походить с моим свичем по мыльницам будет всяко быстрее, чем
отключить от сети всё и подключать по одному устройству раз в несколько дней.
Я попросил админа описать мне как построена сеть, жду ответа. Это сегмент из 64 адресов, причём с половину из них в другой локации (где шлюз), а NAT не используется. Так что там, насколько я понимаю, один большой (скорее всего неуправляемый - это же тут назвали "мыльницей", да? ) свитч, и, возможно, парочка мелких (типа 5-портовых) свитчей в комнатах.
В случае неуправляемого свитча без использования дополнительного оборудования никак не выйдет? Может, можно комп с 2-мя сетевыми (уж найдут поди такой) настроить хитрым образом, чтобы он все ethernet-кадры через себя в неизменном виде пропускал и заодно логировал их?
В случае неуправляемого свитча без использования дополнительного оборудования никак не выйдет? Может, можно комп с 2-мя сетевыми (уж найдут поди такой) настроить хитрым образом, чтобы он все ethernet-кадры через себя в неизменном виде пропускал и заодно логировал их?
по сравнению с зарплатой младшего инженера на 0,2 ставки, который там, может быть, админит, недёшевыТам вообще нет официального админа. Один из научных сотрудников волонёрствует. И я тоже волонтёрствую - админю сервачок с почтой и сайтом по ssh.
Закупка оборудования - дело непростое. Нужно много бегать с кучей бумажек и покупать только в магазинах, согласных на безнал без предоплаты по гарантийному письму. Тем более, что эта закупка должна быть чуть более обоснована, чем тем, что не любит медиаконвертеры.
Узнал про структуру сети.
Аплинк нашего свитча ASUS GigaX 1024, к которому подключены все компьютеры нашего сегмента EXCLUDED/26 (из тех, что в этом здании), идёт на управляемый свитч с портом SFP от производителя Rubytech, который выглядит идентично модели FES-2226G/GD, но точную модель найти на нём не удалось. К нему же подходят несколько аплинков свитчей других кафедр, которые относятся к другим сегментам IP-адресов. И там народ, вроде как, не жалуется на проблемы с сетью. Но в то же время именно его перезагрузка помогает восстановить сеть на несколько дней.
Если я правильно понимаю, этот Rubytech работает на уровне arp, а не ip, передавая кадры с одной стороны оптики на другую между определённой парой портов, не смешивая трафик разных сегментов между собой, что делает его эквивалентным набору конвертеров и оптики для каждого сегмента отдельно.
При этом админы с факультета сказали, что делать ничего не будут, так как проблема с нашей стороны, и административный доступ к свитчу они тоже не дадут.
Так что я пока вижу только один вариант: комп с двумя сетевыми всунуть между нашим свитчём ASUS и общим Rubytech, который бы прозрачно пропускал весь трафик в обе стороны между интерфейсами, заодно логируя. Такое реально сделать? Как это правильно называется, чтобы гулить инструкцию?
Аплинк нашего свитча ASUS GigaX 1024, к которому подключены все компьютеры нашего сегмента EXCLUDED/26 (из тех, что в этом здании), идёт на управляемый свитч с портом SFP от производителя Rubytech, который выглядит идентично модели FES-2226G/GD, но точную модель найти на нём не удалось. К нему же подходят несколько аплинков свитчей других кафедр, которые относятся к другим сегментам IP-адресов. И там народ, вроде как, не жалуется на проблемы с сетью. Но в то же время именно его перезагрузка помогает восстановить сеть на несколько дней.
Если я правильно понимаю, этот Rubytech работает на уровне arp, а не ip, передавая кадры с одной стороны оптики на другую между определённой парой портов, не смешивая трафик разных сегментов между собой, что делает его эквивалентным набору конвертеров и оптики для каждого сегмента отдельно.
При этом админы с факультета сказали, что делать ничего не будут, так как проблема с нашей стороны, и административный доступ к свитчу они тоже не дадут.
Так что я пока вижу только один вариант: комп с двумя сетевыми всунуть между нашим свитчём ASUS и общим Rubytech, который бы прозрачно пропускал весь трафик в обе стороны между интерфейсами, заодно логируя. Такое реально сделать? Как это правильно называется, чтобы гулить инструкцию?
Я бы для начала всё же попросил админов переключить вас в другой SFP-порт этого Rubytech.
Я бы для начала всё же попросил админов переключить вас в другой SFP-порт этого Rubytech.Может, в другой Ethernet-порт? В SFP-порт оптика, а не мы подключена же. Да и я так понял, что SFP-порт там один.
По твоей же ссылке: FES-2226G/GD : 24-Port 100M SFP + 2-Port TP/(100/1000M) SFP Dual Media
Т.е. в том свитче 26 SFP портов, 24 сотки и два гигабита.
Т.е. в том свитче 26 SFP портов, 24 сотки и два гигабита.
Так что я пока вижу только один вариант: комп с двумя сетевыми всунуть между нашим свитчём ASUS и общим Rubytech, который бы прозрачно пропускал весь трафик в обе стороны между интерфейсами, заодно логируя. Такое реально сделать? Как это правильно называется, чтобы гулить инструкцию?Во фряхе это называется bridge.
Ты пробовал просто tcpdump'ом смотреть что прилетает тебе на интерфейс?
Если у вас есть кольцо, то, скорее всего, ты увидишь оргомное количество широковещательных пакетов, которые бегают по кольцу и рассылаются куда только можно, включая твой комп.
А дальше методом выдергивания искать порт, который или разорвет кольцо или изолирует его.
Шировещательный флуд с глючной сетевухи так же будет видно.
Если флуд узконаправленный, в сторону шлюза, то можно отключить uplink, настроить адрес шлюза на своем интерфейсе и посмотреть, что прилетит.
Если у вас есть кольцо, то, скорее всего, ты увидишь оргомное количество широковещательных пакетов, которые бегают по кольцу и рассылаются куда только можно, включая твой комп.
А дальше методом выдергивания искать порт, который или разорвет кольцо или изолирует его.
Шировещательный флуд с глючной сетевухи так же будет видно.
Если флуд узконаправленный, в сторону шлюза, то можно отключить uplink, настроить адрес шлюза на своем интерфейсе и посмотреть, что прилетит.
Оставить комментарий
dangerr
Можно ли что-нибудь сказать о проблеме увеличенного пинга по следующему выводу:EXCLUDED - default gw.
Я пускал tracepath до своего домашнего компьютера, но он вернулся на локалхост (xxx в пунктах 1 и 11 - один и тот же). Эта проблема периодически появляется, но потом сама пропадает (обычно несколько часов, максимум до пары суток). Может ли такое быть вызвано каким-то техническими работами или скорее всего админы не в курсе и есть смысл пытаться выяснять их личности и контакты?