Схема условная CAT-->CAT-->Client
STP работает по всему маршруту. Клиент ставит Свой cat на конце и говорит порту к оператору spanning-tree bpdu-filter enable
далее берет и замыкает два следующих порта eth кабелем.
STP строит дерево за счет BPDU пакетов, в данном случае к клиенту не отправляеться и не принимаеться BPDU, а пакеты тем не менее штурмуют все каталисты по пути. Как этого избежать?

• Схема работы STP на неполном дереве.,sh_, 14:06 , 18-Ноя-08
  • Схема работы STP на неполном дереве.,ntdemon, 14:25 , 18-Ноя-08
  • Схема работы STP на неполном дереве.,Evstifeika, 12:36 , 02-Дек-08
• Схема работы STP на неполном дереве.,Evstifeika, 16:02 , 18-Ноя-08
  • Схема работы STP на неполном дереве.,ntdemon, 16:13 , 18-Ноя-08
    • Схема работы STP на неполном дереве.,Evstifeika, 17:04 , 18-Ноя-08
      • Схема работы STP на неполном дереве.,ntdemon, 17:17 , 18-Ноя-08
        • Схема работы STP на неполном дереве.,merax, 11:38 , 11-Дек-08

Я так понимаю, что штормег возникает у клиента. Поэтому вам нужно просто storm-control настроить на порту.

>Я так понимаю, что штормег возникает у клиента. Поэтому вам нужно просто
>storm-control настроить на порту.

Тоесть STP спасает только от собственных косяков, а от чужих вообще никак не поможет?

>storm-control настроить на порту.

Насколько я понимаю, storm-control тоже не панацея... В документации (http://cisco.com/en/US/docs/switches/lan/catalyst2960/softwa...) написано, что при превышении некоторого конфигурируемого проргового значения, storm-control блокирует указанный тип трафика в следующий интервал времени (который для коммутаторов 2960/3560 равен 1 секунде). Получается, если представить, что клиентский порт генерит трафик, например, со скоростью 50к pps, то в результате получим:
на первой секунде - трафик 50k pps
на второй секунде - блокировнаие трафика
на третьей секунде - трафик 50k pps
на червертой секунде - блокирование
... (и так далее в шахматном порядке)

В среднеем имеем 25k pps... и эта цифра не зависит от указанного threshold'а...
Честно говоря, я не очень понимаю прелести этой (storm-control) технологии... по-моему вопрос остается открытым. поправте меня, если я не прав.

Спасибо.

Как этого избежать?

предлагаю включить на порту, который смотрит на клиента, технологию bpduguard

>Как этого избежать?
>
>предлагаю включить на порту, который смотрит на клиента, технологию bpduguard

а, bpduguard тут причем? Объясни поподробнее. по моему bpduguard в циске для того чтобы работать с STP, и порт при попадании на него bpdu уходит в errdis и тем самым не создает петлю.
вот предидущее сообщение практически решает задачу, но со стороны broadcast storm, а как на счет unicast storm, тут все интереснне, ставлю 50% от скорости интерфейса и если клиент сжирает более 50% полосы, то начинаеться балансирование, sh storm-control unicast показывает плавающее состояние forvard Block, соответственно если не заморачиваться в принцыпы то ситуация похожа на rate-limit. Отличный плюс что ограничивая порты таким образом это все не дойдет до маршрутизатора, если подрозумевать схему "Маршрутизатор на привязи".<-- это конечно бесспорный плюс, хотябы не все ляжет, а только один клиент, и частично скажеться на загрузке сети.

ой, виноват, был не внимателен. действительно, в данном случае от bpduguard пользы никакой не будет. извините.

>ой, виноват, был не внимателен. действительно, в данном случае от bpduguard пользы
>никакой не будет. извините.

Бывает.

Вообщето STP тема довольно сложноая... в курсе BSMCN рекомендуют при вводе каталиста в сеть отключать STP... В вашем же случае можно порекомендовать портам которые на данный момент рутовые запретить становится не рутами...