Jump to content
Калькуляторы

cisco and mstp

Знатоки cisco прошу помощи.

 

Имеется простейшая схема сети, с коммутатором nexus 3000 в центре.

На коммутаторе активен mstp. В mstp сидят все имеющиеся вланы (порядка 4К).

 

Если на коммутаторе любой порт уходит в UP/DOWN, получаю topology change, в итоге полная очистка таблицы мак адресов, пока мак таблица не успела заполниться - имеем флуд трафика во все порты. Маков на коммутаторе порядка 30К.

Во время пустой мак таблицы и флуда по сути нарушается работа всей сети, линки переполнены трафиком.

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

 

Как то можно вылечить это дело?

 

Из того что сам думаю:

 

Использование spanning-tree portfast, но это решает проблему частично, т к работает только на портах в режиме access. Многие сервера имеют trunk порты.

 

Увеличение числа mst инстансов и привязка в них разных групп вланов, так явно будет легче т к мак таблица будет очищаться не полностью. Максимум инстансов 64.

 

На rapid-pvst как я понял перейти не получиться, у нексуса максимум 512 можно задействовать в rapid-pvst.

Share this post


Link to post
Share on other sites

Ого! Спасибо!

Т.е. всё не так плохо. :-)

Сейчас пробегаюсь по портам и там где транки расставляю spanning-tree portfast trunk

Share this post


Link to post
Share on other sites

Насколько я понял там где на транковых портах именно сервера можно смело выставлять команду?

Есть ещё порты на которых висит другой нексус и он в stp топологии, естественно там это включать нельзя.

Share this post


Link to post
Share on other sites

а почему бы в сторону серверов не отключить STP совсем? или на корне дерева сделать restrict tcn на некольцевые линки - это будет дропать tcn и во все дереве не будет flush и перестроения.

Share this post


Link to post
Share on other sites

зачем? портфаст для этого сделан, пусть и работает, а то начнется, тут дропаем, тут не дропаем, тут вдруг окольцевалось, там раскольцевалось, и понеслась

Share this post


Link to post
Share on other sites

А зачем СТП на интерфейсе где заведомо не может быть петли, тем более если у автора коммутатор, где флапы порта ведут к простою, тем более в ядре? с портфастом этот простой меньше, но он же никуда не денется.

 

А для нексусов это вообще норма с перестроением топологии и очисткой мак таблицы? mstp ковырять не доводилось, но если это особенность протокола, то довольно странная. Прошивкой может фиксится?

Share this post


Link to post
Share on other sites

"А зачем СТП на интерфейсе где заведомо не может быть петли"

я абсолютно согласен не зачем

но циска не даёт стп вырубить на интерфейсе

 

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

без этого у меня была перестройка топологии и количество маков до 0 падало! пока таблица не заполнялась был флуд

spanning-tree portfast trunk

spanning-tree portfast

 

http://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/12013-17.html#anc12

Avoid TCN Generation with the portfast Command

 

The portfast feature is a Cisco proprietary change in the STP implementation. The command is applied to specific ports and has two effects:

 

Ports that come up are put directly in the forwarding STP mode, instead of going through the learning and listening process. The STP still runs on ports with portfast.

 

The switch never generates a TCN when a port configured for portfast goes up or down.

 

Enable portfast on ports where the connected hosts are very likely to bring their link up and down (typically end stations that users frequently power cycle). This feature should not be necessary for server ports. It should definitely be avoided on ports that lead to hubs or other bridges. A port that directly transitions to forwarding state on a redundant link can cause temporary bridging loops.

 

Topology changes can be useful, so do not enable portfast on a port for which a link that goes up or down is a significant event for the network.

Edited by 704114

Share this post


Link to post
Share on other sites

 

сегодня может не быть, завтра может быть

 

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

 

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

Share this post


Link to post
Share on other sites

сегодня может не быть, завтра может быть

 

сам недавно с таким столкнулся. тут лучше перебздеть, чем недобздеть.

Share this post


Link to post
Share on other sites

повторю что для кошака с mstp не нашёл способ выключить stp конкретно на интерфейсе

судя по всему этого сделать нельзя

 

но если кто покажет как это делать буду рад :-)

Share this post


Link to post
Share on other sites

никто до сих пор не написал зачем это делать, и что это даст чего нет сейчас

Share this post


Link to post
Share on other sites

Ну на роутед портах по-моему его еще никто не пытался его включать, а на л2 он и так должен быть везде

Share this post


Link to post
Share on other sites

Join the conversation

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

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.