Всем привет!

С этого момента я начну, спонтанную и нерегулярную серию статей по сетевым технологиям, читай, дневник.

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

Я же хочу поговорить про более, если угодно, скучные и рутинные задачи сетевого инженера в маленьком провайдере последней мили, предоставляющим услуги связи нескольких видов на территории некоторого количества объектов. То есть, клиент - бизнес. А бизнес крайне чувствителен к любым задержкам в предоставлении сервиса.

И среди этой рутины, выделить, как минимум, для себя, какие-то интересные, не очень очевидные моменты, а так же поделиться опытом работы с оборудованием конкретных вендоров и моделей, перенять опыт хабровчан, если повезет.

Немного обо мне

Буквально через пару месяцев мне исполнится 25 лет. За свою недолгую сознательную жизнь я так или иначе интересовался техническими темами, а именно разработкой (всей, но больше web), но, как оказалось, моя душа отторгает данный вид деятельности в качестве основной работы. После этого я успел побывать и инженером 3-й линии техподдержки у разработчика ВАТС, и барменом, пока не пришел на должность младшего сетевого инженера на производство.

Должность называлась не так, но в моей зоне ответственности была вся связь в том или ином виде на всем производстве. Аналоговая телефония (обслуживание 3-х АТС и линий телефонной связи), сети (настройка и обслуживание коммутаторов и линий, планирование коммуникаций), а потом и IP телефония, в частности, процесс бесшовного (ну почти) перехода с аналога на цифру для ~ 2 тысяч абонентов.

Несколько месяцев назад я перестал заниматься сетями по совместительству и перешел на новое место работы, где упор будет конкретно на сети и присутствуют перспективы развития выше L2+ сетей.

Тема сегодняшнего разговора

После того, как мы обсудили, безусловно, очень интересные детали моей карьеры, предлагаю перейти непосредственно к делу.

Одной из последних моих задач было реализовать на сети защиту от человеческой ошибки — локальной петли.

Меня, честно говоря, удивила такая задача. Как такая проблема, казалось бы простая и одновременно потенциально опасная для сети, не была решена до моего прихода? Тем более, что структура сети такова, что в одном L2-домене находится значительное количество абонентов.

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

О превентивных же мерах защиты вспомнили после очередной такой ошибки. Проанализировав структуру сети (кольцо на магистральной части и звезда на уровне доступа) я увидел, что в звезде не более 1 хопа от агрегации до коммутатора доступа, по 1 коммутатору на точку присутствия. Правда, этих точек присутствия достаточно много.

Что первое приходит на ум, когда мы говорим о защите от петель коммутации? Конечно, протоколы семейства STP. И сначала я думал настроить STP глобально на каждом объекте. Но, после некоторых размышлений и обсуждений, было решено этого пока не делать и настроить локальную защиту каждого коммутатора доступа от локальной петли. Требовалось протестировать каждую используемую в сети модель на наличие функций по самозащите от петли. Как правило, такая функция называется loop-detection, loop-protection и имеет почти полностью идентичный алгоритм работы и синтаксис настройки.

Парк коммутаторов нашей сети состоит из устройств 3-х вендоров в, примерно, равных пропорциях

• Allied Telesis

• QTech

• HP&Co (H3C, 3COM)

Поэтому способность защищаться от петель тестировалась именно на них. Спойлер - у каждого вендора всё по-разному.

Но сначала, давайте вспомним немного теории

Что такое петля коммутации

Коммутационная петля, так же известная как широковещательный шторм, broadcast storm или просто шторм, возникает, когда до какого-либо коммутатора есть более чем один путь и при этом не настроен никакой протокол защиты от петель/контроля топологии.

Здесь не будем сильно вдаваться в подробности, для интересующихся есть замечательный цикл статей СДСМ с очень наглядными картинками.

Вкратце, происходит это из-за одного правила коммутации широковещательных пакетов, которое звучит как

При получении широковещательного кадра, коммутатор обязан разослать этот кадр на все порты данной (V)LAN кроме того порта, с которого этот кадр пришел.

Поэтому, если два коммутатора соединены более чем одним линком, при коммутации широковещательного кадра они начинают пересылать его друг другу до бесконечности, так как понятия TTL на L2 еще не существует.

В сумме с тем фактом, что широквещательные кадры от клиентов также продолжают поступать, каналы связи между проблемными коммутаторами перегружаются, процессоры коммутаторов перегружаются, память переполняется и в итоге коммутатор теряет способность нормально функционировать, пока петля не будет устранена.

Петли условно можно разделить на обычные и локальные.

Когда мы говорим про обычные, то имеем ввиду топологическую петлю, которая возникает, как минимум, между двумя устройствами.

Локальная петля - разновидность человеческой ошибки, когда один кабель втыкается в два порта одного коммутатора.

Как понять, что в сети петля

Есть несколько признаков, которые свидетельствуют о том, что в сети начался шторм:

• Резко возрастают числовые показатели нагрузки на коммутатор

• В некоторых случаях меняется характер индикации светодиода порта (начинает очень быстро мигать без явной причины или наоборот перестает мигать совсем)

• Если петля небольшая (с небольшим количеством абонентов), может характеризоваться спонтанными проблемами с сетью у пользователей, а коммутатор тем временем будет фиксировать частые перемещения mac-адресов между разными портами

• Если шторм средний или крупный (извините за такую терминологию), удаленный доступ к коммутатору и близлежащим к нему может быть сильно затруднен или невозможен совсем, что способны заметить системы мониторинга

• Абоненты из, примерно, одной локации массово жалуются на невозможность доступа к сети

• Со стороны абонентского порта или со стороны соседнего коммутатора преобладающее количество broadcast/unknown unicast/multicast траффика

Как защитить свою сеть от петли коммутации

Меры по защите от коммутационной петли можно условно разделить на 3 категории в порядке приоритета:

1. Превентивные административные и технические меры

2. Протоколы контроля топологии сети

3. Меры, уменьшающие разрушительное воздействие петли на сеть, если не удалось избежать ее появления

Превентивные меры

Проще всего предотвратить беду, когда она еще не случилась.

Административная защита заключается в построении loop-free топологии на участках, где это возможно, маркировка кабелей, ведение внутреннего учета коммуникаций.

А у нас....

Например, в нашей компании сотруд��иками-энтузиастами была разработана система базового учета коммуникаций, оборудования, VLAN-ов, клиентов и прочей такой штуки с функциями автоматического получения ряда параметров с сетевого оборудования по SNMP. Мне очень понравилась реализация, а самопальные системы мне нравятся редко.

Также, я работаю над регламентом, или стандартом, если угодно, именования всех сущностей, с которыми мы работаем.

Например, description интерфейсов должен формироваться по определенному алгоритму и отражать его предназначение и координаты его второго конца

Техническая защита заключается в наличии и правильной настройке системы мониторинга, использовании возможностей коммутатора для детектирования аномалий (технологии типа arp-inspection, mac-flapping-detection)

Протоколы контроля топологии сети

Эта тема довольно обширная и ее основы рассматриваются все в том же СДСМ.

Самым популярным протоколом защиты некольцевой топологии все еще остаются протоколы семейства STP, чаще всего RSTP (Rapid Spanning Tree).

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

Отдельным пунктом можно вынести функцию loopback-detection, которая может немного по разному называться у разных вендоров, но суть всегда одна, которая предназначены исключительно для того, что устранять локальные петли.

Меры подавления шторма

Также делятся на 2 условные группы: пассивные и активные.

Коммутационная существует на L2 уровне сети. Пассивные меры подавления основаны как раз на этом ее свойстве. С помощью VLAN уменьшается размер шировещательного домена (а равно и поля действия для петли), чтобы даже если шторм случился, он затронул как можно меньшее количество участников сети.

Чем "мельче" "нарезана" сеть на VLAN тем меньшее влияние на сеть окажет петля. В том числе по этой причине многие крупные провайдеры придерживаются принципа VLAN-per-user.

Активные способы подавления петли заключаются в использовании соответствующих функций коммутатора и физического разрыва петли.

Функция, как правило, называется storm-control или storm-constrain у разных вендоров, но в целом выполняет одну и ту же функцию - реакция на превышение широковещательного трафика с абонентских портов свыше определенных инженером порогов, например, ограничение полосы пропускания или полное отключение порта.

Настройка защиты от локальных петель на коммутаторах доступа сети

Наконец, мы добрались до процесса тестирования и настройки наших коммутаторов. Напомню, что тестирую я функции loopback-protection, если они заявлены вендором.

QTech QSW-3750

Единственные коммутаторы из всего парка, на которых без нареканий работает функция защиты от локальной петли loopback-detection. Единственное НО — документация не поясняет смысл нескольких команд.

Как работает loopback-detection

Порты, на которых включен Loopback-detection раз в INTERVAL секунд посылают специальный ethernet кадр. Если этот кадр возвращается в тот же или другой порт коммутатора, считается, что обнаружена петля и ее надо разорвать путем отключения портов, на которых она была обнаружена.

Процесс настройки:

enable
conf
#Настройка интервала отправки того самого LDB пакета
loopback-detection interval-time 5 15
#через сколько порт попытается подняться
loopback-detection control-recovery timeout 30
#Включаем посылку snmp-trap в систему мониторинга
loopback-detection trap enable

Далее необходимо настроить данную функцию на всех абонентских портах коммутатора. Напомню, что я защищаю только одиночные коммутаторы без построения топологии.

interface ethernet 1/0/1
loopback-detection specified-vlan 1-4094
#Настройка действия при обнаружении петли - выключить порт
loopback-detection control shutdown

Пояснения

Хотелось бы пояснить несколько моментов.

loopback-detection interval-time 5 15

Первая цифра указывает частоту посылки LDB пакета в состоянии, когда петля обнаружена. Рекомендую выставлять поменьше, чтобы после разрыва петли порт как можно быстрее восстановился.

Вторая цифра указывает частоту посылки LDB пакета в состоянии когда петля не обнаружена. Я указал побольше, чтобы не генерировать лишний трафик.

Соответственно, время фактической отработки защиты будет в пределах промежутка, указанного второй цифрой, а время восстановления - первой.

loopback-detection control-recovery timeout 30

Через сколько секунд после срабатывания защиты коммутатор поднимет порт автоматически.

Я указал время, равное двум интервалам обнаружения.

Если указать 0, включить порт обратно можно будет только вручную.

Если после поднятия портов петля еще не устранена, вновь сработает защита и он отключится обратно.

loopback-detection specified-vlan 1-4094

Честно говоря, мне не удалось найти информацию, на что влияют значения в этой команде, но в документации написано, что только эта строка фактически активирует защиту.

Работает с любыми значениями, но на всякий случай указал весь vlan диапазон.

loopback-detection control shutdown

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

Настройки SNMP касательно мониторинга срабатывания защиты

При срабатывании loopback-detection на настроенный SNMP сервер будет послан snmp-trap с OID .1.3.6.1.4.1.27514.101.112.1.

В этой переменной будет содержится сообщение

Port Ethernet1/0/1 vlan 1 is a loopback device  или Port Ethernet1/0/1 became a free loop device в зависимости от события.

MIB для расшифровки этих OID: ieee8021-tc-mib-202211080000z.mib (извините, у меня не осталось ссылки, можно погуглить)

Allied Telesis AT8000S

На коммутаторах этого вендора специальная функция loopback-detection отсутствует в принципе, поэтому единственный способ защититься от локальной петли это использовать STP, ограничив область его действия одним отдельно взятым коммутатором.

Теория

Через каждый абонентский порт коммутатор посылает BPDU-пакеты.

Также, на каждом порту или глобально настроена функция BPDU-guard или BPDU-protection в зависимости от вендора. Эта функция позволяет настраивать поведение коммутатора при получении любого BPDU пакета.

Идея заключается в том, что если 2 порта будут замкнуты между собой, коммутатор получит свой же BPDU пакет и заблокирует один из портов, не дав петле состояться и послав сообщение в мониторинг.

НО

Отсюда же вытекает и минус: если оборудование клиента шлет свои BPDU (таким часто занимаются коммутаторы по умолчанию), то оно спровоцирует срабатывание защиты и порт будет заблокирован даже без петли. Предполагается, что такие абоненты — исключение и в купе с постепенным включением защиты удастся безболезненно их вычислить.

ЕЩЕ ОДНО НО

Даже через Edged-порты коммутатор все равно шлет свои BPDU. Это может оказать непредсказуемое влияние на оборудование клиента, если оно их обрабатывает. Опять же, предполагается, что это исключение.

Практика

conf
#включает stp глобально
spanning-tree
#Использовать RSTP. В данном случае не так важно
spanning-tree mode rstp
#отбрасывать bpdu на портах, где выключен STP
spanning-tree bpdu filtering

Далее необходимо настроить все абонентские порты

interface ethernet e1
#блокирует порт при получении bpdu
spanning-tree bpduguard
#Если не включать portfast, порты будут в вечном цикле Learning - Forwarding и защита не сработает
spanning-tree portfast

И отключить STP на UPLINK и DOWNLINK портах.

После срабатывания защиты BPDU Guard заблокированные порты можно посмотреть командой show interface status.

В списке интерфейсов, статус заблокированных портов будет отображаться со звездочкой Disabled*.

Такие порты нужно возвращать в активное состояние только вручную после устранения причины петли с помощью командыset interface active ethernet e2

Настройки SNMP касаемо мониторинга срабатывания защиты

При срабатывании защиты BPDU Guard коммутатор присылает SNMP-trap с OID .1.3.6.1.4.1.89.0.202

В переменной с OID .1.3.6.1.4.1.89.2.3.1.0 будет содержаться номер заблокированного порта.

Пример сообщения: %STP-W-BPDUGRDPRTSUS: e3 suspend by BPDU guard.

HP/H3C 3100

Коммутаторы этого вендора работают под управлением ОС Comware.

В документации заявлена функция loopback-detection, аналогичная QTech. В консольном интерфейсе (и только там) она действительно присутствует, но заставить ее работать не удалось никаким способом, поэтому будем считать, что ее там нет, и будем использовать тот же вариант с STP.

Все плюсы и минусы этого способа аналогичны предыдущей модели.

Настройка:

system-view
stp enable
stp mode rstp
stp bpdu-protection

И настройка всех абонентских портов

interface Ethernet 1/0/1
stp edged-port enable

Тут даже нечего комментировать, всё аналогично предыдущей модели.

Настройки SNMP касаемо мониторинга срабатывания защиты

При срабатывании BPDU Protection коммутатор присылает SNMP Trap с OID .1.3.6.1.4.1.25506.8.35.14.0.5 (переменная hh3cPortMstiBpduGuarded в MIB)

Отдельный OID для восстановления не предусмотрен, присылается TRAP, когда порт переходит в состояние Forwarding с OID .1.3.6.1.4.1.25506.8.35.14.0.1

И в переменной hh3cdot1sMstiPortIndex (MIB) лежит номер интерфейса. MIB к этому коммутатору (касаемо BPDU Protection):  hh3c-splat-mstp.mib (на сайте H3C в разделе MIB Companion)

Вместо вывода

По результатам анализа все три коммутатора показали 3 разные результаты в плане наличия и объема функций по защите самого себя от петли. Где-то можно гибко настроить действия по защите, интервалы, автовосстановление, где-то нет.

Естественно, даже, казалось бы, идеальный вариант с loop-detection не так идеален как кажется на первый взгляд. Он имеет всю ту же проблему, что и вариант с STP — если со стороны абонента стоит оборудование, на котором настроен loop-detection, то при определенном стечении обстоятельств оно может обработать LBD пакет и заблокировать порт даже без петли.

Однако, на данный момент я не вижу иных альтернатив, кроме как не ошибаться или устранять петли по ходу появления. И если при обкатке защиты возникнуть проблемы, то, возможно, от активных мер придется отказаться.

Постскриптум

Для поддержания порядка в шкафах вставьте все свободно болтающиеся концы кабелей в свободные порты коммутатора — это удобно и практично, а ваши коллеги скажут вам огромное спасибо!