Многие сталкивались с ситуацией, когда сеть неожиданно переставала работать, пропадал доступ на оборудование, абоненты начинали жаловаться. В голову приходили страшные мысли об обрывах магистрального кабеля, отключении электропитания на важных узлах и т.п. Однако причина такой глобальной неисправности была совсем в другом - абонент случайно перепутал кабели при подключении к роутеру и устроил кольцо на своем оборудовании.

Дорогие коммутаторы различных производителей поддерживают функцию 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 покажет резко увеличенную нагрузку на процессор одного из устройств, администратор сможет проверить загрузку портов и при необходимости отключить проблемный, на работу остальных абонентов это не повлияет.