Определить факт наличия кольца

[NiTr0]

В одном из сегментов сети начали периодически происходить непонятные вещи со связью, есть подозрение на то, что у какого-то криворукого пользователя организовалось кольцо. Соответственно, возникает вопрос, как данное предположение проверить. Имеется линуксовый роутер, который собссно и отсекает данный сегмент, и DES-2110, в который включены глупые клиентские свичи (на RTL8309/8316).

На порту роутера tcpdump как при появлении проблемы, так и при появлении кольца (тестировали) не показывает ничего сверхъестественного. Потому собссно возник вопрос:

1) Как скажется появление кольца на траффике через порт - будет ли это заметно по SNMP?

2) Если включить вланы - при появлении кольца отвалится только 1 порт DES-2110, на котором появилось кольцо, или же будут проблемы и с другими портами?

3) Есть ли вообще какая-либо методика удаленного определения факта наличия кольца (без физического отключения пользователей по одному до исчезновения проблемы)?

Edited February 23, 2009 by NiTr0

[itl2044]

Будет примерно 50% потерь, ничего аномального снифер не покажет.

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

[chainick]

>> 3) Есть ли вообще какая-либо методика удаленного определения факта наличия кольца (без физического отключения пользователей по одному до исчезновения проблемы)?

 

STP, the Spanning tree protocol

[NiTr0]

STP, the Spanning tree protocol

Это хорошо, но, если не ошибаюсь, кольцо на одном из свичей ложит весь сегмент... Во всяком случае такое наблюдается на глупых свичах. Как на это отреагирует 2110?

И еще вопрос - как разные свичи реагируют на появление идентичных маков на разных портах (не исключен вариант юзеров с шаловливыми ручками)?

Edited February 23, 2009 by NiTr0

[chainick]

Вот, насчет 2110 я не подскажу, простите. Факт тот, что кольцо на любом оборудовании, с ненастроенным стп кладет весь сегмент в полный даун. стп спасает тем, что переводит дублирующий порт в админ-шатдаун и таким образом обрезает шторм.

 

Вариант юзеров с шаловливыми ручками называется arp-spoofing, и как с ним бороться в конкретной сети на конкретном оборудовании загуглить не составляет труда.

[NiTr0]

Вот, насчет 2110 я не подскажу, простите. Факт тот, что кольцо на любом оборудовании, с ненастроенным стп кладет весь сегмент в полный даун. стп спасает тем, что переводит дублирующий порт в админ-шатдаун и таким образом обрезает шторм.

Если 2 порта на "умном" свиче закольцованы - STP спасет. А если в умный свич воткнут глупый с закольцованными портами? Ведь никто не мешает чем-то обиженному пользователю устроить такое "западло"... Потому и интересует поведение умного свича в данном случае. Как при включенных вланах, так и без них.

 

Вариант юзеров с шаловливыми ручками называется arp-spoofing, и как с ним бороться в конкретной сети на конкретном оборудовании загуглить не составляет труда.

Не только спуфинг, но еще и poisoning, хотя это еще детектится.. Но кто-то может и просто поставить мак соседа. Хотя инет он так не пососет без лишних усилий (ибо ВПН, а поломать логин-пароль - это нужно еще поднапрячься, не каждому кул-хацкеру школьного возраста такое по силам), но локалку - может. Потому и интересует - как в таком случае себя будут разные свичи вести, при наличии 2 хостов с одним маком? В основном - касательно работы других абонентов (то, что юзеры с совпадающими маками толком не смогут работать - это ясно).

Edited February 23, 2009 by NiTr0

[chainick]

Влан тут не при чем - это всего-лишь добавление некоего ид к каждому фрейму.

 

А вот как поведет себя умный свитч при шторме с порта, к которому подключен глупый с кольцом - интересный вопрос. Никогда так не пробовал. Лично мне кажется, что умрет сегмент на уровне глупого свитча и до умного порта не дойдет, но это надо проверить. Если сегодня никто не обосрет, завтра проверю и скажу :)

 

 

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

[UglyAdmin]

На умных бывает Loopback Detection.

Только 2110 - ещё не настолько умный...

[Stak]

А вот как поведет себя умный свитч при шторме с порта, к которому подключен глупый с кольцом - интересный вопрос. Никогда так не пробовал. Лично мне кажется, что умрет сегмент на уровне глупого свитча и до умного порта не дойдет, но это надо проверить. Если сегодня никто не обосрет, завтра проверю и скажу :)

Хреново будет умному свичу в этом случае) А вот насколько хреново - зависит от того какой свич. На длинках 3226 например года три назад такая ситуация приводила к 100% нагрузке на ЦПУ, и форварде этих бродкастов во все порты невзирая на вланы))) потом правда поправили... на циске 2900XL просто загрузка по ЦПУ до 100% поднималась, однако управляемость сохранялась) На зукселях 2024 - тоже как то не хорошо было, после шторма не все оживали; На хуавеях 5600 - как на циске.

[OverchenkoAlexander]

Мое мнение - слушать STP с клиентского порта нельзя ни в коем случае. Нужно пользоваться функцией storm-control

[mikevlz]

слушать нужно, только вот прислушиваться вредно. Услышав там левак гасить нафиг.

[Alexandr Ovcharenko]

1. Заменяем 2110 на 3010.

2. Включаем на портах loopback detection

3. Спим спокойно

[OverchenkoAlexander]

Услышав там левак гасить нафиг.

Зачем гасить? А как услуги предоставлять через загашенный порт?

[Alexandr Ovcharenko]

Потому что если не погасить, то пострадают остальные.

Берем самую дешевую свич-мыльницу на 5 или 8 портов, патч-кордом соединяем 2 порта, а 3-м портом втыкаем в сеть провайдера. Получаем генератор флуда. У провайдера при этом гарантировано заколбасит все вплоть до ближайшего "умного" свича. "Умный" - это который умеет loopback detection, то есть гасит порт, на котором возникает флуд от петлевого шторма.

 

P/S в генератор флуда дешевые свичи частенько превращаются от элементарного поражения статикой во время грозы.

[yarmol]

На порту роутера tcpdump как при появлении проблемы, так и при появлении кольца (тестировали) не показывает ничего сверхъестественного.

Ну, за умные свичи тут умные люди говорят )), а я вот про tcpdump скажу - сам факт кольца им прекрасно детектируется:

если валит куча (30-50 штук) идентичных пакетов, значит кольцо есть.

Понятное дело, что по содержимому пакета, да по всему трафику сложно отслеживать, но если отфильтровать, например, icmp, то можно увидеть как пачками вываливаются идентичные пакеты (при обычном пинге смотреть поле seq).

 

[terrible]

Alexandr Ovcharenko дело говорит по поводу loopback detection, кольцо на порту обнаруживается практически мнгновенно (секунда или пол-секунды) - после этого порт выключается и отчет в сислог.

 

А вот как порекомендовал chainick STP - это тоже как вариант можно рассматривать

[OverchenkoAlexander]

Потому что если не погасить, то пострадают остальные.

Я имел в виду не шторм, а нехорошие stp bpdu. Как от последних пострадают другие пользователи, если мы эти bpdu не слушаем? Что же касается шторма, то рубить - уже не прихоть, а необходимость. Механизмов несколько, работают как надо.

[bDrwx]

Столкнулся с кольцами. 12 часов колбасило целое региональное управление. Шторм пропал, в логах записей никаких. Вот нарыл ссылку как диагностировать кольцо кто что думает?

 

Как определить кольцо на свичах Cisco

Edited April 24, 2015 by bDrwx

[Ivan_83]

Думаю нужно понимать что кольца бывают разные.

Можно сделать кольцо на мыльнице и выпустить трафик из него в остальную сеть, сеть ляжет но коммутаторы не увидят кольца, только броадкаст/мультикаст шторм.

Ещё бывают флудящие порты (на коммутаторах и на сетевухах), злообжатые хвостики.

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

[NiTr0]

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

Нет. Есть loopback detect - ну т.е. если возвращается отправленный свичом пакет, значит петля...

[Ivan_83]

Нет. Есть loopback detect - ну т.е. если возвращается отправленный свичом пакет, значит петля...

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

[Negator]

Тогда это и не совсем кольцо.

[vipro]

Подскажите, как на 2960 настроить защиту от флуда и колец.

 

Пробовал следующие варианты:

Switch(config-if)#storm-control action trap

1. Switch(config-if)#storm-control broadcast level X Y

2. Switch(config-if)#storm-control broadcast level pps X Y

 

Что означают в первом случае X и Y?

Какие бы там я значения X не ставил, свич не реагирует на подключенный тупик с закольцованными портами, просто загрузка проца уходит в 99% и ничего больше не происходит. Если же к тупику с кольцом подключить хотя бы один компьютер, то тогда защита срабатывает, через несколько секунд проц расслабляется до стандартных 5%.

1. Как быть, если подключен только закольцованный тупик и больше ничего?

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

3. Если сделать Switch(config-if)#storm-control action shutdown, то после исчезновения проблемы, порт не выходит из этого дауна. Switch(config)#errdisable recovery interval 30 не помогает.

[russ1st]

X и Y измеряются в % от bandwith на порту.

Значение Х - порог сработывания события , Y - порог нормализации (восстановления работы) после срабатывания события.

[vipro]

X и Y измеряются в % от bandwith на порту.

Не понял. Bandwith у порта 100 Мбит/c. Как я могу поставить какой-то процент, если мне и надо, чтобы он на 100 Мбит/с работал?

А как с тупиком бороться? Какие значения не выставляй в storm-control, он не реагирует.