loopdetect на STP

http://www.vimcom.ru/support/lofiversion/index.php?t553.html

Если в логах при петле пишутся слов "STA Topology Change", то это значит, что определение петель на клиентских портах сделано на STP движке. Конечно вы сами решите, как вам ловить такие петли, но вот чем это плохо:



1. STP во всех свичах AFAIK обрабатывается на CPU, аппаратно лишь порты меняют своё состояние (fwd, blk, lrn), сами же сообщения протокола обрабатывает ЦПУ. Если кастомер имеет возможность как-то "трогать" CPU, то однажды кто-то его может потрогать критическим образом, т.е. STP на клиентских портах одлжно отсутствоватьв любом виде.

2. Все виды STP работают в так называемых "инстанциях", т.е. инстанция это как бы отдельное дерево. В per vlan stp обычно может быть 64 инстанции (cisco 29X0 поддерживают до 64 инстанции на свич в режиме pvstp), в mstp AFAIK может быть всего 16 инстанций (но там можно хоть все вланы в одну инстанцию засунуть, либо явно указать где какой, но это надо делать одинаково во всей своей инфраструктуре). Так вот, когда случается topology change, то в данной инстанции происходит событие, забыл как называется, но в доке у цыско где-то подробно это описано. Все свичи в данной инстанции тут же узнают про это дело по соответствующим сообщениям в протоколе. Когда меняется топология, то свичи должны сбрасывать свои таблицы мак-адресов (побыть какое-то время ХАБАМИ!) чтобы быстро перестроить их заново - ведь топология изменилась и теперь некоторые маки (хрен знает какие именно) могут быть уже на других портах. А теперь представим, что вы даёте /24 на vlan, т.е. у вас примерно 250 портов в одной инстанции или даже больше в случае mstp. Как, по-вашему, часто эти порты будут "моргать инстанцию" ? Реально наблюдал, что примерно 400-500 портов в одной инстанции превращали ВСЕ свичи инстанции в хабы примерно раз в 30 секунд :-). Ну всегда находился кто-то, кто включал комп или выключал - это тоже генерит такие событие. Не знаю, как у е-корок реализовано STP, но скорее всего должно работать именно так.

3. Если у клиента есть доступ к STP, то он может сделать root дерева у себя :-). Я такое тоже видел, правда тогда наше STP было вообще не сконфигурировано никак. Свичи просто так отваливались, оказалось, что корень получался ну совсем не в центре сети, ваще где-то на самом отшибе.

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

По этим причинам не следует применять STP в любом виде на кастомерских портах.

Что же делать ? Ну ... зависит отоборудования :-). У цысок есть ещё один метод обнаружения петель, называется keepalive, включен по-умолчанию. У е-коров нет, но есть другие фишки, которые можно применять в т.ч. для противодействия эффектам, получаемым при нежелательных петлях.

Следующие явления случаются при "плохих" или кастомерских петлях:

1. Маки начинают прыгать туда-сюда между портами. Для предотвращения этого можно испоьзовать port-security. Хорошо, 1 мак разрешать может быть кому-то и плохо - юзеры будутпресоватьтехсапорт звонками, сделай 10, 20 ... не так уж и часто юзеры меняют оборудование. Включите storm-control, который детектит unknown unicast traffic - был вроде такой.

2. При петле начинается генерация малтикаст и броадкасттрафика. Опять включаем storm-control на эти виды, есть такой.

3. Можно вешать на порты различные acl. Например, если у вас РРРоЕ, то разрешаем только эти фремы, если IPoE, то можно ip acl вешать, хотя тут сложнее и специфично для сети. acl помогут остановить некоторые виды генерации, если не все.

4. Все перечисленные фичи делают аппаратно и не затрагивают ЦПУ :-).

Я ни к чему не призываю, я просто своё мнение высказал по вопросу применения STP на юзерских портах :-). Пусть каждый сам решает, как ему половчее сконфигурить свою сеть :-).

...

2. Cisco 29x0 - не везде 64 instances pvst+, бывает и 128 и больше в 2960/2970. Опять-же pvst это красиво, но единственная его задача per vlan'овского STP - заставить работать ВСЕ линки в кольцах топологии, выбрав отличающиеся места разрыва кольца для каждого вилана. Красиво, но...

про события в instance и STA Topology Change, руте и т.д. обратите внимание в документации у циски на фичи RootGuard, portfast, bpduguard и т.п., после чего и на RSTP(например). В понимании RSTP есть edge-порты. Предполагается что в них подключено конечное устройство/компьютер/пользователь (аналогичное предполагает и portfast).

Особенность edge-портов, в частности, в том, что они переводятся в состояние Forwarding минуя Listening и, при изменении их состояния, не генерируется Topology Change Message потому что просто незачем всей сети знать об изменении порта ендюзера. Потух - да и черт бы с ним, спустя age time мак всё равно "протухнет" в таблицах коммутации. Порт поднялся? Великолепно, когда в него влетит хоть один фрейм, он будет профлужен по всему вилану сети и src mac попадёт в таблицы коммутации всех бриджей, которые его услышали. Причем фрейм с неизвестным src mac будет профлужен по всему вилану именно как через хабы. Вспоминаем алгоритм работы transparent bridge - если src mac фрейма броадкастовый/отсутствует в таблице коммутации, то флудим его во все порты вилана, кроме того, откуда он пришел (pvlan и traffic segmentation не рассматриваем).

Так что при должной настройке не всё так страшно как Вы описываете, а "хабовость" даже является ключевым пунктом алгоритма коммутации. Хотя, согласен, зафильтровать прием bpdu на портах пользователей бывает полезно. Но жертвовать ради этого loopdetect'ом - в конце концов каждый выбирает сам исходя из своего понимания необходимости определенных фич и схемы построения сети.