https://opennet.ru/openforum/vsluhforumID6/17612.html Схема условная CAT--&gt;CAT--&gt;Client<br>STP работает по всему маршруту. Клиент ставит Свой cat на конце и говорит порту к оператору spanning-tree bpdu-filter enable<br>далее берет и замыкает два следующих порта eth кабелем.<br>STP строит дерево за счет BPDU пакетов, в данном случае к клиенту не отправляеться и не принимаеться BPDU, а пакеты тем не менее штурмуют все каталисты по пути. Как этого избежать?<br> https://opennet.ru/openforum/vsluhforumID6/17612.html#8 Thu, 11 Dec 2008 08:38:08 GMT Вообщето STP тема довольно сложноая... в курсе BSMCN рекомендуют при вводе каталиста в сеть отключать STP... В вашем же случае можно порекомендовать портам которые на данный момент рутовые запретить становится не рутами...<br><br> https://opennet.ru/openforum/vsluhforumID6/17612.html#7 Tue, 02 Dec 2008 09:36:53 GMT &gt;storm-control настроить на порту. <br><br>Насколько я понимаю, storm-control тоже не панацея... В документации (http://cisco.com/en/US/docs/switches/lan/catalyst2960/software/release/12.2_44_se/configuration/guide/swtrafc.html) написано, что при превышении некоторого конфигурируемого проргового значения, storm-control блокирует указанный тип трафика в следующий интервал времени (который для коммутаторов 2960/3560 равен 1 секунде). Получается, если представить, что клиентский порт генерит трафик, например, со скоростью 50к pps, то в результате получим:<br>на первой секунде - трафик 50k pps<br>на второй секунде - блокировнаие трафика<br>на третьей секунде - трафик 50k pps<br>на червертой секунде - блокирование<br>... (и так далее в шахматном порядке)<br><br>В среднеем имеем 25k pps... и эта цифра не зависит от указанного threshold'а...<br>Честно говоря, я не очень понимаю прелести этой (storm-control) технологии... по-моему вопрос остается открытым. поправте меня, если я не прав.<br><br>Спасибо. <br><br> https://opennet.ru/openforum/vsluhforumID6/17612.html#6 Tue, 18 Nov 2008 14:17:35 GMT &gt;ой, виноват, был не внимателен. действительно, в данном случае от bpduguard пользы <br>&gt;никакой не будет. извините. <br><br>Бывает.<br> https://opennet.ru/openforum/vsluhforumID6/17612.html#5 Tue, 18 Nov 2008 14:04:25 GMT ой, виноват, был не внимателен. действительно, в данном случае от bpduguard пользы никакой не будет. извините.<br> https://opennet.ru/openforum/vsluhforumID6/17612.html#4 Tue, 18 Nov 2008 13:13:28 GMT &gt;Как этого избежать? <br>&gt;<br>&gt;предлагаю включить на порту, который смотрит на клиента, технологию bpduguard <br><br>а, bpduguard тут причем? Объясни поподробнее. по моему bpduguard в циске для того чтобы работать с STP, и порт при попадании на него bpdu уходит в errdis и тем самым не создает петлю. <br>вот предидущее сообщение практически решает задачу, но со стороны broadcast storm, а как на счет unicast storm, тут все интереснне, ставлю 50% от скорости интерфейса и если клиент сжирает более 50% полосы, то начинаеться балансирование, sh storm-control unicast показывает плавающее состояние forvard Block, соответственно если не заморачиваться в принцыпы то ситуация похожа на rate-limit. Отличный плюс что ограничивая порты таким образом это все не дойдет до маршрутизатора, если подрозумевать схему "Маршрутизатор на привязи".&lt;-- это конечно бесспорный плюс, хотябы не все ляжет, а только один клиент, и частично скажеться на загрузке сети.<br><br><br> https://opennet.ru/openforum/vsluhforumID6/17612.html#3 Tue, 18 Nov 2008 13:02:15 GMT Как этого избежать?<br><br>предлагаю включить на порту, который смотрит на клиента, технологию bpduguard<br><br><br> https://opennet.ru/openforum/vsluhforumID6/17612.html#2 Tue, 18 Nov 2008 11:25:29 GMT &gt;Я так понимаю, что штормег возникает у клиента. Поэтому вам нужно просто <br>&gt;storm-control настроить на порту. <br><br>Тоесть STP спасает только от собственных косяков, а от чужих вообще никак не поможет?<br> https://opennet.ru/openforum/vsluhforumID6/17612.html#1 Tue, 18 Nov 2008 11:06:00 GMT Я так понимаю, что штормег возникает у клиента. Поэтому вам нужно просто storm-control настроить на порту.<br>