Edge port что это
Основная задача STP — предотвратить появление петель на втором уровне. Как это сделать? Да просто отрубить все избыточные линки, пока они нам не понадобятся. Тут уже сразу возникает много вопросов: какой линк из двух (или трех-четырех) отрубить? Как определить, что основной линк упал, и пора включать запасной? Как понять, что в сети образовалась петля? Чтобы ответить на эти вопросы, нужно разобраться, как работает STP.
STP использует алгоритм STA (Spanning Tree Algorithm), результатом работы которого является граф в виде дерева (связный и без простых циклов )
Для обмена информацией между собой свичи используют специальные пакеты, так называемые BPDU (Bridge Protocol Data Units). BPDU бывают двух видов: конфигурационные (Configuration BPDU) и панические “ААА, топология поменялась!” TCN (Topology Change Notification BPDU). Первые регулярно рассылаются корневым свичом (и ретранслируются остальными) и используются для построения топологии, вторые, как понятно из названия, отсылаются в случае изменения топологии сети (проще говоря, подключении/отключении свича). Конфигурационные BPDU содержат несколько полей, остановимся на самых важных:
Что все это такое и зачем оно нужно, объясню чуть ниже. Так как устройства не знают и не хотят знать своих соседей, никаких отношений (смежности/соседства) они друг с другом не устанавливают. Они шлют BPDU из всех работающих портов на мультикастовый ethernet-адрес 01-80-c2-00-00-00 (по умолчанию каждые 2 секунды), который прослушивают все свичи с включенным STP.
Сначала выбирается так называемый корневой мост/свич (root bridge). Это устройство, которое STP считает точкой отсчета, центром сети; все дерево STP сходится к нему. Выбор базируется на таком понятии, как идентификатор свича (Bridge ID). Bridge ID это число длиной 8 байт, которое состоит из Bridge Priority (приоритет, от 0 до 65535, по умолчанию 32768+номер vlan или инстанс MSTP, в зависимости от реализации протокола), и MAC-адреса устройства. В начале выборов каждый коммутатор считает себя корневым, о чем и заявляет всем остальным с помощью BPDU, в котором представляет свой идентификатор как ID корневого свича. При этом, если он получает BPDU с меньшим Bridge ID, он перестает хвастаться своим и покорно начинает анонсировать полученный Bridge ID в качестве корневого. В итоге, корневым оказывается тот свич, чей Bridge ID меньше всех.
Такой подход таит в себе довольно серьезную проблему. Дело в том, что, при равных значениях Priority (а они равные, если не менять ничего) корневым выбирается самый старый свич, так как мак адреса прописываются на производстве последовательно, соответственно, чем мак меньше, тем устройство старше (естественно, если у нас все оборудование одного вендора). Понятное дело, это ведет к падению производительности сети, так как старое устройство, как правило, имеет худшие характеристики. Подобное поведение протокола следует пресекать, выставляя значение приоритета на желаемом корневом свиче вручную, об этом в практической части.
После того, как коммутаторы померились айдями и выбрали root bridge, каждый из остальных свичей должен найти один, и только один порт, который будет вести к корневому свичу. Такой порт называется корневым портом (Root port) . Чтобы понять, какой порт лучше использовать, каждый некорневой свич определяет стоимость маршрута от каждого своего порта до корневого свича. Эта стоимость определяется суммой стоимостей всех линков, которые нужно пройти кадру, чтобы дойти до корневого свича. В свою очередь, стоимость линка определяется просто — по его скорости (чем выше скорость, тем меньше стоимость). Процесс определения стоимости маршрута связан с полем BPDU “Root Path Cost” и происходит так:
Ближайший свич смотрит на скорость своего порта, куда BPDU пришел, и добавляет стоимость согласно таблице
Далее этот второй свич посылает этот BPDU нижестоящим коммутаторам, но уже с новым значением Root Path Cost, и далее по цепочке вниз
Если имеют место одинаковые стоимости (как в нашем примере с двумя свичами и двумя проводами между ними — у каждого пути будет стоимость 19) — корневым выбирается меньший (fa01, а не fa12, к примеру) порт.
Далее выбираются назначенные ( Designated ) порты. Из каждого конкретного сегмента сети должен существовать только один путь по направлению к корневому свичу, иначе это петля. В данном случае имеем в виду физический сегмент, в современных сетях без хабов это, грубо говоря, просто провод. Назначенным портом выбирается тот, который имеет лучшую стоимость в данном сегменте. У корневого свича все порты — назначенные.
И вот уже после того, как выбраны корневые и назначенные порты, оставшиеся блокируются, таким образом разрывая петлю.
На картинке маршрутизаторы выступают в качестве коммутаторов. В реальной жизни это можно сделать с помощью дополнительной свитчёвой платы.
Чуть раньше мы упомянули состояние блокировки порта, теперь поговорим о том, что это значит, и о других возможных состояниях порта в STP. Итак, в обычном (802.1D) STP существует 5 различных состояний:
блокировка (blocking): блокированный порт не шлет ничего. Это состояние предназначено, как говорилось выше, для предотвращения петель в сети. Блокированный порт, тем не менее, слушает BPDU (чтобы быть в курсе событий, это позволяет ему, когда надо, разблокироваться и начать работать)
прослушивание (listening): порт слушает и начинает сам отправлять BPDU, кадры с данными не отправляет.
обучение (learning): порт слушает и отправляет BPDU, а также вносит изменения в CAM-таблицу, но данные не перенаправляет.
перенаправление/пересылка (forwarding): этот может все: и посылает/принимает BPDU, и с данными оперирует, и участвует в поддержании таблицы mac-адресов. То есть это обычное состояние рабочего порта.
отключен (disabled): состояние administratively down, отключен командой shutdown . Понятное дело, ничего делать не может вообще, пока вручную не включат.
Порядок перечисления состояний не случаен: при включении (а также при втыкании нового провода), все порты на устройстве с STP проходят вышеприведенные состояния именно в таком порядке (за исключением disabled-портов). Возникает закономерный вопрос: а зачем такие сложности? А просто STP осторожничает. Ведь на другом конце провода, который только что воткнули в порт, может быть свич, а это потенциальная петля. Вот поэтому порт сначала 15 секунд (по умолчанию) пребывает в состоянии прослушивания — он смотрит BPDU, попадающие в него, выясняет свое положение в сети — как бы чего ни вышло, потом переходит к обучению еще на 15 секунд — пытается выяснить, какие mac-адреса “в ходу” на линке, и потом, убедившись, что ничего он не поломает, начинает уже свою работу. Итого, мы имеем целых 30 секунд простоя, прежде чем подключенное устройство сможет обмениваться информацией со своими соседями. Современные компы грузятся быстрее, чем за 30 секунд. Вот комп загрузился, уже рвется в сеть, истерит на тему “DHCP-сервер, сволочь, ты будешь айпишник выдавать, или нет?”, и, не получив искомого, обижается и уходит в себя, извлекая из своих недр айпишник автонастройки. Естественно, после таких экзерсисов, в сети его слушать никто не будет, ибо “не местный” со своим 169.254.x.x. Понятно, что все это не дело, но как этого избежать?
Для таких случаев используется особый режим порта — portfast. При подключении устройства к такому порту, он, минуя промежуточные стадии, сразу переходит к forwarding-состоянию. Само собой, portfast следует включать только на интерфейсах, ведущих к конечным устройствам (рабочим станциям, серверам, телефонам и т.д.), но не к другим свичам.
Протоколы семейства STP обычно несильно будоражат умы инженеров. И в большинстве своём на просторах интернета чаще всего сталкиваешься с деталями работы максимум протокола STP. Но время не стоит на месте и классический STP всё реже встречается в работе и в различных материалах вендоров. Возникла идея сделать небольшой обзор ключевых моментов RSTP в виде FAQ. Всем, кому интересен данный вопрос, прошу под кат.
Что настраивать STP, RSTP или MST?
В современных стандартах протокол STP уже нигде не фигурирует. Известный всем 802.1d в последней редакции (802.1d-2004) описывает протокол RSTP. При этом MST перекочевал в 802.1q (802.1q-2014). Как мы помним, ранее RSTP описывался стандартом 802.1w, а MST — 802.1s.
RSTP и MST имеют существенно меньшее время сходимости. Они намного быстрее перестраивают топологию сети в случае отказа оборудования или каналов связи. Время сходимости для ряда отказов этих протоколов меньше 1 секунды против 30+ секунд в случае STP. Поэтому классический STP рекомендуется использовать только там, где задействуется старое оборудование, не поддерживающее более современные протоколы.
MST в своей работе использует алгоритмы RSTP. Но в отличие от RSTP, MST позволяет создавать отдельную топологию (instance) STP для группы VLANов. В случае обычного RSTP у нас на все VLANы одна общая топология. Это не очень удобно, так как не позволяет даже в ручном режиме балансировать трафик по разным каналам. А значит, мы теряем, как минимум половину пропускной способности в случае наличия избыточных путей.
Некоторые вендоры (в частности Cisco) предлагают ещё одну разновидность быстрого протокола STP – Rapid Per-VLAN Spanning Tree (PVRST+). В этом случае для каждой виртуальной сети строится своя топология, что позволяет более эффективно утилизировать каналы. Основной минус такого подхода – это ограничение на максимальное количество таких топологий. Для обеспечения работы каждой топологии устройство тратит аппаратные ресурсы. А они не безграничны. Например, в коммутаторах Cisco 2960 поддерживается максимум 128 «инстансов» STP.
Таким образом, MST является хорошей альтернативой между стандартным RSTP и проприетарным PVRST+. Особенно если наша сеть построена на базе коммутаторов разных производителей. Стоит заметить, что все три вариации быстрого STP совместимы друг с другом.
В дальнейшем, упоминая RSTP, мы будем подразумевать в том числе и его расширения MST/PVRST+.
Какие технологии обеспечивают быстроту реакции в работе RSTP?
RSTP в первую очередь опирается на работу механизмов, не привязанных к стандартным таймерам. Именно поэтому он позволяет получить существенно меньшее время сходимости сети. Можно выделить следующие улучшения в работе RSTP по сравнению с классическим STP:
В классическом варианте BPDU «генерит» в сети только корневой коммутатор. Все остальные устройства лишь ретранслируют его. Таким образом, отсутствие BPDU от вышестоящего устройства значит, что проблема может быть в любом месте между данным устройством и корневым коммутатором. Поэтому приходилось ждать достаточно долго (MaxAge=20 сек) прежде чем, смириться с тем, что что-то пошло не так и нужно перестраивать топологию.
- точка-точка (point-to-point) – к такому порту подключен только один RSTP коммутатор;
- общий (shared) — к такому порту подключено несколько RSTP коммутаторов (через хаб, что в наше время является большой экзотикой).
В классическом STP порт, который должен стать корневым, проходит все стадии по переходу в режим передачи (Listening → Learning → Forwarding), что занимает более 30 секунд.
Прежде чем коснуться механизма Proposal/Agreement, нужно отметить два разных типа портов в RSTP: пограничный порт (Edge port) и не пограничный (non-Edge port). В Edge порт подключаются оконечные устройства (ПК, серверы, в ряде случаев маршрутизаторы и пр.). В не Edge-порт подключаются другие коммутаторы, участвующие в топологии STP.
На коммутаторах Cisco тип порта Edge задаётся командой spanning-tree portfast.
RSTP использует механизм Proposal/Agreement для быстрого переходя портов из состояния Discarding в состояние Forwarding. Этот механизм запускается, когда у коммутатора меняется Root Port (как минимум при включении в сеть). В этом случае он выключает все порты, не являющиеся Edge-портами. Об этом оповещает вышестоящий коммутатор (куда как раз смотрит Root port), после чего включает в режим Forwarding только Root port. Остальные порты (не Edge) находятся в заблокированном состоянии, пока не произойдёт одно из двух:
RSTP отличается от STP тем, что состояние порта отвязали от его роли. Это позволило описать роль порта в топологии сети без оглядки на его состояние. А значит, обладать лучшим видение топологии сети и возможностью оперативно реагировать на изменения в ней. Так появились альтернативный (alternative) и резервный (backup) порты. Альтернативный порт – замена корневому. Через него может быть достигнут корневой коммутатор, но при этом данный порт не имеет роли корневого (т.е. получает BPDU c худшей метрикой) и не является назначенным (т.е. не является лучшим в данном сегменте сети для достижимости корневого устройства).
В протоколе RSTP альтернативный порт переходит в состояние передачи сразу же после того, как откажет корневой. Такого же поведения можно добиться в классическом STP, используя проприетарные доработки. Например, Cisco предлагает для этих целей технологию UplinkFast.
В такой ситуации, если у устройства есть другой маршрут к корневому коммутатору, в классическом STP порт, который ранее был заблокирован, пройдёт все стадии и переключится в режим передачи только через 50 секунд (MaxAge + 2x Forward Delay).
В случае RSTP коммутатор немедленно оценит полученный BPDU (в RSTP нет MaxAge таймера) и начнёт передавать свои, выставив флаг Proposal. Получив такое BPDU, коммутатор, потерявший связь с «рутом», примет участие в механизме Proposal/Agreement, так как у него сменился корневой порт. А дальше достаточно оперативно порты на обоих коммутаторах перейдут в состояние передачи.
RSTP в своей работе использует обычные таймеры в следующих случаях:
-
К порту подключается устройство, поддерживающее только классический STP. В этом случае порт коммутатора из режима работы RSTP переходит в режим STP. А значит проходит все стандартные для STP стадии: Blocking, Listening, Learning, Forwarding (в зависимости от того, с какими значениями корневого коммутатора и стоимости будет получен BPDU).
Деление на порты Edge и non-Edge характерно не только для RSTP, но и для STP. Но в случае STP – это вендорная доработка протокола, нежели требования стандарта.
Основные «ЗА» включения на порту режима Edge (для оборудования Cisco – это portfast) в случае использования протокола STP:
- При срабатывании механизма Proposal/Agreement блокируются все не Edge-порты. А это значит, что если мы не настроим обычный порт, куда подключено оконечное оборудование, в режим Edge, коммутатор будет выключать его на 30 секунд (работа RSTP по таймерам) каждый раз, когда меняется root port. В простых сетях это происходит не часто. Но в относительно большой легко. Это как раз тот случай, когда кажется, что перестроения произойдут в сети достаточно быстро, и никто этого даже не заметит. А по факту устройства «отваливаются» от сети на полминуты.
С настройкой порта в режиме Edge нужно быть аккуратными.
Давайте посмотрим на поведение коммутатора Cisco с портом в режиме portfast (Edge). Порт сразу переходит в режим передачи. Но он продолжает участвовать в передаче BPDU и главное продолжает слушать сеть на наличие BPDU от других устройств, на случай если по ошибке к нему подключили другой коммутатор. Если вдруг приходит BPDU, порт теряет свое состояние portfast и проходит стандартные фазы RSTP. Так в чём же может быть проблема?
BPDU отправляются в диапазоне от 0 до 2 секунд после включения порта. Плюс можно добавить к этому время распространения BPDU по сети (актуально для STP). Поэтому в течение нескольких секунд в сети может быть петля. Если трафика будет очень много, этих секунд может оказаться достаточно, чтобы широковещательный шторм, порождённый петлёй, «убил» control-plane нашего коммутатора. Чтобы этого не допустить рекомендуется portfast настраивать в связке с дополнительными технологиями, например: BPDU Guard и storm-control.
Если сеть многовендорная, причём часть оборудования вообще не поддерживает STP ни в каком виде, всё будет плохо?
Это вопрос не совсем связан с работой RSTP, но всё же я решил его включить. Как это ни странно, подобные вопросы периодически возникают у наших заказчиков. Поэтому есть смысл на нём остановиться.
Если коммутатор не поддерживает STP ни в каком виде, что же он будет делать с BPDU пакетами? Ответ прост – передавать такие пакеты через все порты. В качестве MAC адреса назначения BPDU пакета STP и RSTP устанавливают адрес 0180.C200.0000, который является multicast адресом. Такой BPDU пакет передаётся в рамках VLAN 1.
Протокол MST данные обо всех топологиях упаковывает в один BPDU (кстати, именно поэтому максимальное количество инстансов для MST — 64). В качестве адреса назначения используется стандартный MAC-адрес 0180.C200.0000.
Протоколы PVST+ и PVRST+ в своей работе используют два типа BPDU:
- IEEE-formatted BPDU для совместимости с другими версиями STP, содержит данные топологии STP для VLAN 1. В качестве адреса назначения используется стандартный MAC-адрес 0180.C200.0000.
- PVST+ BPDU, которые содержат данные топологии STP для разных VLANов. В качестве адреса назначения используется MAC-адрес 0100.0CCC.CCCD.
Ещё один занятный момент связан с тем, что даже если мы исключим VLAN 1 из транка между коммутаторами, BPDU для первого VLAN всё равно будут передаваться.
В итоге, если в нашей топологии будет коммутатор, не поддерживающий STP, он будет выглядеть для топологии STP, как обычный канал связи.
А что произойдёт, если соединить два порта между собой на коммутаторе SW1 (т.е. сделать кольцо). Наша сеть погибнет? Есть большой шанс, что нет. В этом случае Root SW получит собственный BPDU на тот же порт, с которого его отправил. После этого он сразу же его заблокирует. И петля останется «жить» только в пределах коммутатора SW1. Но положительный исход возможен, только если Root SW раньше времени не «захлебнётся» от широковещательного шторма, появившегося вследствие петли на SW1. Поэтому лучше не использовать в сети коммутаторы, не поддерживающие STP.
Нужен ли STP/RSTP/MST/… в сети, если там нет петель?
Безусловно. Если петли нет сейчас, не факт, что она не появится в будущем. Например, из-за простой человеческой ошибки, когда один access-порт коммутатора подключается к другому access-порту того же устройства.
Данный FAQ не претендует на полноту. Он носит скорее ознакомительный характер и задаёт некий вектор дальнейших изысканий по тому или иному вопросу, связанному с работой современных протоколов семейства STP.
Ethernet легко подвержен бродкаст-штормам, когда в сети возникают петли.
Но для обеспечения резервирования, требуются альтернативные линки и это приводит топологию сети к петлям.
STP как раз дает возможность использовать резервирование, но избежать петель.
Juniper поддерживает данные вариации STP: STP, RSTP(используется по дефолту), MSTP, VSTP.
Итого зачем вообще нужен STP:
- Предотвращает бродкаст штормы - Обеспечивает резервирование дополнительными линками, без петель - Позволяет подключать к сети устройства, не поддерживающие STP (используя edge ports)
Корень дерева (root tree | root bridge) - это свитч, который выбирается алгоритмом STP на основании Bridge ID (Bridge Priority [0 - 65535] + MAC-addr свитча). Default priority = 32 768. В приоритете коммутатор с наименьшим Bridge ID. В дальнейшем он используется для рассчета наилучшего пути от bridge до root bridge.
Фреймы ходят по сети к получателю - leaf (ПК или любой другой не транзитный хост) - вдоль ветвей (branches).
Tree branch (ветвь) - сегмент сети или линк между бриджами.
Designated bridges - свитчи, которые передают фреймы по STP-дереву.
STP создает единственный возможный путь между root и leaf. Альтернативные пути переводятся в standby режим.
Модификации STP
STP работает на основании "создания" bridge (switch).
Root bridge (switch) - в самом верху.
Ethernet от root switch подсоединяет другие свитчи в Local Area Network (LAN).
В STP и RSTP инстансах свитчам присваиваются extended system-id.
При изменении топологии, bridge извещает об этом root bridge, который требует от остальных почистить записи текущей топологии.
В построенном дереве только root bridge генерирует BPDU.
Дефолтные тайминги 50 sec до перехода в состояние forwarding.
Нахождение порта в состояниях:
- blocking (20 sec)
- listening (15 sec)
- learning (15 sec)
- forwarding
- Hello (2 sec)
- Max Age (20 sec)
- Forward delay timer (15 sec)
- Работает с 802.1D 1998 bridges
- STP обратносовместим с RSTP, можно включать STP на 802.1D 1998 bridges
- Годится для устаревших сетей, где не требуется быстрая сходимость.
- STP и RSTP ограничены одним инстансом для одного интерфейса. Используется set rstp interface для включения интерфейса в RSTP инстанс.
- STP медленее RSTP
- Не разделяет вланы. Создает spanning tree без учетов вланов и возможности постоения топологии для каждого влана. (в MSTP решена эта проблема)
- Не обеспечивает быструю сходимость. STP использует тайминги, RSTP использует handshake механизм.
- В IEEE 802.1D STP не используются edge ports.
На MX (c 14.1R1): - Без включения traceoptions работает логирование состояний и ролей интерфейсов STP. - Сбор информации что стриггерило изменения в STP (роль или статус).
На SRX: Поддерживается начиная с 15.1X49-D70 на некоторых девайсах.
На EX: По дефолту используется RSTP. Если работаем с Junos, поддерживающем Enhanced Layer 2 Software (ELS) - можно указать чтобы STP использовался принудительно (через указание force-version в конфиге).
Config
1. удаляем RSTP глобально или выключаем на конкретных интерфейсах:
2. включаем STP глобально или для конкретных интерфейсов:
3. для более быстрого изучения маков - включаем Address Resolution Protocol (ARP) [при использовании irb | rvi]
BPDU (bridge protocol data units)
Когда отработал STA (spanning tree algorithm), всем портам назначены роли и состояния, идентифицированы root и designated bridges, требуется механизм для поддержания данной топологии в актуальном состоянии. Используем BPDU.
Root bridge отправляет BPDU каждые 2 сек (дефолтный hello time interval RSTP) на мультикаст-адрес: 01:80:c2:00:00:00. Когда на порт приходит BPDU, он сравнивает данные, с полученными ранее, и на основании сравнения:
- Если данные BPDU совпадают с существующей записью в таблице MAC-адресов, порт сбрасывает таймер max age на 0 и пересылает новый BPDU с текущей активной информацией о топологии на следующий порт в spanning tree. - Если топология в BPDU была изменена, обновляется таблица MAC-адресов, max age устанавливается в 0, и новый BPDU пересылается с текущей активной информацией о топологии на следующий порт в spanning tree. - Когда порт не получает BPDU в течение 3 * hello (3*2 = 6 сек), он реагирует одним из двух способов. -Если bridge является root port: происходит полное перестроение spanning tree. -Если bridge является любым некорневым мостом: RSTP обнаруживает, что подключенный хост не умеет отправлять BPDU, и назначает этот порт в edge port.
STP генерирует свои BPDUs. Сетевуха на хосте (ПК, сервер, . ) тоже генерирует свои BPDUs. Эти BPDU хостов могут быть обработаны STP свитча и привести к проблемам на сети. Поэтому лучше включать BPDU Protection на edge ports.
- configuration BPDUs
- topology change notification (TCN) BPDUs
- topology change acknowledgment (TCA) BPDUs
Состояния портов (RSTP)
- Discarding - отбрасывает все BPDU, все data-фреймы и не изучает mac-адреса. [в STP аналогичен по функциям: blocking, disabled, learning]
- Learning - изучает маки, и строит таблицу коммутации и пересылает BPDU
- Forwarding - порт пересылает и фильтрует фреймы > становится частью активного spanning tree. Также есть обмен BPDU.
- blocking - ничего не шлет, но слушает BPDU
- listening - начинает отправлять BPDU, но пока не фреймы
- learning
- forwarding
- disabled - admin down. ничего не пересылает.
Роли портов (RSTP)
- Root port - ближайший к root bridge. Это единственный порт, который получает фреймы от root bridge и пересылает их на него. Root bridge от себя отправляет BPDU с cost = 0. свитч, получивший BPDU - добавляет cost интерфейса, с которого пришел BPDU. И так далее. В случае, когда cost равнозначны с двух интерфейсов - будет выбран с наименьшим номером (ge-0/0/0, в не ge-0/0/10).
- Designated port - порт, передающий трафик от root bridge к leaf. Designated bridge имеет один designated порт для каждого LAN. Root bridge передает фреймы во все designated порты. Также определяется по наименьшей cost. На root bridge все порты designated. На Leaf только один designated, иначе петля.
- Alternate port - альтернатиный порт к root bridge. Он не является частью активного spanning tree, но когда root port накрывается (если падает линк или переходит в состояние отбрасывания пакетов), то alternate port сразу принимает на себя его роль. Отсутствует в обычном STP, за счет чего STP отстает по времени сходимости.
- Backup port - резервный для desidnated порта. Работает аналогично alternate port.
- Disabled port - порт, не принимает участия в активном spanning tree.
- Edge port - порт в сторону хоста, не поддерживаюшего STP (ПК, сервер, роутеры, тупиковые хабы). Т.к. предполагается, что хосты не способны образовать петлю => edge port сразу переходит в состояние передачи фреймов. Можно назначить edge порт, а также STP может сам распознать edge порт (через отсутствие связи с конечными станциями).
- root
- designated
- non-designated
- disabled
RSTP (Rapid STP)
Отличие в скорости реакции на изменение топологии. При изменении топологии, свитч немедленно чистит записи о текущей топологии. Для p2p и edge-портов - быстрый переход к forwarding state.
+ появились alternate и backup роли портов. Что дает возможность заранее подготовиться к факапу, а не принимать решение во время факапа.
RSTP: сходимость 6 сек (3 * hello BPDU interval)
В построенной топологии (дереве) все свитчи генерируют BPDU каждые 2 sec.
В RSTP добавились port-mode:
- shared (half duplex) - p2p между свитчами, проходит обычный цикл во всеми таймингами blocking > listening > learning > forwarding.
- p2p (full duplex) - тут свитч сам запрашивает у соседа-свитча на p2p линке - давай дружить (тут вся инфа о нашем bridge), я вижу root bridge вот так. Сосед принимает решение, сравнивая полученные данные с уже имеющимися. Для обмена данными используются proposal BPDU (запрос локального bridge) и agreement BPDU (ответ соседа). Этот метод обмена данными обходит стороной дефолтные тайминг STP и является основням ускорителем RSTP.
- egde - для конечных устройств. Моментально становятся в состояние - forwarding.
По дефолту именно RSTP используется в Juniper.
- Быстрее в сходимости при факапах.
- Voice и video лучше использовать с rstp.
- RSTP обратносовместим с STP, причем на свитче не обязательно использовать именно RSTP.
- Поддерживается больше портов, чем в MSTP или VSTP
- Поддерживает edge ports на MX и ACX роутерах
- STP и RSTP ограничены одним инстансом для одного интерфейса. Используется set rstp interface для включения интерфейса в RSTP инстанс.
- Не работает с 802.1D 1998 bridges
- Не разделяет вланы. Создает spanning tree без учетов вланов и возможности постоения топологии для каждого влана. (в MSTP решена эта проблема)
Config
[глобально, внутри routing instance, внутри logical system]
- Добавляем интерфейсы [все последующие фичи применимы и к 'interface all']
- Назначаем приоритет интерфейса для определения root port. [default priority = 128, значение должно быть кратно 16 (16,32,112 и т.п.)]
- Назначаем тип интерфейса. [defaults: full-duplex = p2p mode, half-duplex = shared]
- Задаем bridge-priority (switch priority). [default priority = 32 768, значение должно быть кратно 4096]
- Max время ожидания hello-BPDU . [defaults: 20 sec]
- Интервал пересылки configuration-BPDU от root bridge. [defaults: 2 sec]
Опционально:
- Для поддержания устаревших bridge включаем чистый stp. [чтобы откатить - удаляем force-version из конфига и clear spanning-tree protocol-migration]
- Добавление provider-bridge в rstp. [dst mac-address BPDU выставляется = 01:80:c2:00:00:08 и он не блочится RE, на которую прилетел]
- Задать extended system ID. [это ID STP|RSTP инстанса]
- interface cost (вместо определения cost по interface speed - задаем cost вручную)
- Настроить интерфейс как edge - не ожидает BPDU от хоста. Если прилетела BPDU, порт становится non-edge port и переводится в forwarding state. [не работает для чистого STP]
- bridge port пребывает в learning и listening 15 sec, до перехода в forwarding state. Можно этот интервал изменить. [defaults: 15 sec]
NSB - non stop bridging ptorotoсol синхронизирует RSTP на обоих RE, чтобы избежать перерыва сервиса при RE switchover.
- Включаем NSB, если на девайсе две RE [кстати, работает для STP, RSTP, MSTP]:
Root Bridge Fails
Когда link на root port падает, в BPDU добавляется флаг, topology change notification (TCN).
Когда этот BPDU доходит до следующего порта в VLAN, таблица MAC-адресов сбрасывается, и BPDU едет на следующий bridge. В итоге, все порты во VLAN обнулили свои таблицы MAC. После этого RSTP назначает новый root port.
Если root port или designated port падают - alternate или backup port берут на себя их роль после обмена BDPU (proposal-agreement handshake).
Если локальный порт становится root или designated, то он согласовывает быстрое изменение тем же proposal-agreement handshake с ближайшим свитчем.
Так как падение линка приводит к очистке маков на всей сети - это немного затормаживает работу сети и образует неплохой такой флуд для переобучения маков.
Включенный ARP (address resolution protocol) заставляет коммутатор активно отправлять ARP-запросы на IP-адреса в кэше ARP.
Включение ARP в STP наиболее полезно для избегания чрезмерного флуда в L2.
MSTP (Multiple STP)
Является расширением RSTP. На одну физическую топологию накладывается несколько STP-инстансов (STI). Одна STI может состоять из одного или нескольких вланов.
В отличие от STP и RSTP, для одного влана порт будет в состоянии forwarding, для другого - blocked.
Если требуется разбалансировать нагрузку или просто часть вланов пустить по одному дереву, а остальные по-другому, то MSTP для этого подойдет лучше всего. Будет создано столько STP, сколько топологий мы хотим использовать.
Быстрая сходимость сети унаследована от RSTP.
MSTI (MST instance) - это по сути набор вланов.
MSTP region - это группка свитчей с одинаковыми MSTI. Также у свитчей одного региона должны быть одинаковыми:
- region name - задается админом - это просто зазвание
- revision level - задается админом
- mapping table
MSTP region поддерживает до 64 MSTI, каждый MSTI может содержать до 4094 vlans.
Когда мы создаем регион, MSTP автоматом создает internal STI (IST instance 0), в котором определяется Regional Root Bridge и добавляются все вланы, которые не определены в другие MSTI.
Все вланы, на свитче одного MST-региона буду по умолчанию привязаны к IST. При создании новых вланов, по дефолту тоже пойдут в IST, или в MSTI, который зададим для vlan.
IST (MST instance 0) - по умолчанию существует в каждом MSTP region.
Кроме региона, MSTP создает CIST: Common and Internal Spanning Tree, которое управляет всеми MSTP регионами, а также отдельными устройствами, на которых запущен RSTP/STP [MSTP определяет их как отдельные части дерева].
CIST рассматривает MSTP регион как виртуальный bridge, несмотря на то сколько внутри региона девайсов, и позволяет коннектиться разным регионам внутри MSTP.
Благодаря CIST - в MSTP может работать с STP и RSTP.
Также есть Common Apanning Tree, который собирает IST (MSTI) и CIST вместе.
Ещё немного обобщив терминологию:
- IST - дерево внутри региона
- CIST - дерево между регионами
- CST - деревья внутри региона + деревья между регионами
О плюсах и минусах MSTP:
- Работает с несколькими вланами
- Поддерживает несколько инстансов для одного физ интерфейса
- Поддерживает edge ports на MX и ACX роутерах
- Не со всеми протоколами совместим
- Поддерживает ограниченное кол-во портов. MSTP регион поддерживает до 64 MSTIs (а в каждом инстансе 1-4094 вланов)
- MSTP больше нагружает CPU.
- Не так быстр как RSTP
Config
Для QFX5100 и других, которые не поддерживают interface all включаем mstp для диапазона интерфейсов:
Для конкретного интерфейса:
Для протокола (аналогично RSTP):
msti-id уникальна в рамках региона. То есть в другом регионе можно использовать тот же msti-id. CIST (common instance ST) msti-id = 0.
VSTP (VLAN STP)
Для PVST для каждого влана рассчитывается своя топология - при этом будут затрачены значительные ресурсы свитча (CPU, память) и по мере роста вланов - их будет тратиться всё больше и больше.
- Работает в разными вланами. Включаем VSTP внутри вланов, для которых требуется работа STP.
- VSTP и RSTP могут быть включены на свитче одновременно.
- Совместим с Cisco PVST+ и Rapid-PVST+ (но без поддержки ISL trunks)
- Можно добавить интерфейс как в global level, так и в VLAN level. Если добавить global, то VSTP будет включен во всех вланах этого интерфейса. Если будет добавлен global и VLAN level, то конфиг VLAN level будет приоритетнее и перезапишеи global level.
- Поддерживает edge ports на MX и ACX роутерах
- 1 инстанс на один влан
- Использует ограниченное кол-во портов
- VSTP может работать максимум с 509 вланами. Однако, лучше использовать не более 190.
- Для одного влана нельзя включить и VSTP и RSTP.
- Если на свитче одновременно включаем VSTP + RSTP и на свитче более 253 вланов, то для 1-253 влана будет работаеть VSTP, для остальных RSTP.
- Не работает на SRX. Также имеет разные спецификации по кол-ву вланов для разныех моделей свитчей. Лучше смотреть на сайте juniper.
- Рекомендуется включать VSTP во всех вланах. - При использовании: set protocol vstp vlan all, vlan-id 1 туда не включен, если он нужен, то добавляем отдельно: set protocol vstp vlan 1 - Максимальное кол-во вланов, используемых в VSTP - опредлеляется типов свитча и его OS. - Можно использовать VSTP вместе с cisco-свитчами PVST+ и Rapid-PVST+
При настроенном на порту STP edged-port (аналог portfast у Cisco) через него продолжают передаваться STP BPDU.
Неочевидно это потому, что edge port предполагает подключение в него конечных хостов, а также то, что порт не будет получать STP BPDU и потому участвовать в построении топологии STP.
Это действительно так - не нужно каждый раз флудить по домену STP TC и заставлять ишачить все коммутаторы новую топологию, если дело только в том, что у кого-то компьютер перезагрузился. Компьютер опять же не будет генерировать STP BPDU, кроме случая злого умысла
Что если клиент закоротит на коммутаторе два порта? Допустим, случайно это сделать трудновато, но он ведь может и по злоботе душевной, затаив обиду на инженера провайдера, уволокшего на выпускном его девушку у него из под носа.
Для случая если петля окажется на одном порту у нас есть loopback-detect - он посылает в порт тестовый пакет и, если получит его обратно в этот же порт, то блокирует его (или уведомляет NMS). А вот для разных портов непонятно - Storm-control позволит ограничить широковещательный трафик, но CPU по-прежнему может быть под ударом.
И вот тут кажется совершенно логичным, чтобы Edge-port продолжал слать BPDU - если тот ревнивец закоротит два клиентских порта, то один из них получит BPDU и заблокируется - удобно.
Интересно, что в документации об этом нигде не говорится и пришлось проверить догадку на симуляторе ENSP.
Однако есть и ещё одна тонкость в работе Edged-port (portfast).
Вы можете надеяться, что за ним находится компьютер, но реальность такова, что там может оказаться что угодно, в том числе коммутатор. Просто так игнорировать BPDU коммутатор не имеет морального права.
На полученные BPDU может быть две реакции:
1) Заблокировать этот порт от греха подальше (если включет BPDU protection (он же BPDU Guard).
2) Перевести порт в режим non-edge и пересчитать топологию - это действие по умолчанию.
То есть мы заведомо считаем, что хакеров там нет, а новое подключение легитимное.
Portfast на циске работает аналогично, как меня заверила Наташа Самойленко.
Все, о чем мы говорили ранее в этой статье, относится к первой реализация протокола STP, которая была разработана в 1985 году Радией Перлман (ее стихотворение использовано в качестве эпиграфа). В 1990 году эта реализации была включена в стандарт IEEE 802.1D. Тогда время текло медленнее, и перестройка топологии STP, занимающая 30-50 секунд (. ), всех устраивала. Но времена меняются, и через десять лет, в 2001 году, IEEE представляет новый стандарт RSTP (он же 802.1w, он же Rapid Spanning Tree Protocol, он же Быстрый STP).
Чтобы структурировать предыдущий материал и посмотреть различия между обычным STP (802.1d) и RSTP (802.1w), соберем таблицу с основными фактами:
Как мы видим, в RSTP остались такие роли портов, как корневой и назначенный, а роль заблокированного разделили на две новых роли: Alternate и Backup. Alternate — это резервный корневой порт, а backup — резервный назначенный порт. Как раз в этой концепции резервных портов и кроется одна из причин быстрого переключения в случае отказа. Это меняет поведение системы в целом: вместо реактивной (которая начинает искать решение проблемы только после того, как она случилась) система становится проактивной, заранее просчитывающей “пути отхода” еще до появления проблемы. Смысл простой: для того, чтобы в случае отказа основного переключится на резервный линк, RSTP не нужно заново просчитывать топологию, он просто переключится на запасной, заранее просчитанный.
Ранее, для того, чтобы убедиться, что порт может участвовать в передаче данных, требовались таймеры, т.е. свич пассивно ждал в течение означенного времени, слушая BPDU. Ключевой фичей RSTP стало введение концепции типов портов, основанных на режиме работы линка — full duplex или half duplex (типы портов p2p или shared, соответственно), а также понятия пограничный порт (тип edge p2p), для конечных устройств. Пограничные порты назначаются, как и раньше, командой spanning-tree portfast, и с ними все понятно — при включении провода сразу переходим к forwarding-состоянию и работаем. Shared-порты работают по старой схеме с прохождением через состояния BLK — LIS — LRN — FWD. А вот на p2p-портах RSTP использует процесс предложения и соглашения (proposal and agreement). Не вдаваясь в подробности, его можно описать так: свич справедливо считает, что если линк работает в режиме полного дуплекса, и он не обозначен, как пограничный, значит, на нем только два устройства- он и другой свич. Вместо того, чтобы ждать входящих BPDU, он сам пытается связаться со свичом на том конце провода с помощью специальных proposal BPDU, в которых, конечно, есть информация о стоимости маршрута к корневому свичу. Второй свич сравнивает полученную информацию со своей текущей, и принимает решение, о чем извещает первый свич посредством agreement BPDU. Так как весь этот процесс теперь не привязан к таймерам, происходит он очень быстро, только подключили новый свич и он практически сразу вписался в общую топологию и приступил к работе (можете сами оценить скорость переключения в сравнении с обычным STP на видео). В Cisco-мире RSTP называется PVRST (Per-Vlan Rapid Spanning Tree).
Читайте также: