Pull to refresh

Закольцованные сети, или зачем нам STP

Reading time 6 min
Views 58K

Суть проблемы


Целью жизни коммутатора сетевого (он же свитч) является неустанная пересылка пакетов от отправителя получателю. Для оптимизации работы, свитч содержит т.н. CAM-таблицу, содержащую в себе адреса устройств, пакеты от которых он когда-то получал, и номера физических портов, из которых эти самые пакеты были получены.

Иными словами, если свитч недавно получил пакет от компьютера А в порт 1, то в таблицу заносится соответствие «комп. А» -> «порт 1», и дальнейшие пакеты, адресованные компьютеру А, автоматически пересылаются только в порт 1, и никуда больше, что экономит пропускную способность сети и делает неэффективными пассивные перехватчики траффика.

Но что делать свитчу, если приходит широковещательный пакет (broadcast)?
Логично предположить, что такие пакеты пересылаются во все порты, кроме того, откуда изначально были получены.
Что, при определённой конфигурации сети, может привести к весьма печальным последствиям…

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

image

Что произойдёт, если свитчу 1 из облака придёт широковещательный пакет? Он размножит его и передаст в порты 1, 2 и 3 (из порта 4 пакет пришёл, так что обратно в него отправлен не будет). Свитч 2, получив пакет на 2 порту, отправит его копии в порты 1 и 3. Свитч 3, получив пакет на порту 1, отправит его копии в порты 2 и 3. Свитч 4, получив пакет на 3 порту, отправит его копии в порты 1 и 2. После чего каждая копия, передаваясь от устройства к устройству, будет размножена по этой же схеме всё больше и больше, пока суммарно они не займут всю доступную полосу пропускания (или не забьют мозги устройствам до потери их работоспособности).

Но, в то же время, обойтись совсем без «петель» в сети — никак невозможно, поскольку важнейшим свойством хорошей сети является отказоустойчивость. То есть, между любыми двумя важными узлами сети (компьютер рядового пользователя я тут в расчёт не беру) должно быть более одного физического пути на случай выхода из строя канала или промежуточного устройства. А это значит — петли.

STP спешит на помощь


Проблему вышеописанных «широковещательных штормов» решает запуск на свитчах протокола STP (или одного из его расширений).

Spanning Tree Protocol, или протокол простирающегося древа, приводит сеть к «древовидному» виду — с корнем и растущими из него «ветвями». Один из свитчей становится «корнем» (root bridge), затем все остальные рассчитывают «стоимость» (cost) достижения корня из всех своих портов, имеющих такую возможность (то есть, по сути, закольцованных где-то там, далеко), и отключают все неоптимальные линки. Таким образом, разрывая «петли». Если в дальнейшем в сети произойдёт сбой, и «корень» вдруг окажется недостижим через работающий порт, включится лучший из ранее заблокированных и связь будет восстановлена.

А теперь подробнее

Основной «рабочей лошадкой» STP являются Bridge Protocol Data Units aka BPDU. Это пакеты-«зонды», рассылаемые свитчами, и содержащие в себе:
1) идентификатор корневого свитча (Root ID);
2) идентификатор свитча, сформировавшего пакет (Bridge ID);
3) стоимость пути от второго к первому (Cost);
4) порт, из которого BPDU был исторгнут.

Предположим, сеть только что включили. Свитчи друг о друге ничего не знают. Нужно найти друг друга и выбрать, кто же станет «корнем» дерева. Свитчи дружно начинают сыпать во все порты BPDU, где указывают «корнем» себя любимого (Root ID = Bridge ID).

STP работает так, что выйгрывает «выборы корня» свитч с самым низким Bridge ID, который состоит из двух частей: 2-байтный приоритет (по умолчанию 32768) и MAC-адрес свитча. Таким образом, если никаких настроек не производилось, и приоритеты у всех равны, выйграет свитч с самым маленьким MAC-адресом. Есть весьма отличная от нуля вероятность, что это будет самый старый (и, наверно, самый низкопроизводительный) свитч в организации, с закономерным итогом… Не забывайте об этом, друзья. Настраивайте приоритеты!

Итак, свитч с самым низким ID игнорирует принятые BPDU товарищей и продолжает гнуть свою линию — слать раз в 2 секунды свои BPDU, такие же точно, как самый первый. Он — «корень» топологии, он не будет отключать свои порты.
А вот остальные, получив BPDU со значением Root ID меньше, чем свой собственный Bridge ID, понимают, что «корень» — где-то там. Они перестают рассылать свои BPDU. Отныне и впредь, они просто ретранслируют BPDU «корневого» свитча, подставив на место Bridge ID себя, и пересчитав «стоимость» достижения «корня» (добавив к имеющейся в полученном BPDU свою долю).

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

Порт, из которого был получен корневой BPDU с наилучшей стоимостью, называется root-портом, он всегда работает. Порты, из которых получены корневые BPDU с худшей стоимостью, очевидно, ведут в «петли», от которых и нужно избавиться. Такие линки блокируются с одной стороны тем свитчом, чей Bridge ID ниже. Но блокируются не полностью, нам ведь надо иметь возможность вернуть их к жизни в случае сбоя. BPDU в таких линках продолжают отправляться и приниматься.
Если же Bridge ID в обоих пакетах одинаков (например, свитчи соединены более чем одним кабелем), выйгрывает тот, в котором указан меньший номер отправившего порта (Fa0/1 выйграет у Fa0/2).

Виды портов

В классическом STP, определённом стандартом 802.1d, порты могут быть такими:

1) Root port — ведёт к корню, имеет наименьшую стоимость среди собратьев, включён.
2) Designated port — ведёт не к «корню», а в какой-то сегмент сети, работает.
По понятной причине, у «корневого» свитча нет ни одного root порта. Все его порты — designated.
3) Blocked port — ведёт к корню и имеет нелучшую стоимость пути. Заблокирован для всего трафика, кроме BPDU. С другой стороны на этом линке — работающий designated port.

Состояния и переходы

Но самое, пожалуй, интересное — состояния портов. Выше я делил их всего на 2 — работает или заблокирован. На самом деле, их больше, по той простой причине, что работа STP — штука отнюдь не мгновенная, она требует времени. А создать шторм в сети — дело очень быстрое. Поэтому, «во избежание», так сказать, порты проходят через цепочку состояний в процессе работы.

1) Listening — порт включился (воткнули кабель/дали питание).
Передавать трафик страшно — а вдруг петля? Поэтому трафик не передаётся никакой, кроме BPDU. Ищем корень, прикидываем, какие порты будут работать.
Продолжительность — 15 секунд по умолчанию, диод на свитче моргает оранжевым.
2) Learning
Передавать трафик ещё страшно, но свитч уже принимает пакеты помимо BPDU, запоминает MAC-адреса в CAM-таблицу.
Продолжительность — 15 секунд по умолчанию.
3) Forwarding
Лампочка замигала радостным зелёным цветом, порт работает и передаёт данные.
4) Blocking/Disabled
Ну тут по названию всё ясно. Либо линк пришлось отключить, дабы не создавать петлю, либо порт административно выключен.

Обратите внимание, что минимум 30 секунд проходит с момента включения порта до начала передачи данных. В случае быстро загружающегося компьютера (или воткнутого в порт IP-телефона) это может создать проблему. (Решается включением режима portfast, но это тема для другого разговора.)

В случае сбоя в сети, где-то, где BPDU раньше ходили, они ходить перестают. И Blocked-порты, теперь получающие лучшие BPDU, выждав таймаут (20 секунд), переводятся в режим Designated, проходя цепочку состояний Listening — Learning — Forwarding (+30 секунд).
Таким образом, восстановление работоспособности сети может занимать до 50 секунд. Но, согласитесь, это гораздо лучше, чем неработоспособность после сбоя вообще.

И напоследок


Впоследствии, недостатки STP, о которых я упомянул (медленное восстановление работы сети), и о которых не упомянул, решались расширениями к протоколу.
Рассмотрим их вкратце.

1) RSTP (Rapid, быстрый)

Хранит в памяти кандидата на замену вышедшему из строя Root-порту (второе место по степени «наилучшести»), и способен очень быстро переключиться на него, не ожидая всех таймеров. Не получил 3 BPDU подряд на Root порте? Переключаюсь без лишних размышлений.

2) PVST+ (Per VLAN, по VLANный)

Зачем блокировать весь линк? Напрасная трата ресурсов! А давайте для каждого VLANа рассчитаем свою топологию STP, независимую. Таким образом, для одного VLAN будут одни линки заблокированы, а для другого — другие. Закон соблюдён и польза несомненна. При этом, в отправляемых BPDU номер VLANа хранится… в приоритете. 12 младших бит отданы под номер VLANа, а из 4 старших формируется, собственно, приоритет (имеющий при таком раскладе всего 16 легальных значений, с шагом 4096). Поле «приоритет» по умолчанию для VLAN 3 будет, таким образом, 32768 + 3 = 32771.

3) Rapid PVST

Cisco-проприетарный, сочетает свойства первых двух.

4) MSTP (Multiple)

PVST+ хорош, спору нет, но что если у нас over 9000 VLANов? Просчёт топологий для каждой из них может сильно загрузить процессор. Да и нужно ли это, если мы не занимаемся тонкой настройкой каждой полученной топологии? MST позволяет сгруппировать VLANы в т.н. instance (наборы), рассчитывая топологию уже для этих, более крупных образований.

В процессе написания

Использовались википедия и остатки знаний курса CCNA в голове.

Tags:
Hubs:
+61
Comments 41
Comments Comments 41

Articles