В студенческом общежитии построена локальная сеть на основе роутера Mikrotik RB750 и множества неуправляемых коммутаторов. От локальных портов роутера (номера 2, 3, 4, 5) расходятся кабели по этажам на 16-ти и 24-х портовые неуправляемые коммутаторы, а от них на мелкие 5-ти портовые свичи в комнатах. Кое-где в комнатах стоят роутеры, настроенные в режиме «роутер» (своя подсеть).
Всё работало прекрасно, и вот сегодня в логах появилось назойливое сообщение: eth4-local: excessive broadcasts/multicasts, probably a loop. Сеть лежит, но удалённое управление роутером работает. Если програмно отключить подсеть подключенную к 4 разъёму, то у оставшейся части всё начинает работать нормально.
Пробовал стандартными утилитами микротика (/Tools) что-то обнаружить, не особо понимая что искать. Но всё же обнаружил, что при включениии проблемной сети Packet Snifer начинает детектировать адреса ipv6 в сети, при чём некоторые адреса какие-то неполные.
Что, придётся таки идти и дёргать провода последовательно? Вероятно «сдурел» один из свичей? А может кто-то из пользователей балуется?, но как это выявить, какими инструментами?
Прочитано:
12 073
Данная функция появилась в функционале Mikrotik совсем недавно (версия от 6.37.1), но это так чего я давно ждал, ее стоит пользоваться и как она работает я покажу на своем практическом примере.
В наличии Mikrotik RB951Ui-2HnD с прошивкой 6.40.5.
На заметку: петля это когда патчкорд из одного порта не ненароком соединена с другим портом.
Когда Mikrotik обнаруживает что между интерфейсами петля, то в логе формируется сообщение:
И порт выключается,
а в списке интерфейсов тревожное сообщение, что на порту зафиксирована петля
и также если обратиться к этому интерфейсу (тот который заблокирован/выключен) также есть сообщение на этот счет:
Когда петля устранена, то чтобы включить его нужно выключить его и заново включить.
К примеру: Решил пользователь по незнанию торчащий из розетки провод другим концом подключить в свободный порт дабы он не висел. Или если серверная напоминает «паука» проводов, нечаянно не туда был воткнул патчкорд не посмотрев куда приходит другой конец. Если бы не было такой защиты от петель, то через некоторое время сеть начинает захлебываться и все узлы, сервисы перестают работать покуда петля не устранена.
Итак чтобы включить защиту от образования петель в сети на базе Mikrotik нужно всего-то перейти в Interfaces (VLAN,ether) и зайти в каждый интерфейс, после перейти на вкладку Loop Protect и привести настройки к виду:
- Loop Protect: on — включаем блокировку интерфейса в случае образования петли
- Send Interval: 00:00:05 → каждый 5 секунд проводить проверку если ли на интерфейсе петля
- Disable Time: 01:05:00 → если интерфейс фиксирует образование петли, то выключить интерфейс на срок указанный, в моем случае на один час и пять минут.
- Status: on → когда блокировка интерфейса от первого параметра включена.
Также настройки могут принимать и другой вид, об этом можно почитать в документации или в моем руководстве. (Пишу для себя)
loop-protect (on | off | default; Default: default) - Включает и выключает механизм защиты интерфейса. По умолчанию выключен, лучше бы компания Mikrotik принудительно включила бы, а не самим включать, ну главное что теперь такая настройка присутствует.send-interval (time interval; Default: 5s) - время, как часто будет проверяться интерфейс на наличие петель.disable-time (time interval | 0; Default: 5m) - время, как долго будет выключен интерфейс при нахождении на нем петли. Если поставить 0 - навсегда.
На этом у меня всё, с уважением Олло Александр aka ekzorchik.
В одной из предыдущих публикаций про обновление RouterOS 6.37 я уже упоминал про добавление функции Loop Protect. Если быть точнее, Loop Protect добавлен в RouterOS начиная с версии 6.37rc25. Несмотря на это, в сам Winbox эта опция была добавлена только с выходом обновления RouterOS 6.37.1. Тогда же был представлен обновленный Winbox 3.6. С выпуском обновленного Winbox 3.7 мелкие недочеты по прежнему не исправлены.
Что такое Loop Protect и зачем он нужен в RouterOS?
Loop Protect, как следует из названия, функция для защиты от образования петель на уровне Layer 2. Система поддерживает контроль интерфейсов ethernet, vlan, eoip и eoipv6.
Настройка Loop Protect в Winbox
Функция Loop Protect настраивается индивидуально для каждого интерфейса. Откроем, к примеру, интерфейс ether5-slave-local, как видите, функция имеет значение «default», по сути это «off», т. е. по-умолчанию функция отключена на всех интерфейсах.
При использовании командной строки, используется параметр
loop-protect=on|off|default
Разработчики по прежнему не пофиксили дублирование параметров, поэтому на повторяющиеся «on», «off» и остальные параметры в Winbox не стоит обращать внимания, это мелкий баг.
Есть важный нюанс, про который забывает упомянуть как производитель, так и люди, описывающие работу Loop Protect. Дело в том, что для работы функции, необходимо активировать опцию на всех (!) портах, на которых вы считаете возможным образование петель. Если вы активируете loop-protect=on только на одном сетевом интерфейсе, при образовании петли, все порты, находящиеся в одной сети (бридже), станут недоступными. В этом случае необходимо ликвидировать петлю и перезагрузить устройство.
Для того, чтобы воссоздать петлю, я соединил интерфейсы ether3-slave-local и ether5-slave-local патчкордом, сеть при этом «падает», так что заранее необходимо задать все параметры.
В нашем случае для ether3-slave-local и ether5-slave-local задан параметр loop-protect=on.
Как видите, система обнаружила петлю и отключила сетевой интерфейс.
Для того, чтобы правильно настроить функцию, давайте рассмотрим дополнительные параметры:
- loop-protect-send-interval — в Winbox он отображается как Send Interval, данный параметр отвечает за интервал опроса интерфейса. По-умолчанию, здесь указано 5 сек, т. е. RouterOS будет проверять интерфейс каждые 5 секунд.
- loop-protect-disable-time — он же Disable Time в Winbox. Данный параметр отвечает за время, на которое отключается сетевой интерфейс. По-умолчанию — 5 минут.
- loop-protect-status — в Winbox отображается как Status. Может принимать 3 значения: on (LP включен), off (LP выключен) и disable (LP включен, обнаружена петля).
Казалось бы, реализовать цикличность и отключить интерфейс на 5 минут — хорошая идея. Если бы не одно большое но…
Дело в том, что при повторном включении сетевого интерфейса, повторно образуется петля, а все сетевые интерфейсы в локальной сети станут недоступными. Система обнаружит петлю и повторно отключит интерфейс на 5 минут.
В таблице интерфейсов над отключенным интерфейсом будет отображен комментарий красного цвета, с помощью которого можно определить с какого порта пришел loop-пакет и, соответственно, определить объединенные порты.
Если посмотреть логи, можно обнаружить, что при этом на несколько секунд «падают» все сетевые интерфейсы. Для соединений между маршрутизатором и коммутатором это не критично, а вот конечные клиенты должны повторно переподключиться к маршрутизатору и получить IP (для сетей с DHCP).
На стороне конечных клиентов это будет выглядеть так
Т. е. каждые 5 минут будет обрываться соединение. Чтобы этого избежать, на интерфейсах можно установить параметр loop-protect-disable-time=0, что приведет к полному отключению интерфейса, система не будет в дальнейшем пытаться активировать его самостоятельно и проверять на наличие петли.
Пока не ясно, будет ли Mikrotik дорабатывать этот функционал, к примеру, выводить (изолировать) порт в отдельный бридж или vlan, чтобы другие сетевые интерфейсы не падали при повторной активации порта.
Где может быть полезен Loop Protect? В первую очередь в больших сетях с большим количеством соединений. Никто не застрахован он подобных случаев, Loop Protection позволяет существенно сэкономить время и нервы, которые уйдут на поиск неисправности.
Многие сталкивались с ситуацией, когда сеть неожиданно переставала работать, пропадал доступ на оборудование, абоненты начинали жаловаться. В голову приходили страшные мысли об обрывах магистрального кабеля, отключении электропитания на важных узлах и т.п. Однако причина такой глобальной неисправности была совсем в другом — абонент случайно перепутал кабели при подключении к роутеру и устроил кольцо на своем оборудовании.
Дорогие коммутаторы различных производителей поддерживают функцию Loopback Detection, что позволяет при аналогичных проблемах, когда абонент соединил патчкордом порты своего оборудования между собой, устроив петлю, сразу же отключать клиентский порт на коммутаторе провайдера. Такая схема хорошо работает в кабельных сетях, когда имеется оптический канал до многоэтажного дома, в нем установлены многопортовые коммутаторы и аналогичное оборудование. Но что делать, если подключаются несколько абонентов в малоэтажных домах — не устанавливать же туда дорогие коммутаторы, которые никогда не окупятся.
Поэтому в таких случаях выгодно использовать маршрутизаторы Mikrotik, на котором IP-адрес абонента привязан к своему порту и полностью изолирован от других абонентов и промежуточного оборудования. Называется такая схема — L3 Access, но о ней мы поговорим позже, а сейчас только проверим как она помогает защититься от проблемы петель на абонентском порту.
Возьмем роутер Mikrotik RB751G-2HnD для проведения тестов, сбросим начальную конфигурацию и не будем вносить изменения в настройки.
Для создания кольца будем подключать его к 24 портовому коммутатору через 5 сетевой порт RB751G-2HnD. На самом коммутаторе патчкордом соединяем 2 любых порта между собой.
Видно, что никаких бриджей в настройках не указано, т.к. они в схеме L3 access не нужны.
Подключаем к 5 сетевому порту коммутатор, на котором устроена петля, при этом сам коммутатор не должен отключать порты, если он поддерживает функцию loop detect, то она должна быть отключена.
Запускаем Torch, выбираем нужный сетевой порт и отмечаем все галочки, нажимаем Start — видим, что из указанного порта идет трафик около 1 мегабита, в основном это ARP. То есть все то, что отправляет Mikrotik в сеть, коммутатор возвращает обратно, если бы 5 порт был объединен с другими портами, то эти данные разлетелись по всей сети, создав проблемы. Но в нашем случае они никуда, дальше своего порта не пройдут.
Отключаем патчкорд из коммутатора, с помощью которого создали петлю.
Настраиваем DHCP Server на Mikrotik, подключаем ноутбук к коммутатору, он получает адрес 10.0.0.254 и запускаем пинг на него. Видно, что он проходит с нулевой задержкой.
Теперь снова подключаем патчкорд, и видим, что пинг пропал, входящий трафик на порту возрос до 4 мегабит в секунду.
Что бы уменьшить количество трафика при возникновении петель, требуется отключить ARP на самом микротике, для этого в настройках сетевого порта в пункте ARP требуется указать reply-only, а что бы дать возможность работы абонентам — в настройках DHCP сервера поставить галочку Add ARP For Leases, что позволит автоматически добавлять статическую запись в ARP при выдачи IP-адреса абоненту.
Вновь создаем петлю на коммутаторе и видим, что объем трафика уменьшился до 3 мегабит в секунду, загрузка процессора при этом всего 1%. Следовательно Mikrotik работает и без аппаратного Loopback Detection, при этом ограничивая трафик абонента в пределах своего порта, мусорные данные по сети не разлетаются.
Теперь представим ситуацию, когда абонент намеренно хочет создать проблемы оператору, специально подключив в свой коммутатор несколько других коммутаторов или роутеров, которые будут генерировать большое количество трафика. Видно, что объем входящих данных увеличился и составляет 33 мегабита в секунду, нагрузка на процессор микротика так же возросла, и составляет 58%, при этом частота процессора всего 400 мегагерц, это самая младшая модель в линейке производителя. Однако увеличилась она не из-за самого объема трафика, а от количество пакетов, которые приходят на устройство, в данном примере их 64 тысячи.
Следовательно, даже если кто-то специально хочет создать проблемы, то не сможет заблокировать работу роутера большими объемами трафика. Если вместо ARP запросов в порт пойдут реальные данные, передаваемые внутри сети абонента, то размер пакета будет не 64 байта, а больше, что опять же не позволит создать высокую нагрузку на процессор, а наоборот, снизит ее.
В реальных сетях с заворотом трафика сталкиваются редко, поэтому если использовать Mikrotik для подключения абонентов в кабельной или беспроводной сети, создав при этом полностью L3 сеть, эта проблема совершенно не будет влиять на работу. Если система мониторинга The DUDE покажет резко увеличенную нагрузку на процессор одного из устройств, администратор сможет проверить загрузку портов и при необходимости отключить проблемный, на работу остальных абонентов это не повлияет.
Данный информационный материал был создан, подготовлен и размещен специалистами ООО «ЛАНМАРТ» и является собственностью администрации проекта www.lanmart.ru. Любое использование и размещение данного материала на других ресурсах допускается только при наличии прямой ссылки на первоисточник.
Широковещательный шторм или как его еще называют сетевой шторм в сети, крайне неприятная проблема, вся сеть парализована, последовательная перезагрузка активного оборудования помогает если источник локализован и изолирован. О таких проблемах обычно вспоминают у костра на привале, когда дело доходит до страшных историй, так опытные инженеры-сетевеки пугают молодых сисадминов, что бы не расслаблялись. Конечно существуют протокол STP (обращаться с ним нужно осторожно, т.к., сам может быть источником широковещательного шторма), позволяющий отлавливать на каком порту петля и блокировать его, но у него есть существенный недостаток — низкая скорость реакции, RSTP в этом отношении намного быстрее работает, но и он не лишён недостатков.
В RSTP протоколе каждый наблюдаемый мост (порт, интерфейс, VLAN) это отдельный RSTP — процесс и соответственно,чем больше становится VLANов, тем больше ресурсов для наблюдения требуется. Эволюционное решение MSTP протокол, который может объединять наблюдаемые виртуальные интерфейсы в один STP процесс и это прекрасно. Но все это нужно только если в сети есть петли и от них не уйти — ну например, организация резервирования для облачного ЦОД и это тема для следующей статьи. Сейчас мы будем принимать меры от случайного (или не случайного) образования физической петли в сети, для этого на оборудовании Mikrotik реализован специальный протокол Loop Protect (начиная с версии 6.37.1) блокирующий проблемный интерфейс на заданное время, если не менять настройки — 5 минут. Сейчас, давайте разберемся как это работает и насколько это нужно в вашей сети.
- Возникновение петли в сети и сетевой шторм как следствие
- Настройка loop protect на Микротике
- Проверка работы Loop Protect на Микротике
- Параметры настройки Loop Protect на Mikrotik
Возникновение петли в сети и сетевой шторм как следствие
Давайте на минутку представим не очень сложную конфигурацию сети:
Если вы внимательно посмотрите на рисунок, очевидно, что при такой топологии коммутатор С создает петлю, (конечно, если не настроен STP протокол) ARP таблица на всех трех коммутаторах заполнится повторяющимися записями со скоростью света и сеть будет парализована. Но если погасить линк между коммутаторами B и C работа сети будет восстановлена. Аналогичная проблема будет если соединить между патчкордом два порта на любом из коммутаторов, даже если просто воткнуть патчкорд из порта 2 в третий порт на любом коммутаторе — это петля. Что бы избежать такого несчастья, т.к., от ошибок никто не застрахован нам нужно настроить Loop Protect на нашем Mikrotike. Таким образом, из соображений безопасности и здравого смысла LP (loop protect) необходимо включать на всех межкоммутаторных линках, конечно, если оборудование позволяет. И если все же случится сетевой шторм, ваше оборудование отсечёт аварийный сегмент.
Перед настройкой хочу напомнить, что протокол LP на Микротиках не включен по умолчанию и включать его нужно отдельно для каждого интерфейса.
Важно! для работы функции LP, необходимо активировать опцию на всех портах, на которых вы считаете возможным образование петель. Если вы активируете loop-protect=on только на одном сетевом интерфейсе, при образовании петли, все порты, находящиеся в одной сети (бридже), станут недоступными.
Проверка работы Loop Protect на Микротике
Для создания аварийной ситуациия, я соединил интерфейсы ether3-local и ether5-local патчкордом, микротик при этом ожидаемо падает .
Теперь отключим патчкорд и заранее настроим все параметры LP, для чего, ether3 и ether5 переключим параметр loop-protect=on.
И повторим наш бесчеловечный эксперимент, т.е., соединим третий и пятый порт патчкордом.
Как видите в Winbox, микротик обнаружил петлю на 3м интерфейсе и погасил его на 5 минут.
Важно!
Важно:
Параметр Loop-protect-disable-time задает период отключения интерфейса, после чего система попытается включить аварийный интерфейс, хорошо если проблема устранена и тогда всё заработает в штатном режиме. но если петля не устранена, после включения аварийного линка, проблема возобновиться и кратковременно лягут остальные интерфейсы, затем они включатся все, кроме аварийного. И будет колбасить всю сетку с интервалом в 5 минут, до устранения.
Параметры настройки 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 конечно не панацея, есть свои нюансы, но как «защита от дурака» вполне.