Общие данные про spanning-tree
Все очень плохо:- Протоколы spanning-tree не гарантируют защиту от петель и могут не обеспечить должного резервирования. Даже хуже, так как именно резервирование по L2 с применением spanning-tree чаще всего и приводит к петлям.
- Есть разные реализации одного и того же протокола разными производителями.
Почему протокол spanning-tree не защищает от петель?
Коммутатор, который отправил BPDU, по понятным причинам не может и не должен контролировать его получение другими коммутаторами, а для рассылки BPDU использует мультикастовый адрес. Между коммутаторами могут происходить разные события, из-за которых какой-то коммутатор не получит BPDU, переведет порт из состояния alternate в состояние forwarding хоть и на короткое время, но этого будет вполне достаточно. Такое может случиться когда:- возникла односторонняя связь на оптических линках;
- между коммутаторами включился half-duplex, что привело к множественным ошибкам и потерям;
- на вашей транспортной сети из-за ошибок больше не передается мультикаст в принципе;
- через операторские сети BPDU перестали передаваться, если вообще хоть кто-то когда-то из операторов такое разрешает;
- вы просто ошиблись с конфигурацией оборудования, не смогли предусмотреть каких-то нюансов, что происходит чаще всего.
- настроить Unidirectional Link Detection (UDLD) протокол для оптических линков на случай односторонней связи;
- настроить spanning-tree loopguard для блокировки порта до соседнего коммутатора на случай, когда BPDU не будет получен по любой причине;
- настроить Connectivity Fault Management (CFM), если у вас metro-серия коммутаторов.
- UDLD протокол можно применить только между коммутаторами cisco, так как это их разработка;
- аналога spanning-tree loopguard на коммутаторе может не быть;
- надо настраивать "link-fault-management" (802.3ah) или “connectivity-fault-management" (802.3ag)
Выводы:
- CFM 802.3ag полезен для определения состояния линка;
- При наличии только loopguard из всего выше перечисленного можно себя обезопасить от потери BPDU.
Что не так с реализациями spanning-tree?
Я сейчас не буду рассказывать подробно про разные стандарты, про которые любят писать писатели. Вроде как stp в стандарте заменили на rstp, а mstp стандарт теперь еще как-то называется. Есть еще куча разных протоколов в индустриальных коммутаторах. Дело же не в этом. Дело в том, что при использовании старых коммутаторов cisco и коммутаторов других производителей, только MSTP позволяет нормально настроить кольцо. Говорят, cisco поддерживает RSTP, но называется это RPVST+ или даже PVRST+. Но это ведь не стандартный RSTP, так как в цисковской реализации для каждого влана создается свой инстанс, рассылаются для каждого влана BPDU. Это неудобно даже в случае применения на сетях с цисками:
- У вас есть коммутаторы с ограничением по количеству активных вланов: 256 или 1024. Если вы используете vtp протокол для создания вланов, то есть вероятность превышения лимита, из-за которого для определенных вланов инстанс stp создан не будет. Это 100% кольцо;
- неудобно администрировать кучу инстансов;
- загрузка cpu на коммутаторе тем выше, чем больше инстансов.
Вывод: Два из трех протоколов spanning-tree от cisco не соответствуют стандартам. Использовать следует только MSTP.
Настройка MSTP
Кажется, что mstp сложен для внедрения, но если поставить себе более простую задачу – создание аналога RSTP, то все сильно упрощается. Необходимо для начала определить для себя минимально необходимое количество инстансов. Пусть будет всего один, в который будут включены вообще все возможные вланы. Такая конфигурация никогда не будет изменяться, поэтому можно не читать про номера ревизий и т.п. Здесь в качестве нулевого - cist, через который mstp будет взаимодействовать с другими протоколами, а в первом msti - все возможные вланы. В качестве примера для 0 и 1 увеличены приоритеты. Бывает, что для 1-го увеличишь, а для cist - нет.
Для коммутатора cisco:
spanning-tree mst configurationДля коммутатора juniper:
name acb
revision 1
instance 1 vlan 1-4094
spanning-tree mode mst
spanning-tree mst 0-1 priority 28672
juniper> show configuration protocols mstpДля eltex mes тоже можно настроить аналогично циске
configuration-name abc;
revision-level 1;
bridge-priority 28k; #это приоритет для cist
msti 1 {
bridge-priority 28k; #это приоритет для msti
vlan 1-4094;
}
spanning-tree mode mstДля extreme network я пробовал настроить при тестировании x430 и, к сожалению, такую конструкцию реализовать не получилось, так как в инстанс там добавляются только созданные на коммутаторе вланы.
spanning-tree priority 28672
spanning-tree mst configuration
instance 1 vlan 1-4094
name abc
revision 1
exit
spanning-tree mst 1 priority 28672
Регион создавать один на всю сеть, да и то только по той причине, чтобы была возможность установки такого коммутатора в любую точку сети без переконфигурации. Никакой выгоды от нескольких регионов нет.
Не следует злоупотреблять большим количеством инстансов. Мне попадались коммутаторы, в котором их можно было создать максимум штук 8.
Альтернативы протоколу spanning-tree
G.8032 Ethernet Ring Protection (ERP) protocol описанный в стандарте ITU-T G.8032 является хорошей альтернативной stp. И ERPS, и CFM можно найти у extreme network, даже у eltex, не говоря уже о многочисленных китайских поделках, но у циски почему-то это есть только в metro-серии. Так что имеет ли смысл далее поддерживать этого производителя, обезличивая конфигурации шеститонников для конкурсов "уникальным" функционалом: "поддержка EIGRP" и "возможность запуска отдельного экземпляра RSTP для отдельных vlan"?
Маршрутизация не является альтернативной spanning-tree. Это совсем другая песня.