Широковещательный шторм или как его еще называют сетевой шторм в сети, крайне неприятная проблема, вся сеть парализована, последовательная перезагрузка активного оборудования помогает если источник локализован и изолирован. О таких проблемах обычно вспоминают у костра на привале, когда дело доходит до страшных историй, так опытные инженеры-сетевеки пугают молодых сисадминов, что бы не расслаблялись. Конечно существуют протокол STP (обращаться с ним нужно осторожно, т.к., сам может быть источником широковещательного шторма), позволяющий отлавливать на каком порту петля и блокировать его, но у него есть существенный недостаток — низкая скорость реакции, RSTP в этом отношении намного быстрее работает, но и он не лишён недостатков.
В RSTP протоколе каждый наблюдаемый мост (порт, интерфейс, VLAN) это отдельный RSTP — процесс и соответственно,чем больше становится VLANов, тем больше ресурсов для наблюдения требуется. Эволюционное решение MSTP протокол, который может объединять наблюдаемые виртуальные интерфейсы в один STP процесс и это прекрасно. Но все это нужно только если в сети есть петли и от них не уйти — ну например, организация резервирования для облачного ЦОД и это тема для следующей статьи. Сейчас мы будем принимать меры от случайного (или не случайного) образования физической петли в сети, для этого на оборудовании Mikrotik реализован специальный протокол Loop Protect (начиная с версии 6.37.1) блокирующий проблемный интерфейс на заданное время, если не менять настройки — 5 минут. Сейчас, давайте разберемся как это работает и насколько это нужно в вашей сети.
Возникновение петли в сети и сетевой шторм как следствие
Давайте на минутку представим не очень сложную конфигурацию сети:
Если вы внимательно посмотрите на рисунок, очевидно, что при такой топологии коммутатор С создает петлю, (конечно, если не настроен STP протокол) ARP таблица на всех трех коммутаторах заполнится повторяющимися записями со скоростью света и сеть будет парализована. Но если погасить линк между коммутаторами B и C работа сети будет восстановлена. Аналогичная проблема будет если соединить между патчкордом два порта на любом из коммутаторов, даже если просто воткнуть патчкорд из порта 2 в третий порт на любом коммутаторе — это петля. Что бы избежать такого несчастья, т.к., от ошибок никто не застрахован нам нужно настроить Loop Protect на нашем Mikrotike. Таким образом, из соображений безопасности и здравого смысла LP (loop protect) необходимо включать на всех межкоммутаторных линках, конечно, если оборудование позволяет. И если все же случится сетевой шторм, ваше оборудование отсечёт аварийный сегмент.
Настройка loop protect на Микротике
Перед настройкой хочу напомнить, что протокол LP на Микротиках не включен по умолчанию и включать его нужно отдельно для каждого интерфейса.
Проверка работы Loop Protect на Микротике
Для создания аварийной ситуациия, я соединил интерфейсы ether3-local и ether5-local патчкордом, микротик при этом ожидаемо падает .
Теперь отключим патчкорд и заранее настроим все параметры LP, для чего, ether3 и ether5 переключим параметр loop-protect=on.
Важно!
Параметры настройки Loop Protect на Mikrotik
давайте рассмотрим дополнительные параметры:
- loop-protect-send-interval — в Winbox он отображается как Send Interval, данный параметр отвечает за интервал опроса интерфейса. По-умолчанию, здесь указано 5 сек, т. е. микротик будет проверять интерфейс каждые 5 секунд.
- loop-protect-disable-time — он же Disable Time в Winbox. Данный параметр отвечает за время, на которое отключается сетевой интерфейс. Default — 5 минут.
- loop-protect-status — в Winbox отображается как Status. Может принимать 3 значения: on (LP включен), off (LP выключен) и disable (LP включен, обнаружена петля).
Заключение:
Loop Protect на оборудовании Mikrotik конечно не панацея, есть свои нюансы, но как «защита от дурака» вполне.