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

Срабатывание LBD на доступе блокирует VLAN по STP

Доброго всем, коллеги!

 

Помогите советом. Условно сеть передачи данных с PPPoE BRAS:

 

post-45790-023801200 1432111003_thumb.png

 

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

На каталисте в ядре сети вижу, что spaning tree (PVST) блокирует 205 VLAN (Self-looped).

Изучение логов коммутаторв доступа показало, что на дэлинке срабатывает loopback detect

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

 

Почему такое происходит и как побороть?

Share this post


Link to post
Share on other sites

отключить на катклисте stp в этом vlan

Share this post


Link to post
Share on other sites

Изучение логов коммутаторв доступа показало, что на дэлинке срабатывает loopback detect

на порту одного из абонентов.

выключить порт этого абонента до устранения неисправности (замена порта/сетевой)

 

отключить на катклисте stp в этом vlan

и ловить здецы каждый раз как длинк по рекавери поднимает порт ;)

 

Кошак блочит влан как только ловит признак петли в bpdu, а это значит что bpdu успел пройти от кошака до длинка, попасть на проблемный порт и вернуться. Т.е. происходит это в как только порт поднялся по рекавери таймауту, и не успел еще пройти интервал опроса длинковского loopdetect. Можно конечно таймеры накрутить - увеличить рекавери, чтоб успеть починить/погасить порт до следущего подъема, и уменьшить интервал опроса (штатно там вроде как 10 секунд, понижается до 2 секунд), последнее может немножко поднять нагрузку на cpu длинка.

Share this post


Link to post
Share on other sites

не будет ничего плохого - кольцо не по vlan-е управления ведь. а в dlink можно интервал проверки 1 секунду установить.

Share this post


Link to post
Share on other sites

Изучение логов коммутаторв доступа показало, что на дэлинке срабатывает loopback detect

на порту одного из абонентов.

выключить порт этого абонента до устранения неисправности (замена порта/сетевой)

Ну я собственно это и сделал. Но это временное решение. Непонятно почему вообще такое происходит.

STP выключен на дэлинках глобально, на портах доступа:

config stp ports 1-24 externalcost auto edge true restricted_tcn false restricted_role false p2p auto state disable priority 128 hellotime 2 fbpdu enable

То есть BPDU должны фильтроваться.

отключить на катклисте stp в этом vlan

и ловить здецы каждый раз как длинк по рекавери поднимает порт ;)

 

Кошак блочит влан как только ловит признак петли в bpdu, а это значит что bpdu успел пройти от кошака до длинка, попасть на проблемный порт и вернуться. Т.е. происходит это в как только порт поднялся по рекавери таймауту, и не успел еще пройти интервал опроса длинковского loopdetect. Можно конечно таймеры накрутить - увеличить рекавери, чтоб успеть починить/погасить порт до следущего подъема, и уменьшить интервал опроса (штатно там вроде как 10 секунд, понижается до 2 секунд), последнее может немножко поднять нагрузку на cpu длинка.

Видимо как-то так.

Share this post


Link to post
Share on other sites

То есть BPDU должны фильтроваться.

Где же оно фильтруется то? В команде fbpdu enable стоит, если в sh stp будет forward bpdu enable (при глобально выключенном stp, а по умолчанию оно так и есть), то можно сказать что вобще все плохо - это наоборот форвардит bpdu между портами без какого-либо вмешательства, что чревато очередными здецами, если кто воткнет в сеть мыльницу с stp root'ом.

И если зафлудил именно порт (пожгло грозой или еще почему) то там никакой фильтр не спасет - пакеты будут петлять на уровне чипсета.

 

не будет ничего плохого - кольцо не по vlan-е управления ведь. а в dlink можно интервал проверки 1 секунду установить.

С точки зрения менеджмента да, ничего плохого. А теперь давайте на минуту представим, что вы абонент, которому "повезло" сидеть на соседнем порту данного коммутатора. Сегодня, когда в каждом населенном пункте по 3-4 конкурента, и цена за подключения чисто символическая или отсутствует вовсе, такое вот "повезло" приводит к потере абонентов.

Share this post


Link to post
Share on other sites

То есть BPDU должны фильтроваться.

Где же оно фильтруется то? В команде fbpdu enable стоит, если в sh stp будет forward bpdu enable (при глобально выключенном stp, а по умолчанию оно так и есть), то можно сказать что вобще все плохо - это наоборот форвардит bpdu между портами без какого-либо вмешательства, что чревато очередными здецами, если кто воткнет в сеть мыльницу с stp root'ом.

И если зафлудил именно порт (пожгло грозой или еще почему) то там никакой фильтр не спасет - пакеты будут петлять на уровне чипсета.

Вот блин! У меня просто голова уже вспухла от разнообразия вендоров, думал fbpdu - это bpdu filtering.

Спасибо за пинок в нужном направлении!

 

Только в такой конфигурации stp на свиче VLAN перестаёт блокироваться из-за лупа:

 

disable stp
config stp fbpdu disable
config stp ports 1-24 externalcost auto edge true restricted_tcn false restricted_role false p2p auto state priority 128 hellotime 2 fbpdu disable
config stp ports 25-28 externalcost auto edge auto restricted_tcn false restricted_role false p2p auto state disable priority 128 hellotime 2 fbpdu disable

 

То есть нужно полностью выключать хождение BPDU, которое по дефолту разрешено на всех портах даже при отключенном STP.

Этот «сюрприз» от D-Linka имеет место именно в этой модели. На 3200 сериях, 3526 и 1228 дефолтно форвардинг BPDU запрещён.

Edited by Yoda

Share this post


Link to post
Share on other sites

у длинка bpdu filter идет через отдельный функционал:

enable bpdu_filter
conf bpdu_filter ports 1-24 mode drop state enable
conf bpdu_filter recover inf 

Как-то так. На младших сериях bpdu filter работает только если глобально включен stp, и длинк когда-то давно обещал это дело поправить, но увы, пока все без изменений.

Share this post


Link to post
Share on other sites

у длинка bpdu filter идет через отдельный функционал:

enable bpdu_filter
conf bpdu_filter ports 1-24 mode drop state enable
conf bpdu_filter recover inf 

Как-то так. На младших сериях bpdu filter работает только если глобально включен stp, и длинк когда-то давно обещал это дело поправить, но увы, пока все без изменений.

Сейчас глянул в 1210-28 — есть только enable bpdu_protection видимо обозвали по-другому.

Не знаю как уживается loopdetect с stp на Huawei-ях, ещё не было ни одного срабатывания. А вот

D-Link часто. Было даже пара случаев, когда порты замыкались между собой в коммутационной

матрице.

Share this post


Link to post
Share on other sites

darkagent

С китайцами вообще весело. Вот нашёл в доке 9303 хуавея замечательную команду: traffic-pppoe,

которая волшебным образом запрещает на интерфейсе всё кроме 0x8863 и 0x8864. Но применить её можно только на физическом

интерфейсе! Соответственно пользы от неё ровно 0, если на этот порт подключен сегмент сети, а не один-единственный абонент.

Edited by Yoda

Share this post


Link to post
Share on other sites

darkagent

С китайцами вообще весело. Вот нашёл в доке 9303 хуавея замечательную команду: traffic-pppoe,

которая волшебным образом запрещает на интерфейсе всё кроме 0x8863 и 0x8864. Но применить её можно только на физическом

интерфейсе! Соответственно пользы от неё ровно 0, если на этот порт подключен сегмент сети, а не один-единственный абонент.

 

что мешает применять только на конечных абонентских портах?

Share this post


Link to post
Share on other sites

что мешает применять только на конечных абонентских портах?

 

На доступе (S2326 и S3328) этого функционала нет. Там есть только L2 acl, которые ещё настроить, протестировать и навестить

на каждый порт абонентский нужно.

 

P.S. На доступе у нас вообще зоопарк из разных моделей и ревизий D-Link'ов, упомянутых Huawei'ев и Compex'ов PS2216

Edited by Yoda

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this