Хроники связи СВО

RSTP: зачем исправный порт перестаёт передавать трафик В прошлом посте этой серии разобрали, как петля размножает Ethernet-кадры и может положить несколько площадок. Теперь возникает нормальный вопрос: а как тогда делать резервные соединения? Возьмём три коммутатора. Соединим их треугольником: A–B, B–C и C–A. У каждого есть два пути к остальным. При обрыве одного кабеля физическая связность сохраняется. Но если все три соединения бесконтрольно пересылают кадры одного VLAN, мы получили петлю. RSTP позволяет сохранить кабели и построить поверх них топологию без замкнутого пути для пользовательского трафика. Как коммутаторы договариваются Они обмениваются служебными кадрами BPDU. С их помощью выбирают корневой коммутатор, root bridge, и определяют пути к нему. Корень выбирается по наименьшему Bridge ID. Приоритет входит в этот идентификатор; при равных приоритетах выбор зависит от MAC-адреса. Поэтому оставленные по умолчанию настройки могут дать вполне неожиданного победителя. Корень служит точкой отсчёта для построения дерева. Он не является обязательным шлюзом и не должен пропускать через себя каждый пользовательский кадр. Остальные коммутаторы выбирают лучшие пути к корню с учётом стоимости соединений. Избыточные пути получают соответствующие роли. В нашем треугольнике один из портов окажется в состоянии discarding: пользовательские кадры через него не пересылаются, но участие в работе протокола продолжается. Допустим, A стал корнем, соединения A–B и A–C передают трафик. На соединении B–C порт со стороны C оставлен резервным. Кадр может пройти от B через A к C. Вернуться из C в B по третьей стороне треугольника он уже не сможет. Круг разорван. При этом индикатор порта вполне может гореть. Физическое соединение исправно, просто протокол не разрешает использовать этот порт для обычной пересылки. Отключать RSTP ради того, чтобы «заработал последний кабель», здесь особенно плохая идея. Что произойдёт при обрыве Если соединение A–C пропадёт, C сможет использовать резервный путь через B. Быстрая перестройка RSTP опирается на заранее определённые роли портов и согласование переходов между соседями. На подходящих соединениях используется обмен proposal/agreement: устройства согласуют безопасный переход к передаче трафика. Но слово Rapid не обещает одинаковое время восстановления в любой сети. Результат зависит от способа обнаружения отказа, топологии, настроек и совместимости оборудования. Потеря физического линка и исчезновение служебных сообщений при горящем порте — разные ситуации. Почему одной галочки недостаточно Для работы протокола коммутаторы должны получать необходимые BPDU. Если пользовательский трафик проходит, а служебный обмен нарушен, рассчитывать на правильное построение дерева нельзя. Особенно внимательно это нужно проверять при соединении через чужую L2-сеть. Перенос клиентских VLAN сам по себе не обещает прозрачную передачу всех служебных кадров. Есть ещё edge-порты: соединения с конечными устройствами, которым разрешён быстрый переход к передаче данных. И отдельный механизм BPDU Guard, реагирующий на появление BPDU там, где их не ожидают. Это разные функции. Межкоммутаторный порт нельзя объявлять пользовательским только ради ускорения запуска. Наконец, RSTP устраняет петли в топологии, но не ограничивает интенсивность broadcast. Неисправное устройство может завалить сеть широковещательными кадрами и без единого замкнутого соединения. В этом случае дерево построено правильно, а сеть всё равно перегружена. Следующий пост будет про storm control: как ограничивают такой поток и почему случайно выбранный порог способен создать новую неисправность. Communicatio est victoria. — Душнила t.me/zas_svo vk.com/zas_svo #СВО #связь #RSTP #сети