Wednesday, December 16, 2015

Broadcast storm или как победить "мелких поганцев" в сети. UPD. Часть 2 Часть 1


     Итак, продолжаем бороться со штормом. Сегодня поделюсь опытом использования специализированной loop-защиты на Cisco и HP ProCurve.
     Все усилия при использовании broadcast-limit на HP и storm-control на Cisco не прошли даром, ситуация в сети становится намного лучше чем без использования этих технологий, но до конца не нормализуется. На Cisco и HP есть специализированные средства борьбы с петлями, которые помогают противостоять в том числе петлям на "неуправляемом" оборудовании.

     HP ProCurve.

     На HP эта функция зовётся loop-protect, и работает по простой и надёжной технологии: в порт посылается broadcast пакет, и если он вернулся, то значит на порту петля. Современные коммутаторы отправляя broadcast пакет "во все порты" исключают из списка порт с которого получили пакет, по этому вернуться назад при "здоровой" топологии сети он не может. Такая простота протокола тем не менее позволяет безошибочно обнаруживать и блокировать петли даже, если к порту подключена целая гирлянда из неуправляемых коммутаторов.
Настраивается это чрезвычайно просто:
loop-protect A1-A24,B1-B24
A1-A24,B1-B24 - диапазон портов, на который применить настройки. Так же у этой функции есть дополнительные параметры, описывающие, что делать, если обнаружена петля:
... receiver-action send-disable - просто заблокировать порт и все,
... receiver-action send-recv-dis - заблокировать и попытаться восстановить через какое-то время.
Пример: "loop-protect A1-A24,B1-B24 receiver-action send-disable" - блокировать порты в случае обнаружения петли, и автоматически не восстанавливать. Может автоматически восстанавливать и не нужно, на самом деле, потому что петля сама скорее всего не исчезнет. Надо идти, искать ее и устранять, а потом уже поднять порт руками: int A17 enable
     Так же можно задать глобально параметры для loop-protect, определяющие таймеры и т.п:

loop-protect disable-timer - через сколько пытаться восстановить линк, после блокировки,
loop-protect mode port / vlan - режим работы, с портами или вланами,
loop-protect transmit-interval 1-10 - через сколько секунд повторять посылки пакетов для обнаружения петель, в порт,
trap, vlan и PORT-LIST - наверное понятно и без пояснений :)

     Собственно сегодня тестировал эту технологию - работает превосходно! HP почти сразу блокирует порт с D-Link'ом так, что сеть даже тряхнуть не успевает:



     Cisco.

     Spanning-tree loopguard - это нам вообще не поможет, так как эта технология основана на "потере связи по BPDU", т.е. она для межкоммутаторных линков, и от петель на неуправляемом оборудовании она никак не может помочь.

     UDLD:
Включается либо глобально для всех интерфейсов:
   conf t
      udld enable

Либо выборочно на интерфейсах:
   conf t
      interface GigabitEthernet0/1
         udld port enable

     По первому, второму и прочим впечатлениям - это работает, только интервал там 15 секунд, а не 5, как у HP, и никак не настраивается, потому сеть немного успевает тряхнуть перед блокировкой. Также у UDLD есть два режима работы: normal (просто enable) и aggressive, но в мелкой задаче блокировки петель aggressive mode нам не нужен, так что не будем в него углубляться :)

     Еще могу добавить, что на клиентских access портах Cisco неплохо бы включать BPDU Guard. BPDU Guard заблокирует порт, если вдруг поймает там BPDU, например в случае какой-либо незамысловатой петли. В общем это уже тонкости настройки STP, в какой-нибудь из следующих статей я это разберу. И BPDU Guard, и BPDU Filter и еще много чего можно разобрать :)

     Для тестов использовал HP ProCurve 5412zl и cisco 2960G. В качестве неуправляемого "мелкого поганца" использовал 8-портовый неуправляемый D-Link с петлей в его портах.

No comments :

Post a Comment