The Good, The Bad and RSTP
Как известно, принципиальным для “быстрой” работы RSTP является наличие point-to-point линка между двумя бриджами. Нужно это чтобы не усложнять схему хендшейка - как только апстрим послал proposal и получил agreement он сразу разблокирует свой designated порт. Существенным является то что даунстрим бридж блокирует свои порты прежде чем дать наверх agreement - нужно это чтобы петли не возникали. Теоретически можно схему хендшейка реализовать на shared линках, только там все уж больно сложно становится.
Так вот главный вопрос был такой. RSTP как известно определяет тип линка по дуплексу. Вполне логично. А если представить что три или более бриджа включаются в другой, который делает QinQ + L2 protocol tunneling? Тогда каждый бридж будет видеть линк как p2p но реально облако между ними будет shared. И как только upsteam получает хоть один agreement он сразу разблокирует свой порт, хотя остальные даунстримы еще могли не синхронизироваться.
Сценарий довольно редкий, но потенциально могущий привести к временным петлям на момент реконвергенции. Впервые мне он пришел в голову когда я подумал о том как Rapid-PVST (= RSTP & PVST+) будет работать когда три RPVST свитча включить в один CST (IEEE 802.1D). PVST+ как известно туннелирует все non-VLAN 1 STP через CST регион, интерпретируя его как один линк. При этом может возникнуть тот же сценарий что и выше с QinQ - три бриджа думают что между ними P2P линк.
Если собрать небольшую лабу и прогнать дебаги то в общем-то видно что ничего особо страшного не происходит - agreement приходят от всех даунстримов но апстрим реагирует только на первый. К чему это может привести в продакшне сказать сложно. Но просто лучше избегайте таких сценариев (P2P завсегда лучше для Ethernet), да и вообще не балуйтесь растягиванием L2 доменов :)
PS
На закуску - очередная статейка из категории - “Making Ethernet Scalable, even though nobody asks for that” http://100x100network.org/papers/myers-hotnets2004.pdf
Так вот главный вопрос был такой. RSTP как известно определяет тип линка по дуплексу. Вполне логично. А если представить что три или более бриджа включаются в другой, который делает QinQ + L2 protocol tunneling? Тогда каждый бридж будет видеть линк как p2p но реально облако между ними будет shared. И как только upsteam получает хоть один agreement он сразу разблокирует свой порт, хотя остальные даунстримы еще могли не синхронизироваться.
Сценарий довольно редкий, но потенциально могущий привести к временным петлям на момент реконвергенции. Впервые мне он пришел в голову когда я подумал о том как Rapid-PVST (= RSTP & PVST+) будет работать когда три RPVST свитча включить в один CST (IEEE 802.1D). PVST+ как известно туннелирует все non-VLAN 1 STP через CST регион, интерпретируя его как один линк. При этом может возникнуть тот же сценарий что и выше с QinQ - три бриджа думают что между ними P2P линк.
Если собрать небольшую лабу и прогнать дебаги то в общем-то видно что ничего особо страшного не происходит - agreement приходят от всех даунстримов но апстрим реагирует только на первый. К чему это может привести в продакшне сказать сложно. Но просто лучше избегайте таких сценариев (P2P завсегда лучше для Ethernet), да и вообще не балуйтесь растягиванием L2 доменов :)
PS
На закуску - очередная статейка из категории - “Making Ethernet Scalable, even though nobody asks for that” http://100x100network.org/papers/myers-hotnets2004.pdf