Перейти к содержимому
Калькуляторы

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

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

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

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

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

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

Изменено пользователем NiTr0

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

STP, the Spanning tree protocol

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Изменено пользователем NiTr0

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

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

Изменено пользователем NiTr0

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Изменено пользователем bDrwx

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Подскажите, как на 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 не помогает.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.