Странное поведение в сети, петля?

[morfey 82]

Траффик запрещен, алиасы есть. Нашел абонентский порт где этот "писюн")) вылазит. Отключил, мониторю.

[BUM 237]

в момент шторма на BDCOM пробовали clear fdb ?

[alex_o 1 194]

в момент шторма на BDCOM пробовали clear fdb ?

этож бдком, а не экстрим.

clear mac addr dyn

[BUM 237]

в момент шторма на BDCOM пробовали clear fdb ?

этож бдком, а не экстрим.

clear mac addr dyn

Суть от этого не меняется)

кстати как раз год назад наблюдалась такая же бяка на x650 прошивка 12.5.х, обновились до 12.6.1.3 проблема пропала.

[Гайджин 574]

в момент шторма на BDCOM пробовали clear fdb ?

Очень здравая мысль - мне такое то же в голову приходило.

Запросто может быть какое то триперьё которое генерирует пакеты с разными маками, чем перепирает таблицу коммутации на свиче агрегации. А так как все в одном влане, то свич начинает работать как хаб и разливает вполне себе легеминый трафик по всем портам - вот тебе и графики.

[morfey 82]

Не, не делал. После того как положил клиентский порт, все утихло. Судя по маку на порту, у клиента тплинк роутер, помониторю и зашлю монтажников поглядеть.

 

 

P.S. Юзер знакомый попался, говорит что у него роутер Tenda.

[greyshadow 22]

На картинке - примерная сеть.

 

Что было обнаружено:

Роутеры A,B,C работают, все нормально, все хорошо.

Вдруг B "гаснет", свич sw1 сносит его mac из таблицы коммутации, но с сервера продолжают еще "долетать" пакеты вида [src IP <a.b.c.d>; dst IP <IP_роутера B>], т.к. сервак ничего не знает о состоянии роутера B и благополучно хранит его MAC в arp-е сервер отправляет соответствующий фрейм в соответствующий интерфейс.

Т.к. коммутатор уже MAC для B не помнит, он как и положено футболит фрейм на роутеры A и C, по всем правилам жанра A и C должны его проигнорировать, т.к. dst MAC вовсе не их, НО

некоторые роутеры (в лично моем случае это оказались tenda) по необьяснимым причинам берут этот фрейм, извлекают из него соответствующий IP пакет, обнаруживают, что dst IP <IP_роутера B> нах

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

Шлюз, как честный маршрутизатор пуляет уже 2 пакета в сторону роутера B, и все повторяется с максимально доступной скоростью пока шлюз наконец не сносит MAC роутера B из arp-а.

При всем при этом стоящий в сторонке роутер D (НЕ tenda) так же получает некислый такой всплеск пакетов в свою сторону, но как порядочный роутер игнорит оные, но абоненту от этого не намного

легче...

 

Если свичей в цепочке несколько, то эффект проявляется когда истекает таймаут для MAC-ов на свичах.

 

В подобном поведении пока только tenda замечена...

[morfey 82]

Выше написал, tenda...

 

Как боротся с такими тендами?

[greyshadow 22]

Как возможный вариант, если на роутере активировано клонирование MAC-а, он может тоже поступать аналогичным образом.

[greyshadow 22]

в момент шторма на BDCOM пробовали clear fdb ?

Очень здравая мысль - мне такое то же в голову приходило.

Запросто может быть какое то триперьё которое генерирует пакеты с разными маками, чем перепирает таблицу коммутации на свиче агрегации. А так как все в одном влане, то свич начинает работать как хаб и разливает вполне себе легеминый трафик по всем портам - вот тебе и графики.

 

В таком варианте со стороны сервака не было бы ответной реакции - MAC не его, значит трафик игнорим, а она (реакция) есть....

[greyshadow 22]

Выше написал, tenda...

 

Как боротся с такими тендами?

 

Я запретил на рутере с абонентского интерфейса пакеты с src IP адресами, отличными от абонентских, т.е. по схеме выше, сервак от абонов принимает пакеты только с src_IP из Net_1 и Net_2, но это только часть решения, пришлось так же запретить принимать пакеты вида [src ip <Net_1>; dst ip <Net_2>] и наоборот (т.е. запретил общение между абонами разных подсетей).

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

[greyshadow 22]

Ну и есть плешь тому, кто эти тенды выпускает....

Пусть прошивку пилит.

[alex_o 1 194]

Я запретил на рутере с абонентского интерфейса пакеты с src IP адресами, отличными от абонентских

Надо не забывать, что есть еще протоколы Л2-уровня - arp, dhcp, pppoe. Они умеют срать броадкастом. А arp к тому же еще и умеет засорять МАС-таблицы свичей и роутеров. Так что одного только Л3-фильтра по IP недостаточно, надо бы запретить абону по arp анонсить несвой IP и сильно ограничить пропуск броадкаста (например, 10 пакетов в сек).

[Гайджин 574]

В таком варианте со стороны сервака не было бы ответной реакции - MAC не его, значит трафик игнорим, а она (реакция) есть....

И где это?

[Гайджин 574]

Что было обнаружено:

Роутеры A,B,C работают, все нормально, все хорошо.

Вдруг B "гаснет", свич sw1 сносит его mac из таблицы коммутации, но с сервера продолжают еще "долетать" пакеты вида [src IP <a.b.c.d>; dst IP <IP_роутера B>], т.к. сервак ничего не знает о состоянии роутера B и благополучно хранит его MAC в arp-е сервер отправляет соответствующий фрейм в соответствующий интерфейс.

Т.к. коммутатор уже MAC для B не помнит, он как и положено футболит фрейм на роутеры A и C, по всем правилам жанра A и C должны его проигнорировать, т.к. dst MAC вовсе не их, НО

некоторые роутеры (в лично моем случае это оказались tenda) по необьяснимым причинам берут этот фрейм, извлекают из него соответствующий IP пакет, обнаруживают, что dst IP <IP_роутера B> нах

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

Шлюз, как честный маршрутизатор пуляет уже 2 пакета в сторону роутера B, и все повторяется с максимально доступной скоростью пока шлюз наконец не сносит MAC роутера B из arp-а.

При всем при этом стоящий в сторонке роутер D (НЕ tenda) так же получает некислый такой всплеск пакетов в свою сторону, но как порядочный роутер игнорит оные, но абоненту от этого не намного

легче...

В Вашей теории есть несколько проблем.

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

Если Тенда поведет себя таким образом, то на L3 коммутаторе агрегации должно будет так ЦПУ нагрузить, что живые позавидуют мертвым. - А мы Морфея наблюдаем, а если бы вштырило сивч агрегации - не наблюдали бы.

[_WesT_ 1 016]

А мы Морфея наблюдаем, а если бы вштырило сивч агрегации - не наблюдали бы.

 

Вот это очень точно сказано

[greyshadow 22]

В Вашей теории есть несколько проблем.

Увы, чистейшая практика! 2 дня занимался диагностикой, анализом и отловом.

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

Если Тенда поведет себя таким образом, то на L3 коммутаторе агрегации должно будет так ЦПУ нагрузить, что живые позавидуют мертвым. - А мы Морфея наблюдаем, а если бы вштырило сивч агрегации - не наблюдали бы.

 

Нет там L3 коммутатора агрегации, весь L3 приземлен прям нашлюзе, от абона до шлюза - только L2.

[greyshadow 22]

ув.morfey, вас не затруднит опубликовать график порта свича в сторону шлюза (если возможно - там где именно абонентский трафик гуляет, если у вас на шлюзе 2 или более физических интерфейса) в тот же период, что и графики в первом сообщении??

[morfey 82]

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

[greyshadow 22]

Я запретил на рутере с абонентского интерфейса пакеты с src IP адресами, отличными от абонентских

Надо не забывать, что есть еще протоколы Л2-уровня - arp, dhcp, pppoe. Они умеют срать броадкастом. А arp к тому же еще и умеет засорять МАС-таблицы свичей и роутеров. Так что одного только Л3-фильтра по IP недостаточно, надо бы запретить абону по arp анонсить несвой IP и сильно ограничить пропуск броадкаста (например, 10 пакетов в сек).

То, что я показал только некую выжимку из всего, что делал вам в голову не пришло??

После анализа бродкаста и мультикаста предположение о высере бродкаста или мультикаста в сеть было забраковано.

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

Описание всех проведенных действий и экспериментов больше смахивало бы на повесть

[greyshadow 22]

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

Сравните масштабы и шкалы! на высланом вами графике около 12:00 и далее 00:00 есть четкие всплкески в 50М как на вход так и на выход, хороше совпадающие с пиками из первого поста.

Вы статистику по unicast, broadcast и multicast фреймам со свича снимаете?? усли еще нет - очень советую начать, на ucast эти пики были бы видны очень хорошо.

Кроме того отсутствие подобных пиков на bcast и mcast статистике только подтвердило бы мои слова... или наоборот - наличие бы говорило именно о bcast или mcast шторме.

[morfey 82]

Уже начинаю снимать)

[greyshadow 22]

собственно есть простой метод предварительной проверки - гасите найденного абонента на сутки например (их там, кстати, как минимум 2!, на графиках в первом сообщении 2 графика нижние, которые полностью видны) там где 150М пики четко виден не только OUT, но и IN трафик, а вот на 50М IN-а уже нет, вероятно выключены были.

[greyshadow 22]

В Вашей теории есть несколько проблем.

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

Если Тенда поведет себя таким образом, то на L3 коммутаторе агрегации должно будет так ЦПУ нагрузить, что живые позавидуют мертвым. - А мы Морфея наблюдаем, а если бы вштырило сивч агрегации - не наблюдали бы.

 

Кстати, насчет dhcp, arp и т.д. с таймаутами,

Вот результат вывода arp-а с самого обычного bsd-ного сервера БЕЗ всяких подкруток, тюнингов и вообще с генерик ядром:

 

(172.17.20.19) at 00:26:2d:61:76:7d on vlan0 expires in 1196 seconds [vlan]

 

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

А у свичей как травило таймаут небольшой, например edge-core по дефолту

 

show mac-address-table aging-time

Status: Enabled Aging time: 300 sec.

[morfey 82]

Кстати, нашел другого пациента. Только он онлайн, а "шторма" нет. Как-то резонансно откликнулся..