Switch cisco
spanning-tree
Нельзя на порту отключить stp, поэтому так. И loopback-detection нет на старом железе. Вот только недавно где-то сделали.
Bdpufilter фильтрует в обе стороны, т.е. коммутатор отбрасывает все входящие BPDU и не отправляет BPDU в порт.
Логично фильтр повесить на порты, которые никак не участвуют в кольцевой топологии, с которых никогда не придет BPDU,
например, на порт подключения сервера, на порт подключения маршрутизатора, на стык с провайдером.
Особо странный провайдер включает на порту клиента bpduguard и отключит порт при получении bpdu от вашего коммутатора.
Поэтому на операторских стыках необходимо вешать фильтр всегда. Чтобы при изменении топологии данные порты не проходили все возможные фазы blocking, listening, learning, а переходили сразу в forwarding,
необходимо включать portfast.
Необходимо учесть, что включенный spanning-tree portfast на транковом порту работать не будет.
Тут нужен spanning-tree portfast trunk или spanning-tree portfast edge trunk как в этом примере.
interface GigabitEthernet1/0/1
description Server
switchport access vlan 100
switchport mode access
spanning-tree portfast edge
spanning-tree bpdufilter enable
interface GigabitEthernet1/0/2
description Router
switchport trunk encapsulation dot1q
switchport mode trunk
spanning-tree portfast edge trunk
spanning-tree bpdufilter enable
interface GigabitEthernet1/0/3
description Internet
switchport access vlan 5000
switchport mode access
spanning-tree portfast edge
spanning-tree bpdufilter enable
interface GigabitEthernet1/0/4
spanning-tree bpdufilter enable
spanning-tree bpduguard enable
interface GigabitEthernet1/0/5
description User
switchport access vlan 200
switchport mode access
spanning-tree portfast edge
spanning-tree bpduguard enable
errdisable recovery cause bpduguard
errdisable recovery interval 120
Кажется, что mstp сложен для внедрения, но если поставить себе более простую задачу – создание аналога RSTP, то все сильно упрощается. Необходимо для начала определить для себя минимально необходимое количество инстансов. Пусть будет всего один, в который будут включены вообще все возможные вланы. Такая конфигурация никогда не будет изменяться, поэтому можно не читать про номера ревизий и т.п. Здесь в качестве нулевого - cist, через который mstp будет взаимодействовать с другими протоколами, а в первом msti - все возможные вланы. В качестве примера для 0 и 1 увеличены приоритеты. Бывает, что для 1-го увеличишь, а для cist - нет. При получении pvst bpdu порт переключается в режим совместимости и mstp перестает работать. Поэтому pvst надо фильтровать или недопускать подключение ненастроенных коммутаторов cisco.
spanning-tree mst configuration
name acb
revision 1
instance 1 vlan 1-4094
spanning-tree mode mst
spanning-tree mst 0-1 priority 28672
- У вас есть коммутаторы с ограничением по количеству активных вланов: 256 или 1024.
- Если вы используете vtp протокол для создания вланов, то есть вероятность превышения лимита, из-за которого для определенных вланов инстанс stp создан не будет. Это 100% кольцо; неудобно администрировать кучу инстансов;
- загрузка cpu на коммутаторе тем выше, чем больше инстансов.
В стандартном RSTP ничего этого нет, поэтому самый простой способ оптимизировать сеть на старых коммутаторах cisco – настроить MSTP. Почему протокол spanning-tree не защищает от петель? Коммутатор, который отправил BPDU, по понятным причинам не может и не должен контролировать его получение другими коммутаторами, а для рассылки BPDU использует мультикастовый адрес. Между коммутаторами могут происходить разные события, из-за которых какой-то коммутатор не получит BPDU, переведет порт из состояния alternate в состояние forwarding хоть и на короткое время, но этого будет вполне достаточно. Такое может случиться когда:
- возникла односторонняя связь на оптических линках;
- между коммутаторами включился half-duplex, что привело к множественным ошибкам и потерям;
- на вашей транспортной сети из-за ошибок больше не передается мультикаст в принципе;
- через операторские сети BPDU перестали передаваться, если вообще хоть кто-то когда-то из операторов такое разрешает;
- вы просто ошиблись с конфигурацией оборудования, не смогли предусмотреть каких-то нюансов, что происходит чаще всего.
В случае использования коммутаторов Cisco следует:
- изменить схему включения, если по какой-то причине stp настроили в ШБД точка-многоточка, хотя для нормальной работы надо p2p линки;
- настроить Unidirectional Link Detection (UDLD) протокол для оптических линков на случай односторонней связи;
- настроить spanning-tree loopguard для блокировки порта до соседнего коммутатора на случай, когда BPDU не будет получен по любой причине;
- настроить Connectivity Fault Management (CFM), если у вас metro-серия коммутаторов.
В случае использования коммутаторов других производителей или какого-то транспортного оборудования можно заметить, что:
- UDLD протокол можно применить только между коммутаторами cisco, так как это их разработка;
- аналога spanning-tree loopguard на коммутаторе может не быть;
- надо настраивать "link-fault-management" (802.3ah) или “connectivity-fault-management" (802.3ag)
Выводы:
- CFM 802.3ag полезен для определения состояния линка;
- При наличии только loopguard из всего выше перечисленного можно себя обезопасить от потери BPDU, но только если линки p2p а не точка-многоточка.
save config
Конфигурации можно сохранять с маршрутизаторов и коммутаторов cisco несколькими способами: * настроить archive и оборудование будет сохранять конфигурацию автоматически, либо после записи конфигурации в память устройства; * настроить kron и оборудование будет сохранять конфигурацию автоматически; * настроить cisco event manager для сохранения конфигурацию по какому-либо событию; * командой write net .. данной вручную или скриптом с сервера; * командой sh startup-config | tee .. данной вручную или скриптом с сервера; * включить scp и запустить на удаленном сервере копирование; * сохранить по tftp, отравив snmp-запрос на запись с удаленного сервера; * любыми скриптами или ansible'ом выполнить sh run и сохранить вывод в файл. Возможно, наиболее безопасным способом будет копирование конфигурации по протоколу ssh, однако не во всех версиях IOS он присутствует. При условии уже настроенного ssh в IOS, включить scp:
ip scp server enable
scp hostname:startup-config /backup/hostname
dhcp-snooping
Тут нет такого как на джуниперах и в случае L3 коммутатора dhcp-snooping работает. Есть ограничение на использование совсем старых флешек с файловой системой Low End File System, которая предусматривает очистку файловой системы от удаленных файлов вручную. На коммутаторе настраивается dhcp-snooping очень привычно.
ip dhcp snooping vlan [диапазон или список через запятую]
no ip dhcp snooping information option
ip dhcp snooping database flash:/имя_файла
ip dhcp snooping
interface GigabitEthernet0/1
ip dhcp snooping trust
mls qos
Без лишней необходимости включать qos на коммутаторе не нужно. Это касается и cisco voip autoqos, в частности. Как минимум, необходимо убедиться в корректной маркировке пакетов телефонами или кодеками, иначе будет только хуже. Если qos на коммутаторе выключен:
- с высокой вероятностью дропов на портах нет;
- все порты доверяют меткам cos и dscp по-умолчанию;
- для всех портов одинаковые и малоизвестные настройки очередей, где для трафика выделено от 90% полосы и буферов.Часть буферов может быть зарезервирована для network control. Передача данных с разными метками через порт коммутатора возможна на скорости близкой к скорости порта, но за счет буферизации может немного вырасти jitter; возможны дропы в буфере коммутации, но это уже зависит от чипа, который использовал производитель коммутаторов. В чипе может не хватить памяти, либо он обрабатывает эту память недостаточно быстро, я не знаю наверняка. Например, в сети могут возникать т.н. микробёрсты - большой объем данных, переданных за короткое время, которые могут передаваться через гигабитный интерфейс без потерь, к примеру, а при коммутации в 100мбит/с интерфейс, куда включен ip-телефон и ПК, эти данные могут быть частично потеряны.
Если qos на коммутаторе включен и никаких предварительных настроек не проводилось:
- порты не доверяют меткам cos или dscp;
- начинают работать 4 исходящие очереди с одинаковыми настройками. Поскольку все метки снимаются, то весь трафик попадет в одну очередь, которая почти в 4 раза меньше той, которая была при выключенном qos.
- с высокой вероятностью появляются дропы на портах. Их можно посмотреть командой sh int counters errors в столбце OutDiscards;
- с буфером коммутации ситуация не поменялась, но поскольку метки сбросились, то все попадает в одну входящую очередь из двух.
Практически все устройства так или иначе поддерживают маркировки, которые можно посмотреть в таблице QoS.
Для ip-телефонии и видеоконференцсвязи часто используются следующие значения dscp:
| dscp dec | dscp class | desc |
|---|---|---|
| 46 | ef | медиа (rtp) |
| 24 | cs3 | сигнализация (sip,h323,unistim) |
| 32 | cs4 | видео c кодеков(rtp) |
| 34 | af41 | видео с телефона, софтового клиента, кодека (rtp) |
| 0 | be | весь остальной трафик без маркировки. |
Для начала рекомендуется изучить вывод следующих команд и понять какой "dscp" в какую очередь попадет. 34 - 3 по горизонтали, 4 по вертикали. В исходящей очереди это будет очередь 4 и трешхолд 1
SWITCH#sh mls qos maps dscp-input-q
Dscp-inputq-threshold map:
d1 :d2 0 1 2 3 4 5 6 7 8 9
------------------------------------------------------------
0 : 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01
1 : 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01
2 : 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01
3 : 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01
4 : 02-01 02-01 02-01 02-01 02-01 02-01 02-01 02-01 01-01 01-01
5 : 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01
6 : 01-01 01-01 01-01 01-01
SWITCH#sh mls qos maps dscp-output-q
Dscp-outputq-threshold map:
d1 :d2 0 1 2 3 4 5 6 7 8 9
------------------------------------------------------------
0 : 02-01 02-01 02-01 02-01 02-01 02-01 02-01 02-01 02-01 02-01
1 : 02-01 02-01 02-01 02-01 02-01 02-01 03-01 03-01 03-01 03-01
2 : 03-01 03-01 03-01 03-01 03-01 03-01 03-01 03-01 03-01 03-01
3 : 03-01 03-01 04-01 04-01 04-01 04-01 04-01 04-01 04-01 04-01
4 : 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 04-01 04-01
5 : 04-01 04-01 04-01 04-01 04-01 04-01 04-01 04-01 04-01 04-01
6 : 04-01 04-01 04-01 04-01
SWITCH#sh mls qos input-queue
Queue : 1 2
----------------------------------------------
buffers : 90 10
bandwidth : 4 4
priority : 0 10
threshold1: 100 100
threshold2: 100 100
SWITCH#sh mls qos queue-set 1
Queueset: 1
Queue : 1 2 3 4
----------------------------------------------
buffers : 25 25 25 25
threshold1: 100 200 100 100
threshold2: 100 200 100 100
reserved : 50 50 50 50
maximum : 400 400 400 400
sh mls qos interface <ifname> statistics с указанием имени интересующего интерфейса.
Цифры для настройки очередей предварительно подбираются, но за основу можно брать тот же autoqos. Никакого другого пояснения я дать не могу. Будут дропы – надо будет менять параметры. Не будет – все хорошо. Ниже в примере приоритетная первая очередь, вторая очередь с основным объем данных. Сигнализация попадет в 3-ю очередь, видео - в 4-ю. Второй очереди выделено 60% буфера.
mls qos queue-set output 1 threshold 1 150 150 90 150
mls qos queue-set output 1 threshold 2 400 400 100 400
mls qos queue-set output 1 threshold 3 150 150 90 400
mls qos queue-set output 1 threshold 4 150 150 50 400
mls qos queue-set output 1 buffers 10 60 15 15
SWITCH#(config)#mls qos
SWITCH#(config)#no mls qos
SWITCH#(config)#mls qos rewrite ip dscp
SWITCH#(config-if)# priority-queue out
SWITCH#(config-if)# mls qos trust dscp
Маркировка трафика на примере IP-PBX
Если надо маркировать трафик, например, для сервера с ip-pbx, то сначала создаются acl, которые указываются в классах, из которых составляется политика
ip access-list extended rtp
permit udp any range 10000 20000 any
ip access-list extended signaling
permit tcp any any eq 5060
permit udp any any eq 5060
permit udp any eq 5060 any
permit tcp any eq 5060 any
permit udp any any eq 1720
permit tcp any any eq 1720
class-map match-all MARK-SIGN
match access-group name signaling
class-map match-all MARK-VOICE
match access-group name rtp
!
policy-map MARK-PBX
class MARK-VOICE
set dscp ef
class MARK-SIGN
set dscp cs3
class class-default
SWITCH#sh run int gi1/0/22
interface GigabitEthernet1/0/22
description IP-PBX
switchport access vlan 100
switchport mode access
priority-queue out
spanning-tree portfast edge
spanning-tree bpdufilter enable
service-policy input MARK-PBX
SWITCH#sh mls qos interface gi1/0/22
GigabitEthernet1/0/22
Attached policy-map for Ingress: MARK-PBX
trust state: not trusted
trust mode: not trusted
trust enabled flag: ena
COS override: dis
default COS: 0
DSCP Mutation Map: Default DSCP Mutation Map
Trust device: none
qos mode: port-based
SWITCH#sh mls qos interface gi1/0/22 statistics
GigabitEthernet1/0/22 (All statistics are in packets)
dscp: incoming
-------------------------------
0 - 4 : 7510037 0 0 0 0
5 - 9 : 0 0 0 0 0
10 - 14 : 0 0 0 0 0
15 - 19 : 0 0 0 0 0
20 - 24 : 0 0 0 0 4
25 - 29 : 0 0 0 0 0
30 - 34 : 0 0 0 0 0
35 - 39 : 0 0 0 0 0
40 - 44 : 0 0 0 0 0
45 - 49 : 0 2 0 114 0
50 - 54 : 373 0 104 0 1479
55 - 59 : 0 0 0 0 0
60 - 64 : 0 0 0 0
dscp: outgoing
-------------------------------
0 - 4 : 125576 0 0 0 0
5 - 9 : 0 0 0 0 0
10 - 14 : 0 0 932963 0 0
15 - 19 : 0 0 0 0 0
20 - 24 : 0 0 0 0 31532
25 - 29 : 0 32781 0 0 0
30 - 34 : 0 0 0 0 0
35 - 39 : 0 0 0 0 0
40 - 44 : 0 0 0 0 0
45 - 49 : 0 6364194 0 159 0
50 - 54 : 0 0 0 0 94
55 - 59 : 0 0 0 0 0
60 - 64 : 0 0 0 0
cos: incoming
-------------------------------
0 - 4 : 7512319 0 0 0 0
5 - 7 : 0 0 0
cos: outgoing
-------------------------------
0 - 4 : 125883 932963 0 64313 0
5 - 7 : 6364194 253 874
output queues enqueued:
queue: threshold1 threshold2 threshold3
-----------------------------------------------
queue 0: 6364193 0 0
queue 1: 1058845 121 23495
queue 2: 64272 0 0
queue 3: 253 0 0
output queues dropped:
queue: threshold1 threshold2 threshold3
-----------------------------------------------
queue 0: 0 0 0
queue 1: 0 0 0
queue 2: 0 0 0
queue 3: 0 0 0
Policer: Inprofile: 0 OutofProfile: 0
qos на 4900M
Полисеры для маркировки, полисеры для ограничения полосы в классе настраиваются немного иначе
vlan configuration 100
service-policy output MARK
vlan configuration 200,300
service-policy input LIMIT
sh policy-map vlan
eem high cpu
От cisco tac
process cpu threshold type total rising 60 interval 5
event manager applet HIGH_CPU
event syslog pattern "CPURISINGTHRESHOLD"
action 0.0 syslog msg "High CPU Detected"
action 0.1 cli command "enable"
action 0.2 cli command "show clock | append nvram:HIGHCPU.txt"
action 0.2 cli command "show process cpu sort | append nvram:HIGHCPU.txt"
action 0.2 cli command "debug platform packet all receive"
action 0.3 cli command "show platform cpu packet buffered | append nvram:HIGHCPU.txt"
action 0.4 cli command "show ip arp | append nvram:HIGHCPU.txt"
action 0.9 cli command "show platform cpu packet statistics | append nvram:HIGHCPU.txt"
action 0.9 cli command "undebug all"
action 1.1 cli command "end"