[Wingman]

К сожалению, stp я готовить не умею.

Однако очень хочется на l2+l3 аггрегаторах ловить петли, причем, желательно, на вланах, а не портах.

В качестве аггрегаторов у нас выступают 6500 и ME-4924-10GE

 

Почитав вечерок по теме, собрал небольшой стенд:

4924, а у неё на одном из портов - длинк с закольцованными двумя портами.

 

Конфиг:

spanning-tree mode rapid-pvst
spanning-tree loopguard default
! ...
interface GigabitEthernet1/7
switchport access vlan 107
switchport trunk encapsulation dot1q
switchport trunk native vlan 107
switchport trunk allowed vlan 107,4001
switchport mode trunk
speed nonegotiate
spanning-tree bpdufilter enable
spanning-tree guard loop
end

 

В 107 влане у нас петля, 4001 - управление длинка.

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

 

Собственно, так и происходит:

#sh spanning-tree blockedports

Name                 Blocked Interfaces List
-------------------- ------------------------------------
VLAN0107             Gi1/7

Влан блокируется, маков в нём нет, всё прекрасно.

 

Однако, если я включаю на длинке закольцованные порты, загрузка CPU на циске лавинообразно растёт до 100% ;*(

 

sh platform health говорит, что процессор грузит K2CpuMan Review. По идее, это mac learning, судя по гуглу.

 

Однако влан с петлёй ведь заблокирован =\ sh mac address-table - пустой; трафика на порту нет. На всякий случай замониторил брудкасты на порту и SVI - пусто:

 

 

Может быть кто подскажет, в какую сторону копать?

Конечная цель как раз не допускать ухода CPU в полку и отображение/логирование/блокировка вланов с петлями. (copp не предлагать, это немного другое)

[NikAlexAn]

Насколько помню включение bpdufilter блокирует приём и передачу bpdu на порту но 2-3 bpdu при включении и перезагрузке коммутатора пропускает.

Так что поиграв с портами на длинке влан 107 скорей всего вышел из состояния blocked, точнее в loop-inconsistent раз включен loop guard.

Вообще рекомендуют включать loop guard на root и alternate портах а с bpdufilter вообще поосторожней стоит быть.

 

стоит в таких случаях смотреть ещё

sh int status

sh span

sh span det

sh log

 

в общем - bpdufilter и guard loop уберите - порт должен блокироваться. Только вот количество экземпляров spanning-tree вовсе не бесконечная величина и зависит от модели и ios. Возможно что вашу задумку реализовать не получится на большом количестве агрегируемых вланов. Да и stp процессором обрабатывается.

а смотреть по snmp состояние stp - cisco-stp-extensions-mib.my вам в помощь.

Edited October 16, 2015 by NikAlexAn

[Wingman]

Насколько помню включение bpdufilter блокирует приём и передачу bpdu на порту но 2-3 bpdu при включении и перезагрузке коммутатора пропускает.

Имеется в виду перезагрузка коммутатора, на котором включен bpdufilter? Об этом речь не идёт в данном случае - он стоит в серверной, и перезагрузки довольно редки.

 

Так что поиграв с портами на длинке влан 107 скорей всего вышел из состояния blocked

В том-то и дело, что во время роста загрузки cpu я смотрю blockedports и вижу

 

#sh spanning-tree blockedports

Name                 Blocked Interfaces List
-------------------- ------------------------------------
VLAN0107             Gi1/7

 

стоит в таких случаях смотреть ещё

sh int status

sh span

sh span det

sh log

 

Интерфейс поднят; в логе один раз пролетело:

Oct 16 23:22:13: %SPANTREE-2-LOOPGUARD_BLOCK: Loop guard blocking port GigabitEthernet1/7 on VLAN0107

и с тех пор влан так и висел в заблокированных, а в логе ничего по этомту поводу больше не было

 

 

в общем - bpdufilter и guard loop уберите - порт должен блокироваться.

В том-то и дело, что мне не нужно, чтобы порт блокировался, мне хочется делать так, чтобы блокировался проблемный вилан. И он таки блокируется, но вот откуда берётся cpu load - непонятно ;(

 

А если убрать bpdufilter - кошак будет реагировать на левые bpdu от, например, клиентских роутеров или подглючивающих длинков, разве нет?

 

количество экземпляров spanning-tree вовсе не бесконечная величина и зависит от модели и ios

 

http://www.cisco.com/c/en/us/products/collateral/switches/me-4900-series-ethernet-switches/product_data_sheet0900aecd8052f36b.html

Scalability to 4094 Spanning Tree Protocol instances

 

Мне бы как раз хватило %)

 

 

 

edit: и ещё одна проблема: vlan107 до сих пор blocked, хотя включен `errdisable recovery all`, а петля выключена ещё вчера ;(

На блокировки stp рекавер не распространяется? ;(

Edited October 17, 2015 by Wingman

[iostream]

Конфиг:

spanning-tree mode rapid-pvst
spanning-tree loopguard default
! ...
interface GigabitEthernet1/7
switchport access vlan 107
switchport trunk encapsulation dot1q
switchport trunk native vlan 107
switchport trunk allowed vlan 107,4001
switchport mode trunk
speed nonegotiate
spanning-tree bpdufilter enable
spanning-tree guard loop
end

 

 

Если я не ошибаюсь - spanning-tree loopguard default и spanning-tree guard loop - одинаковые вещи. Команда default включает loopguard на всех портах, кроме аплинков.

 

Loopguard в cisco работает следующим образом - слушает, приходит ли на "Blocked" порт BPDU пакеты. Если поток BPDU прекращается - то порт переводится в статус Loop-Inconsistent. Поэтому команда spanning-tree gurard loop или spanning-tree loopguard default вас, имхо, не спасет :)

 

bpdufilter - предотвращает отправление bpdu с этого порта и обработку bpdu пришедших на этот порт. Т.е по факту отключает STP на определенном порту...

Поэтому, я предположу, у вас и растет CPU - "скрестили" loopguard и bpdufilter.

 

Поэтому предлагаю убрать функции, с которыми еще не разобрались и оставить чистый rstp:

 

spanning-tree mode rapid-pvst

! ...

interface GigabitEthernet1/7

switchport trunk encapsulation dot1q

switchport trunk native vlan 107

switchport trunk allowed vlan 107,4001

switchport mode trunk

speed nonegotiate

end

 

После этого - при включении "петли" на д-линке у вас начнуть приходить bpdu на порт cisco, с которого они уходили. Ну и циска, видя "родные" bpdu заблокирует этот порт во влане, где ей возвращаются bpdu (в нашем случе - 107).

 

Р.с: Петли надо начинать отлавливать с уровня доступа - на длинках прописать loopdetect , ограничить broadcast traffic control'ом и т.д...

[Wingman]

bpdufilter - предотвращает отправление bpdu с этого порта и обработку bpdu пришедших на этот порт. Т.е по факту отключает STP на определенном порту...

Поэтому, я предположу, у вас и растет CPU - "скрестили" loopguard и bpdufilter.

 

Да, я примерно в эту сторону и думал, и как раз сейчас вот отключил и loopguard и bpdufilter.

Однако картина ровно та же: порт (влан) переходит в blockedports, но загрузка CPU один хрен так и растёт до 100% ;(

 

 

Р.с: Петли надо начинать отлавливать с уровня доступа - на длинках прописать loopdetect , ограничить broadcast traffic control'ом и т.д...

Это всё естественно, однако не всегда, к сожалению, длинки ловят петли как надо.

 

p.s. Вообще ноги отсюда растут: http://forum.nag.ru/forum/index.php?showtopic=109225&st=0&p=1185744&fromsearch=1entry1185744

Из-за этого и решил освоить stp для лупдетекта в ядре

[Wingman]

Чуть больше дебага:

 

Добавил в мониторинг ещё и мультикаст, оказалось, что при петле на инпуте >200kpps мультика прилетает.

Подебажил `debug platform packet all receive buffer` + `show platform cpu packet buffered`, оказалось, что прилетает тьма таких вот пакетов:

 

Index 2:
0 days 19:31:17:855096 - RxVlan: 107, RxPort: Gi1/7
Priority: Normal, Tag: No Tag, Event: Input Acl, Flags: 0x40, Size: 68
Eth: Src 00:24:14:4E:75:06 Dst 01:00:0C:CC:CC:CD Type/Len 0x0032
Remaining data:
0: 0x0  0x0  0x2  0x2  0x3C 0x80 0x6B 0x0  0x24 0x14
10: 0x4E 0x75 0x0  0x0  0x0  0x0  0x0  0x80 0x6B 0x0
20: 0x24 0x14 0x4E 0x75 0x0  0x80 0x7  0x0  0x0  0x14
30: 0x0  0x2  0x0  0xF  0x0  0x0  0x0  0x0  0x0  0x2
40: 0x0  0x6B

Index 3:
0 days 19:31:17:855133 - RxVlan: 107, RxPort: Gi1/7
Priority: Normal, Tag: No Tag, Event: Input Acl, Flags: 0x40, Size: 68
Eth: Src 00:24:14:4E:75:06 Dst 01:00:0C:CC:CC:CD Type/Len 0x0032
Remaining data:
0: 0x0  0x0  0x2  0x2  0x3C 0x80 0x6B 0x0  0x24 0x14
10: 0x4E 0x75 0x0  0x0  0x0  0x0  0x0  0x80 0x6B 0x0
20: 0x24 0x14 0x4E 0x75 0x0  0x80 0x7  0x0  0x0  0x14
30: 0x0  0x2  0x0  0xF  0x0  0x0  0x0  0x0  0x0  0x2
40: 0x0  0x6B

 

Dst 01:00:0C:CC:CC:CD = Cisco Shared Spanning Tree Protocol Address

 

То есть, на заблокированном порту/влане циска один хрен мониторит прилетающие bpdu и, поскольку там петля, stp кладёт нахрен её проц ><

 

С этим-то, блин, что можно придумать? Зарезать рейтлимит? Copp? В принципе, поскольку на сети stp не используется, можно большую часть его безболезненно дропать при попадании на проц...

Не понос, так золотуха, блин :))

 

 

 

----

 

update: таки да. Зарезал в copp system-cpp-sstp и system-cpp-cdp на минимумы (32000/1000):

   Class-map: system-cpp-cdp (match-all)
     33980223 packets
     Match: access-group name system-cpp-cdp
     police: Per-interface
       Conform: 247040 bytes Exceed: 618060288 bytes

   Class-map: system-cpp-sstp (match-all)
     34196655 packets
     Match: access-group name system-cpp-sstp
     police: Per-interface
       Conform: 242148 bytes Exceed: 532714040 bytes

Про cdp вообще странно, т.к. "no cdp run" =\

 

И загрузка cpu не поднимается выше 12%

 

 

Осталось придумать:

- как логировать topology change для оперативного реагирования ( у нас централизованный сислог, на котором лог парсится на лету и кидаются оповещения, трапы ловить не хочется )

`spanning-tree logging` включен, но в логи оно не срёт ;(

- как всё-таки обезопаситься от bpdu со стороны абонентов и собственных свитчей, которые могут сглючить. bpdufilter ведь не катит, как выяснилось ;(

Edited October 17, 2015 by Wingman

[applx]

у вас странные понятия о bpdufilter он фильтрует bpdu исходяшие а не входящие а еше storm-control повесить неплохо было бы.

[Wingman]

Гхм.

 

Caution Be careful when you enter the spanning-tree bpdufilter enable command on specified interfaces. Explicitly configuring BPDU Filtering on a port this is not connected to a host can cause a bridging loop because the port will ignore any BPDU that it receives, and the port moves to the STP forwarding state.

[NikAlexAn]

у вас странные понятия о bpdufilter он фильтрует bpdu исходяшие а не входящие а еше storm-control повесить неплохо было бы.

 

Не так

"You always should allow STP to run on a switch to prevent loops. However, in special cases when you need to prevent BPDUs from being sent or processed on one or more switch ports, you can use BPDU filtering to effectively disable STP on those ports.you would use bpdufilter when you want a switch plugged into your network but you don't want it participating in spanning tree."

 

To TC: Правда это не означает что stp и его варианты являются этакой вундервафлей для защиты сети на уровне агрегации от глюков нижестоящего и абонентского оборудования.

Кстати stp/rstp/mst bpdu вроде как ни одно и тоже что cisco pvst bpdu и, если не ошибаюсь, свичи длинк работают с последними как с обычными пакетами l2.

Полисингом stp в copp вы ограничиваете количество обрабатываемых bpdu и если такое у вас с петлёй на одном влане то, представьте, сколько будет у вас в сети bpdu если включите spanning-tree на всех вланах.

bpdufilter блокирует отправку и обработку bpdu на порту но это вовсе не значит что с помощью этой фичи можно бороться с абонентскими bpdu на агрегации. С абонентскими bpdu (да и другими глюками типа петель и штормов) надо бороться там где они возникают а отсекать на абонентских портах коммутаторов доступа.

Edited October 17, 2015 by NikAlexAn

[Wingman]

To TC: Правда это не означает что stp и его варианты являются этакой вундервафлей для защиты сети на уровне агрегации от глюков нижестоящего и абонентского оборудования.

Кстати stp/rstp/mst bpdu вроде как ни одно и тоже что cisco pvst bpdu и, если не ошибаюсь, свичи длинк работают с последними как с обычными пакетами l2.

Полисингом stp в copp вы ограничиваете количество обрабатываемых bpdu и если такое у вас с петлёй на одном влане то, представьте, сколько будет у вас в сети bpdu если включите spanning-tree на всех вланах.

bpdufilter блокирует отправку и обработку bpdu на порту но это вовсе не значит что с помощью этой фичи можно бороться с абонентскими bpdu на агрегации. С абонентскими bpdu (да и другими глюками типа петель и штормов) надо бороться там где они возникают а отсекать на абонентских портах коммутаторов доступа.

 

Это я уже понял :) Начал потихоньку включать на живой сети - при включении на одном из абонентских вланов CPU опять же уходит в полку ;( При том, что на всём акцесе bpdu на абонентских портах зафильтрованы.

Думаю дальше...

[iostream]

А можете приложить конфиг d-link - интересно увидеть sh vlan и укажите, где аплинк на Cisco?

 

И еще - у вас топология сейчас в лабе какая? Просто порт Cisco воткнут в д-линк ( без stp) на котором делаете петлю? Или все же двумя портами подключаете между собой?

 

На живой сети - топология кольцо?

[Wingman]

Да длинк тупо дефолтный; стп выключен, лупдетект выключен, вланы:

 

Command: show config effective include "vlan"
disable igmp_snooping multicast_vlan
config vlan default add untagged 1-10
config vlan default advertisement enable
create vlan 4001 tag 4001
config vlan 4001 add tagged 9-10 advertisement disable
disable vlan_trunk
config port_vlan 1-10 gvrp_state disable ingress_checking enable acceptable_frame admit_all pvid 1
config ipif System vlan 4001

Петля между 1-2 портами (дефолтный влан, он же нейтив 107 на кошаке), аплинк в циску - 10, влан 4001 - для управления

 

Собсно на длинке всё завелось как хотелось, но на живой сети, как я написал выше, при включении stp на одном из вланов происходит коллапс. Правда, лаба на 4924, а на живой сети ковырял 6500 с SUP720-3B

 

На живой сети - везде звезда, stp нигде не используется.

Edited October 17, 2015 by Wingman

[iostream]

Эм.., ну тогда как один из вариантов - bpdu guard вам в помощь.

 

Настраиваете на всех интерфейсах, куда смотрят отдельные линки.

Смысл сего - агрегатор ( кошка 4924) будет сама слать BPDU пакеты на уровень доступа. В случае, если на доступе есть петля в каком-то VLAN - этоn BPDU вернется на циску и она, согласно гуарду должна будет залочить этот VLAN на этом порту. Далее настраиваете err-disable recovery на cisco и отсыл трапов в случае блокировки порта. Потом ищем источник петель и разбираемся с ними уже на доступе...

Edited October 17, 2015 by iostream

[Wingman]

iostream, это было бы супер, но

1) разве bpduguard не заблочит весь порт?

2) разве bpduguard не срабатывает на _любой_ bpdu, а не только на свой вернувшийся?

Edited October 17, 2015 by Wingman

[NikAlexAn]

bpduguard только для access портов.

для транковых - bpduguard trunk.

и тот и другой шутданят порт а не влан.

 

На длинках(да и на других коммутаторах) есть bpdu forward на уровне порта и loopdetect - стоит начинать оттуда и + ещё stormcontrol включать в сторону абонентов.

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

 

А stp в принципе отрабатывает все пришедшие bpdu и независимо от состояния порта (forward/block) а вот какая будет реакция - зависит от информации в этом пакете и настроек stp на свиче и порту.

Edited October 17, 2015 by NikAlexAn

[Wingman]

loopdetect - стоит начинать оттуда и + ещё stormcontrol включать в сторону абонентов.

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

[iostream]

Wingman

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

Ну а про то, что реагирует на любые bpdu - так вам же это и нужно вроде, нет? (топология звезда, на доступе везде STP выключен - следовательно BPDU взяться неоткуда, кроме как с самой циски ( ну или с клиентского порта))

[NikAlexAn]

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

Если что то не отработало на коммутаторе доступа то вполне возможно что этот коммутатор или какой то его порт неисправен.

Эксплуатирую сеть из нескольких колец разнотипных свичей замыкающихся на 6509/sup720-3b - помнится пришлось прилично повозиться чтоб подобать оптимальные настройки и вычислить глючные порты и коммутаторы а потом стало значительно легче :)

Вроде как киски не пишут в лог изменение stp статуса порта/влана.

Но с помощью snmp можно контролировать состояние stp.

sh span det показывает счётчики bpdu и tcn для каждого экземпляра stp(не помню можно ли это посмотреть через snmp).

кстати в режиме pvst/rapid pvst stp на конкретном влане отключается командой no spann vlan XXX.

 

Добавлю. Хоть stp на коммутаторах доступа и выключен - настройте и убедитесь что bpdu от абонентов в сеть не пролазят.

И не забывайте про priority экземпляров stp , на root свиче лучше для всех вланов сделать приоритет "0" то есть наивысший.

Edited October 17, 2015 by NikAlexAn

[Wingman]

Если что то не отработало на коммутаторе доступа то вполне возможно что этот коммутатор или какой то его порт неисправен.

Это понятно :) Но если шторм/петля плавающие, а коммутаторов несколько тысяч - то найти такой свитч без подсказки аггрегатора - может стать делом не одного дня ;(

 

Вроде как киски не пишут в лог изменение stp статуса порта/влана.

В принципе, при `debug span events` - пишут, ну или трапы ловить, как вариант

 

кстати в режиме pvst/rapid pvst stp на конкретном влане отключается командой no spann vlan XXX.

Да, я в курсе :)

 

Ну а про то, что реагирует на любые bpdu - так вам же это и нужно вроде, нет? (топология звезда, на доступе везде STP выключен - следовательно BPDU взяться неоткуда, кроме как с самой циски ( ну или с клиентского порта))

Теоретически - да, но для начала нужно на всех свитчах зафильтровать bpdu от юзеров; хотя это и не очень большая проблема

А кроме того, есть остатки всяких DGS-3100, например, на которых лупдетект тоже только средствами STP реализован; выключать - не хочется

[iostream]

Теоретически - да, но для начала нужно на всех свитчах зафильтровать bpdu от юзеров; хотя это и не очень большая проблема

А кроме того, есть остатки всяких DGS-3100, например, на которых лупдетект тоже только средствами STP реализован; выключать - не хочется

 

Ну выключите тогда только на магистральных портах дгсов stp. Тогда он выше не поднимется.

Как вариант, чтобы отлавливать петли силами stp - на доступе настройте stp только на клиентских портах, а на аплинках выключите ( при этом разрешив форвардинг bpdu). Тогда в случае петли будет ложиться порт на свитче доступа (ну а как настраивать трапы для этого сами разберётесь :))

[Wingman]

Да я вообще уже думаю попробовать на

портах кошки ацлями зарезать бпду,

пропуская только те, в которых dst Mac = мак циски)

Осталось только выяснить, какие маки она пихает в пакеты: везде один, или на каждый влан/порт свой)

[xcme]

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

Syslog же :) и MAC-notify trap (интересует событие mov). И можно будет видеть петли практически онлайн.

[Wingman]

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

Syslog же :) и MAC-notify trap (интересует событие mov). И можно будет видеть петли практически онлайн.

Гм, а попробуем, поковыряем, спасибо ж)

 

А нет на длинках mac-move / mac-flap, навскидку =(

[xcme]

А нет на длинках mac-move / mac-flap, навскидку =(

Трап прилетает при появлении мака на порту, его исчезновении или перемещении мака на другой порт. Обычно это перемещается мак шлюза из-за петли на абонентском порту.

[Wingman]

Понял, спасибо, попробуем-с