Сложилась ситуация, когда в ИТ-инфраструктуре произошла смена поколений серверов, но остались старые ядра сети, которые в свое время были флагманами. Петли генерируемые при неправильной настройки виртуальных свичей раньше не приносили больших проблем ядру - запас производительности позволял спокойно разбираться с нарушителями. Но сейчас, когда любой сервер обладает огромной мощностью и очень производительными сетевыми картами, картина изменилась - петли стали загружать CPU sup720 (cisco 6500) на 100% и страдать начинают все, при этом множественный мониторинг по SNMP, ICMP тоже повышает утилизацию, что усугубляет ситуацию.
Как меру по разгрузки ядра (уже) надо включать некое ограничение нагрузки на CPU самого ядра сети от внешних запросов.
на sup720 есть некоторые ограничения по применению механизма control-plane (COPP) - он не может работать с L2, т.е. ему нельзя в policy указывать L2 связанные параметры: mac, arp.
политику можно применить только если есть L3 описание трафика в class-map, а также минимальное ограничение в 32000 bit/s.
пример:
!
ip access-list extended icmp-to-core
permit icmp any host <core ip>
ip access-list extended snmp-core
permit udp any host <core ip> eq snmp
class-map match-all copp-icmp
match access-group name icmp-to-core
class-map match-all copp-snmp
match access-group name snmp-core
policy-map copp
class copp-icmp
police 32000 1500 1500 conform-action transmit exceed-action drop
class copp-snmp
police 64000 3200 conform-action transmit exceed-action drop
control-plane
service-policy input copp
(желательно, при добавлении в policy-map нового class-map, выключать service-policy из control-plane, добавлять class в policy-map и затем опять включать в control-plane, т.к. производится проверка совместимости policy и control-plane, в противном случаем можно добавить в policy-map не совместимы параметр, что может привести к крешу IOS)
L2 ограничения можно установить только через mls qos:
!
mls qos
mls cef error action reset
mls qos map policed-dscp normal-burst 0 24 26 34 36 to 8
mls qos map cos-dscp 0 10 18 24 34 46 48 56
mls qos protocol ARP police 640000 6400
И надо рассматривать включение storm-control на всех интерфейсах, т.к. риск отключить отдельный сегмент сети уже не так страшен, по сравнению с неработоспособность всей сети.
Как меру по разгрузки ядра (уже) надо включать некое ограничение нагрузки на CPU самого ядра сети от внешних запросов.
на sup720 есть некоторые ограничения по применению механизма control-plane (COPP) - он не может работать с L2, т.е. ему нельзя в policy указывать L2 связанные параметры: mac, arp.
политику можно применить только если есть L3 описание трафика в class-map, а также минимальное ограничение в 32000 bit/s.
пример:
!
ip access-list extended icmp-to-core
permit icmp any host <core ip>
ip access-list extended snmp-core
permit udp any host <core ip> eq snmp
class-map match-all copp-icmp
match access-group name icmp-to-core
class-map match-all copp-snmp
match access-group name snmp-core
policy-map copp
class copp-icmp
police 32000 1500 1500 conform-action transmit exceed-action drop
class copp-snmp
police 64000 3200 conform-action transmit exceed-action drop
control-plane
service-policy input copp
(желательно, при добавлении в policy-map нового class-map, выключать service-policy из control-plane, добавлять class в policy-map и затем опять включать в control-plane, т.к. производится проверка совместимости policy и control-plane, в противном случаем можно добавить в policy-map не совместимы параметр, что может привести к крешу IOS)
L2 ограничения можно установить только через mls qos:
!
mls qos
mls cef error action reset
mls qos map policed-dscp normal-burst 0 24 26 34 36 to 8
mls qos map cos-dscp 0 10 18 24 34 46 48 56
mls qos protocol ARP police 640000 6400
И надо рассматривать включение storm-control на всех интерфейсах, т.к. риск отключить отдельный сегмент сети уже не так страшен, по сравнению с неработоспособность всей сети.
Комментариев нет:
Отправить комментарий