Pull to refresh

Comments 16

Редакция legacy STP уже давно является архаизмом. Во многих современных книгах по сетям его даже не рассматривают. Если уж и браться за семейство протоколов STP, то стоит смотреть в сторону RSTP или же MSTP.

Небольшое замечание по статье: в состояние Blocking порт после включения переходит сразу же, как только получит superior BPDU (т.е. BPDU с лучшим Bridge ID).

Также интересен вопрос с таймером forward delay. Почему именно 15? Ответ: потому что 2*15 = 30 :). Именно 30 секунд нужно подождать, прежде чем перевести порт в состояние Forwarding, чтобы в сети не возникло временных петель. Это рекомендованное значение для сети диаметром семь хопов. Оно получается из суммирования времени распространения BPDU по сети, времени жизни BPDU в сети, времени перехода порта в состояние Blocking и пр.
RSTP и MSTP стоит на фундаменте STP. На мой взгяд, лучше разобраться с работой STP, а потом понять RSTP и MSTP. Статья про MSTP написана, но никак руки не дойдут до редактирования.
Спасибо за замечание.

Поддержу, rstp это так сказать улучшенный stp, для хорошего понимания лучше начать именно со второго.
Спасибо за статью, буду рекомендовать своим одминам

Статья сразу начинает рассматривать протокол PVSTP. Админам лучше начать с базового STP.
Учитывая, что на коммутаторах используется только один влан, то на принцип работы не влияет.
Когда писал статью, думал писать ли про оптимизацию и разные плюшки, но во множенстве других статей всё довольно ясно описано, поэтому подумал, что смысла нет писать и копипастить. По поводу TCN на портфаст:
Как мы говорили, когда в топологии что-то меняется (например, изменение состояния линка), то он рассылается по всем коммутаторам и они меняет время хранения мак адресов с 300 до 15 (в RSTP таблица мак-адресов сразу обнуляется). Это важно, когда падает линк между коммутаторами, но STP не такой умный, чтоб различать линк к какому-нибудь хосту от линка к коммутатору. Теперь представьте, юзер включает или выключает комп — у вас расслается TCN — это всё влияет на работу всех коммутаторов. А если пользователей очень много? То ваша сеть может из-за этого довольно сильно страдать. Поэтому важно переводить порты, которые точно будут подключены к хостам, в режим portfast. В этом случае, не будут работать STP таймеры и, самое главное, не будут рассылать TCN при изменении состояний таких линков.
Надеюсь, смог Вам помочь)
Надеюсь время найдётся на редактирование и постинг статей по MSTP и RSTP.
Понравилось изложение. Спасибо.
Добрый день, Руслан, а как вы добавляете в eve-ng интерфейсы Fast — Gigabit ethernet?
Если честно, специально ничего не нажимал, оно само)) Использовал vIOS L2.

Понятно, спасибо, в образах IOL присутствуют только ethernet порты. Попробую vIOS)

Bridge Priority (приоритет, от 0 до 65535, по умолчанию 32768)

Нет. Максимум 61440 и потому что инкремент строго в 4096, а не полный диапазон в 16 бит.

то сравниваются MAC-адреса (посимвольно, тот который меньше, тот побеждает).

«посимвольно» маки ни кто не сравнивает. это в первую очередь 48-bit число. Символьное представление только для удобства людей.

TCN — на мой взгляд пропущено наиважнейшее его свойство. Как только он попадает на коммутатор первым делом происходит мгновенное очищение таблицы мак адресов.

Ну и мысли в слух. Classic STP — зло. В первую очередь из-за времени сходимости. Не нужно его использовать, если есть другие варианты. Реинкарнации не сильно лучше. Простой каналов, куча костылей для обработки сложных кейсов. Причем у каждого вендора, они свои. Лучше вообще смотреть в сторону L3 фабрик. На худой конец L2 агрегацию линков.
Про TCN вы пытаетесь ввести в заблуждение. В большинстве случаев коммутатор уменьшает время хранения мак адресов с 300 до 15, о чем сказал автор в комментариях. Полное очищение таблицы происходит лишь на очень небольшом количестве моделей коммутаторов.
С точки зрения стандарта, Вы и автор безусловно правы. Но еще и практика. На моей (25 лет в сетях) большинство вендоров и хоть сколько-нибудь серьезные коммутаторы делают как я написал. Все у cisco, вроде все у джунипера и у всех huawei что я видел. Если для вас это небольшое количество, то по факту это огромная часть рынка. Нет ни малейшего смысла ждать пока bpdu с tc доберется до рута. В 802.1w уже должно было быть в стандарте такое поведение с небольшой вариацией.
Насколько я знаю, в случае STP — уменьшается время до 15 секунд, а в случае RSTP моментальное очищение.
Спасибо за полезные замечания)
Sign up to leave a comment.

Articles