Сегодня поговорим про защиту CPU от broadcast/multicast трафика на платформе Extreme X670. Данные рассуждения так же верны для X670V.
Коммутаторы построены на довольно старом Trident+ и в сравнении с одноклассниками – Huawei (S6700-48-EI) или Cisco (N3K-3064) практически не имеют защиты control plane.
Extreme предлагает воспользоваться встроенным в XOS механизмом – dos-protect. Однако, этот механизм не спасет в случае broadcast/multicast шторма.
Для защиты от BUM трафика принято пользоваться опцией storm-control или rate-limit flood в XOS. Тут нас тоже ждет неприятный сюрприз. На X670 G1 платформе используется XOS 16.x, в котором функционал rate-limit flood реализован с использованием токенов с инетервалом обновления 15.625 микросекунд. Не углубляясь в подробности, скажу сразу – опция rate-limit flood будет дропать легитимный трафик из за несовершенства механизма.
Более подробно можно прочитать на форуме extremenetworks.com
Описываемые методы были успешно применены в качестве последнего рубежа защиты на магистральных L2 коммутаторах. Однако, не стоит ограничиваться только этими методами, best practice – защита на доступе.
Теория:
Итак, пора разобраться, какой трафик попадает на CPU:
Queue 0 : Broadcast and IPv6 packets
Queue 1 : sFlow packets
Queue 2 : vMAC destined packets (VRRP MAC and ESRP MAC)
Queue 3 : L3 Miss packets (ARP request not resolved) or L2 Miss packets (Software MAC learning)
Queue 4 : Multicast traffic not hitting hardware ipmc table (224.0.0.0/4 normal IP multicast packets neither IGMP nor PIM)
Queue 5 : ARP reply packets or packets destined for switch itself
Queue 6 : IGMP or PIM packets
Queue 7 : Packets whose TOS field is "0xc0" and Ethertype is "0x0800", or STP, EAPS, EDP, OSPF packets При возникновении L2 петель, основной трафик который полетит в CPU – это Broadcast, IPV6 и Multicast.
Для снятия дампа с CPU и анализа текущей ситуации, можно воспользоваться командой :
debug packet capture on interface Broadcom count 1000
Дамп сохранится в /usr/local/tmp.
Можно воспользоваться tftp или scp для того, что бы скопировать дамп на рабочую машину.
tftp put 11.1.1.1 vr "VR-Default" /usr/local/tmp/2020-02-10_16-54-22_rx_tx.pcap 2020-02-10_16-54-22_rx_tx.pcap
После того, как мы проанализировали трафик на CPU, приступим к построению защиты.
Практика:
Для начала посмотрим, что будет с CPU при генерации broadcast и multicast трафика без какой либо защиты.
Схема лабы:
Для генерации трафика BcMc используется пакет pktgetn и скрипт nmap для флуда RA.
На сервере gen1 генерируется multicast трафик и IPV6 RA, сервер gen2 генерит broadcast.
Средний рейт генерации — 3Mpps.
Утилизация CPU:
sw2# sh cpu-monitoring | exclude 0.0
CPU Utilization Statistics - Monitored every 5 seconds
-----------------------------------------------------------------------
Process 5 10 30 1 5 30 1 Max Total
secs secs secs min mins mins hour User/System
util util util util util util util util CPU Usage
(%) (%) (%) (%) (%) (%) (%) (%) (secs)
-----------------------------------------------------------------------
System 52.2 50.3 50.4 47.3 48.9 26.0 13.0 69.7 0.32 964.28
mcmgr 39.9 40.4 41.6 43.0 38.6 10.5 5.2 47.1 46.47 356.98
sw2#top
Load average: 6.57 5.38 4.74 4/208 2905
PID PPID USER STAT RSS %MEM CPU %CPU COMMAND
1327 2 root RW 0 0.0 1 41.2 [bcmRX]
1543 1 root R 3852 0.3 0 40.4 ./mcmgr
sw2# debug hal show device port-info system unit 0 | include cpu
MC_PERQ_PKT(0).cpu0 : 1,131,571 +62,271 5,776/s
MC_PERQ_PKT(4).cpu0 : 187,781 +42,768 5,353/s
MC_PERQ_PKT(7).cpu0 : 503 +17
MCQ_DROP_PKT(0).cpu0 : 174,095,428 +29,103,098 3,298,296/s
MCQ_DROP_PKT(4).cpu0 : 78,082,718 +17,834,191 1,021,107/s
sw2# debug hal show congestion
Congestion information for Summit type X670-48x since last query
CPU congestion present: 12414120
Итого, при транзитном трафике broadcast/multicast с рейтом около 6Mpps мы имеем загрузку CPU 100% и 10Kpps в очередях на процессоре, все остальное дропается. Реальный трафик на процессор многократно выше.
Теперь перейдем к фильтрам и посмотрим, что у получится.
Для защиты Queue 0 : Broadcast and IPv6 packets, создадим policy limit-bc-ipv6.
Данный конфиг можно использовать, если на коммутаторе НЕ используется L3 IPv6 функционал.
configure meter limit-broadcast committed-rate 1000 Pps out-actions drop
sw#show policy limit-bc-ipv6
entry match-v6 {
if match all {
ethernet-type 0x86DD ;
}
then {
deny-cpu ;
}
}
entry match-bc {
if match all {
ethernet-destination-address ff:ff:ff:ff:ff:ff ;
}
then {
meter limit-broadcast ;
}
}
Данную политику можно применить на все порты, либо только на те, где возомжно возникновение шторма.
configure access-list limit-bc-ipv6 ports 1-48 ingress
Для полной симуляции, создадим петлю в портах 11 и 12.
sw2# sh ports 11-12,46-47 utilization
Link Utilization Averages Fri Apr 3 14:55:26 2020
Port Link Rx Peak Rx Tx Peak Tx
State pkts/sec pkts/sec pkts/sec pkts/sec
===========================================================================
11 A 7484877 8725834 7483368 8724075
12 A 7471259 8710066 7472785 8711816
46 A 2962834 3716425 7435635 8690736
47 A 2807846 3931673 7304028 8541282
В CPU попадает 3000 Broadcast пакетов, проходящих через петлю, все остальное — мультикаст.
sw2# debug hal show device port-info system unit 0 | include cpu
MC_PERQ_PKT(0).cpu0 : 2,456,584 +290,921 3,043/s
MC_PERQ_PKT(3).cpu0 : 3,104,008 +1,498,923 4,102/s
MC_PERQ_PKT(4).cpu0 : 3,125,047 +394,781 4,102/s
MC_PERQ_PKT(6).cpu0 : 1,222,571 +135,286 4,090/s
Утилизация CPU все еще 100%:
sw2# sh cpu-monitoring
CPU Utilization Statistics - Monitored every 5 seconds
-----------------------------------------------------------------------
Process 5 10 30 1 5 30 1 Max Total
secs secs secs min mins mins hour User/System
util util util util util util util util CPU Usage
(%) (%) (%) (%) (%) (%) (%) (%) (secs)
-----------------------------------------------------------------------
System 50.3 48.9 46.9 51.4 58.1 31.7 15.8 68.8 0.32 1180.54
mcmgr 43.9 43.1 44.8 31.0 6.3 6.3 3.1 48.5 33.33 198.40
Попробуем защитить CPU от мультикаста.
Для этого понадобится выключить igmp snooping на всех вланах, которые смотрят в порт, с которого приходит шторм.
Если на влане включен igmp snooping, трафик будет попадать в CPU.
sw2# configure igmp snooping filters per-vlan
sw2#disable igmp snooping vlan test
sw2#disable igmp snooping vlan test2
После наложения данных фильтров на CPU попадает 3000pps броадкаста:
sw2# debug hal show device port-info system unit 0 | include cpu
MC_PERQ_PKT(0).cpu0 : 4,908,231 +6,352 2,994/s
MC_PERQ_PKT(7).cpu0 : 11,214 +3 1/s
Утилизация CPU ~ 15%.
sw2# sh cpu-monitoring | exclude 0.0
CPU Utilization Statistics - Monitored every 5 seconds
-----------------------------------------------------------------------
Process 5 10 30 1 5 30 1 Max Total
secs secs secs min mins mins hour User/System
util util util util util util util util CPU Usage
(%) (%) (%) (%) (%) (%) (%) (%) (secs)
-----------------------------------------------------------------------
System 9.3 10.5 16.5 13.7 2.7 0.4 0.2 34.1 0.14 18.96
hal 3.5 3.7 3.2 10.2 2.0 0.3 0.1 51.5 1.42 10.67
sw2#top
Mem: 577816K used, 443708K free, 0K shrd, 127032K buff, 157064K cached
CPU: 0.8% usr 16.5% sys 0.0% nic 69.9% idle 0.0% io 2.6% irq 9.9% sirq
Load average: 5.12 2.77 1.10 3/208 2015
PID PPID USER STAT RSS %MEM CPU %CPU COMMAND
1329 2 root SW 0 0.0 1 17.7 [bcmRX]
Подводя итог, можно сказать, что данные коммутаторы будут хороши как L2 агрегаторы или P роутеры в MPLS сетях. Если использовать X670 как L3/L2 коммутатор, полноценной защиты CPU сделать не получится.
UPD(02/2021):
В ExtremeXOS 16.2.5-Patch1-22 (Apr 2020) заявлен фикс проблемы с storm-control:
xos0063205 Even though the traffic rate is below the configured flood rate limit, traffic is dropped.
Но, как обычно, пофиксили не до конца.
Настраиваем action = disable-port log для broadcast и multicast при прeвышении порога в 500pps и только log для unknown-destmac.
configure port 1 rate-limit flood broadcast 500 out-actions log disable-port
configure port 1 rate-limit flood multicast 500 out-actions log disable-port
configure port 1 rate-limit flood unknown-destmac 500 out-actions log
Запускаем генератор трафика с рандомными DST MAC и рейтом 1000pps.
Проблема в том, что action=disable-port срабатывает при достижении порога любым типом трафика. В нашем случае, при достижении unknown-destmac порога в 500pps порт выключаться не должен. Однако, порт выключается:
sw2#sh ports 1 rate-limit flood out-of-profile refresh
Port Monitor Fri Feb 12 11:48:33 2021
Port Flood Type Status Counter
#-------- ---------------- -------------- ----------
1 Unknown Dest MAC Out of profile 109336
1 Multicast Out of profile 109336
1 Broadcast Out of profile 109336
sw2# sh log
02/12/2021 11:52:14.71 Info:vlan.msgs.portLinkStateDown Port 1 link down
02/12/2021 11:52:14.70 Info:vlan.msgs.FldRateOutActDsblPort Port 1 disabled by Flood Control Rate Limit because the traffic exceeded the configured rate.
Протестировано на 16.2.5.4 16.2.5.4-patch1-29.
Надеюсь, это исправят в следующих релизах.