...
Основные причины утилизации очереди:
- 1. Для connected-сетей. На коммутатор поступает трафик с адресами назначения, для которых нет полной записи в ARP-таблице. Коммутатор не может корректно перенаправить этот трафик, пытается добавить arp-запись в arp-таблицу для маршрутизации трафика, но хосты не отвечают. Вследствие чего весь транзитный трафик на эти хосты перехватывается на CPU, утилизация CPU в такие моменты обычно возрастает. Зачастую такое встречается у клиентов, когда на сети работают различные системы мониторинга, которые периодически с большим pps подключаются к хостам и снимают различную информацию независимо от того, включено оборудование конечного хоста или нет. Также возможны всплески в данной очереди по причине флаша мак таблицы, как правило из-за перестроения xSTP, например на какой-либо порт пришла TCN BPDU--------> флашнулась мак-------> запись в ARP таблице стала невалидна--->коммутатор перехватывает трафик до момента заполнения ARP таблицы.
| Блок кода |
|---|
spine-1(config)#do sh spanning-tree *********************************** Process 0 *********************************** Spanning tree enabled mode RSTP Default port cost method: long Loopback guard: Disabled Loop guard default: Disabled TC protection: Disabled Root ID Priority 32768 Address e4:5a:d4:d7:8c:40 This switch is the root Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Number of TC BPDU handled 0 **Number of topology changes 1 last change occurred 00:00:36 ago from te1/0/2** Times: hold 1, **topology change 35**, notification 2 hello 2, max age 20, forward delay 15 |
| Блок кода |
|---|
spine-1#sh mac address-table count
Capacity : 32768
Free : 32755
Used unicast : 13
Used multicast : 0
Used IPv4 hosts : 0
Used IPv6 hosts : 0 (each IPv6 host consumes 2 entries in MAC address table)
Secure : 0
Dynamic unicast : 8
Static unicast : 0
Internal : 5
Service dynamic : 0 |
2. Для не connected-сетей. Это обычный route unknown трафик, который попадает на коммутатор, т.е трафик, для которого нет маршрута в таблице маршрутизации.
- 3. Формирование icmp redirect сообщений. Может возникнуть при неоптимально настроенной маршрутизации трафика независимо от того, какая используется маршрутизация, статическая или динамическая. Обычно встречается в комбинированных сетях с множественным доступом. В большинстве случае понять, что загрузку очереди route unknown вызывают icmp redirect сообщения, можно по загруженным процессам IPG и 3SWF. Пример:
...
Для большинства сетей хорошей практикой является отключение icmp redirect на всех l3 интерфейсах. Практического применения у данного функционала в текущих реалиях нет, рекомендуется отключать его на всех l3 интерфейсах коммутатора. Отключается в контексте ip интерфейса:
| Блок кода |
|---|
console#shspine-1#sh ip interface IP Address I/F I/F Status Type Directed Prec Redirect Status admin/oper Broadcast ------------------ ------------- ---------- ------- --------- ---- -------- ------ 172.16.0.1/24 vlan 10 UP/UP Static disable No enable Valid console#conf console(config)#interface ip 172.16.0.1 console(config-ip)#no ip redirects |
...