[Morbid]

Добрый день, коллеги.

 

Столкнулся с такой бедой.

 

Есть влан, раскидан по разным частям города.

 

Во влане дико скачут юникасты, причем симметрично во всех портах одновременно, в разных частях города.

То есть 5 активных портов на коммутаторе. У всех у них одинковая нагрузка по Юникастам. То есть создается такое впечатление что коммутаторы работаю как хабы.

Берем другой коммутатор, таже самая беда, во всех активных портах, одинаковая нагрузка. Берем другой коммутатор где нет этого влана, все ок, везде порты загружены по разному.

 

Заббикс показывает, что нагрузка именно юникастовая, ни броадкастов, ни мультикаста нет на портах.

 

Даже идей нет куда копать, ладно было бы в одном районе, а так разных частях, но в приделах одного влана. :(

 

Есть какие либо идеи? может кто сталкивался?

 

Коммутаторы Длинк, DES35xx, DES32XX

[sol]

tcpdump

wireshark

[Aksel]

Обычная L2 петля. Нужно смотреть шарком, найти зло и выключить порт, этого зла.

[s.lobanov]

Есть влан, раскидан по разным частям города.

В принципе, дальше можно не читать. L2-сегменты должны быть маленькими настолько, насколько это возможно.

 

По существу, если там много маков, то и без петель будет много unicast'а, превративщегося в бродкаст

[Serejka]

Во влане дико скачут юникасты, причем симметрично во всех портах одновременно, в разных частях города.

То есть 5 активных портов на коммутаторе. У всех у них одинковая нагрузка по Юникастам. То есть создается такое впечатление что коммутаторы работаю как хабы.

Берем другой коммутатор, таже самая беда, во всех активных портах, одинаковая нагрузка. Берем другой коммутатор где нет этого влана, все ок, везде порты загружены по разному.

 

Заббикс показывает, что нагрузка именно юникастовая, ни броадкастов, ни мультикаста нет на портах.

 

Даже идей нет куда копать, ладно было бы в одном районе, а так разных частях, но в приделах одного влана. :(

 

Есть какие либо идеи? может кто сталкивался?

 

по симптомам у вас проблема с unknown unicast, вполне возможно что источником является какая-то завирусованная железка или банальный вредитель. без tcpdump/etherdump/tshark это лечить можно только методом тыка, туша поочерёдно порты и постепенно локализуя источник, если источников несколько - помогут вам только экстрасенсы :)

[ShyLion]

Было дело - видеокамера слала поток на IP/MAC, который про эту камеру забыл давно (или тупо выключился не сообщив камере). Глюкавое ПО камеры не обращало внимания на отсутствие сеанса и юникастило. Как только MAC протух в таблицах свичей, так во все порты и ливануло. Заметили когда ливануло на модемные линки медленные.

[Morbid]

Все печальней :(

 

Коммутатор агрегации теряет маки. Из-за этого он и рассылает во все порты. При этом во всей цепочки от агрегации до клиента, есть мак, а именно на агрегации нет :(

 

Ребут железки помогает, но не надолго :(

[s.lobanov]

Morbid

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

[Morbid]

s.lobanov

Это понятно, но к сожалению быстро и по хлопку это сделать не реально. Дробление на вланы идет, но медленно. А проблема сейчас :( Махнем железку, благо есть на что, дальше посмотрим в железе было дело или нет.

[s.lobanov]

Morbid

ну да, быстрее поменять на железку с бо'льшей мак-таблицей

[Morbid]

Тут таблица на 16к, маков юзается 8к всего, он просто не изучает какие то маки и все. Причем, в другой части стоит два таких же коммутатора тоже в стеке и там все ок.

 

Если мак прописать ручками (статикой) на нужный порт и влан, то проблема решается. Но общих признаков выявить не удалось, что бы понять по какому принципу они не добавляються. Такое ощущение что коммутатор просто приказал долго жить. Сегодня ночью махнем на такой же, с новой прошивкой и будем надеется что дело все такие в железе, которое "сломалось".

[s.lobanov]

Morbid

Нет, всё не так. На дешевых свитчах, при заявленной таблице в 8К маки начинают заметно теряться от 300-500 маков, это из-за хешей, тут на наге полно таких тем. При 16К и при наличии 8К на нём, да, это очень вероятно. Когда вы делаете статику, то какой-то другой мак пропадёт. Махнуть на такой же смысла нет - инфа соточка, опять будет тоже самое

[Morbid]

Как в воду глядели. Проблема осталась, ни прошивка, ни замена железки не помогла :(

 

 

Теперь другой вопрос, стоит DGS3420-28SC. Понятно что не подходит. Кто что скажет про MES3124F? Или что нить другое может, за адекватные деньги?

 

P.S. Дробление вланов, это понятно. Но за неделю даже не сменю.

[tehmeh]

Поставить две или три железки вместо нереально?

[kayot]

Теперь другой вопрос, стоит DGS3420-28SC. Понятно что не подходит.

Неверно. У 3420 честная mac-таблица на 16к записей, без коллизий.

Теряться и переполняться там нечему, замена не поможет.

 

Таки ищите что у вас в сети на L2 флудит.

[s.lobanov]

kayot

Чёто не особо верится. Вы лично его проверяли?

[Morbid]

2kayot: Опишу как искали проблему, может чего не понимаю или делаю не так. Беру Хост, который торчит в проблемный влан, делаю так

 

tcpdump -e -i eth0.xxx | grep "IPv4"

 

В итоге вижу кучу левого трафика, который не должен попадать к этому хосту. Беру мак такого Ипшника, и смотрю на всем пути от агрегации, до клиента. На всех коммутаторах он есть, кроме агрегации.

Добавлю этот мак статикой в сторону нужного порта и влана, все сразу пропадает. tcpdump ни чего не показывает.

 

Так делал несколько раз, с разных напралвенией, все один в один.

 

2tehmeh: Тоже уже думла, будем реализовывать. Это быстрее чем разбить на вланы.

2s.lobanov: Смущает одно, что люди на форуме длинка, говорят что там 12-15к маков держит, со скринами и т.д. Но я все таки думаю, что там разбиты на вланы, сильнее чем у меня. и поэтому колизий нету. Ведь если я не ошибаюсь в хешах используеться, порт, мак, влан.

 

Суть в том что на этой же железке, есть и другие вланы, и там нету таких проблем. Только в "большом" влане, встречается.

[s.lobanov]

Morbid

у вас ведь есть запасной такой свитч. возьмите его, возьмите генератор маков и сами посмотрите с какого кол-ва маков коллизии становятся заметны (несколько прогонов)

 

Поставить две или три железки вместо нереально?

 

А как это сделать? Это ж по сути тоже самое, что разбить влан на 2-3, что крайне сложно для автора топика

[kayot]

kayot

Чёто не особо верится. Вы лично его проверяли?

Лично нет, но в теме по коллизиям длинков выкладывали тест для 3120 и 3420 - до 16к влетало без потерь.

[tehmeh]

А как это сделать? Это ж по сути тоже самое, что разбить влан на 2-3, что крайне сложно для автора топика

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

[Butch3r]

3120 я тестировал. На 16к потерялось в районе 100шт. 3420 - следующая модель, поэтому тут всё нормально.

[s.lobanov]

3120 я тестировал. На 16к потерялось в районе 100шт. 3420 - следующая модель, поэтому тут всё нормально.

 

kayot

Чёто не особо верится. Вы лично его проверяли?

Лично нет, но в теме по коллизиям длинков выкладывали тест для 3120 и 3420 - до 16к влетало без потерь.

 

 

Ну вот видите, у кого-то без потерь, а у кого-то 100 маков потерялось на 3120. Я не думаю, что на 3420 маки совсем не теряются при 16К, все же понимают что это вероятностный процесс. У топикстартера достаточно потеряться одному маку и тогда клиент, который "потерялся" на агрегации может забить все 100м линки.

[Butch3r]

100 на 16к это очень хороший результат. Считай, что потерь нет.

[Ivan_83]

tcpdump -e -i eth0.xxx | grep "IPv4"

Плохая идея, лучше прописать матчинг прямо в tcpdump, так ресурсов будет жрать сильно меньше, ибо фильтрация будет в ядре ОС.

[mcdemon]

на 3420 есть команда enable flood_fdb ?