Bevezető
A Spanning-Tree szerintem tipikusan egy olyan téma amit sok ember alül becsül. Beteszel egy új switchet a hálózatba, nem is gondolsz rá hogy melyik eszköz a root bridge az adott VLAN(ok)-ban, az STP teszi a dolgát. Ha viszont valamiért nem működik, akkor letérdel az egész hálózat, és ember legyen a talpán aki megtalálja hogy melyik link vagy eszköz okozza a hibát. Legvégső esetben meg kell törni a loopot (letiltani/kihúzni minden olyan kábelt amely miatt fizikai redundancia van a hálózatban). Nem véletlen tehát, hogy ez a protokoll nem túl népszerű, tűzzel-vassal irtják és minden design dokumentációban már a routed access a javasolt megoldás.
De mi van akkor, ha hozzá kell nyúlni, sőt tovább megyek, PVST+ domain-t kell MST-vel összekapcsolni?
Nézzük az alábbi topológiát. Felül az MST domain, alul a PVST+ látható.
Az MST és PVST+ protokollok természetesen kompatibilisek egymással. Ahhoz viszont hogy a pontos működést megértsük, meg kell vizsgálnunk a BPDU üzenetek cserélésének módját.
PVST+ STP verziónál:
- a native VLAN-ban IEEE és Cisco BPDU is küldésre kerül. Előbbi biztosítja, hogy nem Cisco eszköz esetében is garantált legyen a loop-free topológia, hiszen ez szabvány és minden switch “érti”. Utóbbi segítségével PVST+ topológia vihető át nem Cisco hálózat felett is, hiszen a nem Cisco switch-nek ezek L2 multicast üzenetek, amelyeket feldolgozás nélkül továbbít.
- Minden nem native VLAN-ban Cisco BPDU kerül kiküldésre.
Ezt láthatjuk az alábbi pcap-ben is. A switchen az 1,10,20,30 VLAN-ok léteznek.
Vegyük észre, hogy a native VLAN-ban két BPDU van, egy “PVST+” (destination MAC: 01:00:0c:cc:cc:cd) és egy “Spanning-tree-(for-bridges)_00 (01:80:c2:00:00:00)”, a többiben viszont csak egy BPDU küldése történik meg.
MST esetében egy dedikált instance (MSTI0) van kijelölve a BPDU cserére, hiszen VLAN-okat instance-hoz mappelünk, ezért nincs minden VLAN-ban BPDU küldés, az MSTI0 a teljes topológiát írja le (M-Recordok segítségével). Pont ez a lényeg, hogy véges számú topológia létezik, miért futtatnánk mindegyikre külön instance-t (és küldenénk BPDU-t).
Nézzük az alábbi konfigurációt:
spanning-tree mode mst spanning-tree mst configuration name fkuris revision 1 instance 1 vlan 1-4094
A pcap-ben látjuk, hogy csak a native VLAN-ban van BPDU csere, és M-recordban kerül leírásra az instance-vlan mapping (ezt pontosan nem látjuk, mert hashként kerül kiküldésre).
Ha eddig elolvastad és még nem adtad fel, akkor jöhet a mélyvíz!
MST-PVST+ domainek között úgy működik a kommunikáció, hogy az MST-ben a border switch(ek)
- MST -> PVST+ irányba minden VLAN-ba küld PVST+ BPDU-t
- PVST+ -> MST irányban ellenőrzi, hogy a VLAN1 és a többi VLAN prioritása egyezik -e (PVST Simulation). Ez utóbbi kritikus fontosságú, mert nem lehet olyan állapot, hogy egyik VLAN-ban a PVST domainben van a root, másikban pedig az MST-ben.
A root bridge helye kulcskérdés. Nyilván két eset lehetséges:
- A root bridge az MST domain van
- A root bridge a PVST+ domain-ben van
Az első lehetőség egyszerűbb. Az MST domainben az egyik switch prioritása alacsonyabb mint bármelyik másiké a PVST+ tartományban, teljesen úgy működik minden ahogy gondoljuk.
A második már jóval problémásabb. Ennek oka, hogy az MST domain border eszközei a fent leírtaknak megfelelően fordítják a BPDU-kat. Garantálni kell, hogy ha a root bridge a VLAN1-ben a PVST+ domainben van, akkor minden VLAN-ban a root bridge ott kell, hogy legyen. Miért? Mert értelemszerűen nem lehet olyan helyzet, hogy az adott interface a VLAN1-re FWD, VLAN2-re blocking, mivel MST-ben nem per-VLAN STP-t használunk.
A fontos szabály az, hogy VLAN1 root bridge a PVST+ domain-ben van, és minden egyéb VLAN prioritása annál kisebb legyen. Azaz ha VLAN1 priority 8192, akkor VLAN2-4094 (vagy az allowed VLAN lista) legyen 4096 vagy 0. Hogy miért nem lehet egyenlő (csak kisebb) arra később visszatérünk.
A mi topológiánkban SW1 és SW2 is “border” eszköz, azaz mindkettő végez MST-PVST+ BPDU fordításokat.
A prioritások így vannak beállítva (minden VLAN-ra):
SW1: 24576
SW2: 28672
SW3: 4096 (root)
SW4: 8192
Mi következik ebből: a root a PVST+ domainben van (SW3), de VLAN1 prioritása megegyezik az összes többiével (4096). Ezért az MST switcheken ún. “PVST Inconsistent” állapotba mennek a portok.
*Apr 20 18:39:52.854: %SPANTREE-2-PVSTSIM_FAIL: Blocking root port Et0/1: Inconsitent inferior PVST BPDU received on VLAN 10, claiming root 4106:aabb.cc00.3500 SW1#
SW1#sh span vl 10
MST1
Spanning tree enabled protocol mstp
Root ID Priority 24577
Address aabb.cc00.1500
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 24577 (priority 24576 sys-id-ext 1)
Address aabb.cc00.1500
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Et0/0 Desg FWD 2000000 128.1 Shr
Et0/1 Mstr BKN*2000000 128.2 Shr Bound(PVST) *PVST_Inc
SW1#
És akkor térjünk vissza arra a kérdésre, hogy miért kell hogy VLAN2-4094 prioritása kisebb legyen (nem egyenlő)? A válasz rendkívül egyszerű: a “priority” a konfigurált prioritás és VLAN ID (MST-nél az instance ID) összege. Mivel VLAN1 és VLAN2 esetén az értékek 4097 (4096+1) illetve 4098 (4096+2) ezért csak a kisebb prioritás elégíti ki a feltételt.
VLAN10 esetében ez “4096+10 = 4106”, ahogy a logban látjuk is.
*Apr 20 18:39:52.854: %SPANTREE-2-PVSTSIM_FAIL: Blocking root port Et0/1: Inconsitent inferior PVST BPDU received on VLAN 10, claiming root 4106:aabb.cc00.3500
Nézzük mi történik, ha a root switchen (SW3) teljesül a feltétel, VLAN2-4094 prioritását kisebbre vesszük (esetünkben 0-ra)? A STP működés helyreáll.
SW3(config)#spanning-tree vlan 2-4094 priority 0
SW1# *Apr 20 18:43:13.471: %SPANTREE-2-PVSTSIM_OK: PVST Simulation inconsistency cleared on port Ethernet0/1. SW1#
SW1#sh span vl 10
MST1
Spanning tree enabled protocol mstp
Root ID Priority 24577
Address aabb.cc00.1500
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 24577 (priority 24576 sys-id-ext 1)
Address aabb.cc00.1500
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Et0/0 Desg FWD 2000000 128.1 Shr
Et0/1 Mstr FWD 2000000 128.2 Shr Bound(PVST)
SW1#
Fontos megjegyzés még, hogy a trunkon hiába nem a VLAN1 a native, akkor is annak az értékét nézi az algoritmus.
A critical concept to understand is that only the Institute of Electrical and Electronics Engineers (IEEE) BPDU for VLAN 1 is processed for the root bridge election. This is compared to only the instance 0 information from the MST region. No other instance information is used in order to elect the root bridge for CIST. No other VLAN information from the PVST+ domain other than VLAN 1 is used in order to elect the CIST root bridge.
Ez különösen “kellemetlen” lehet olyan hálózatokban, ahol a trunkon (best practise alapján) nem a VLAN1 a native, azt gyakorlatilag nem is használják. Mégis ennek a VLAN-nak a prioritása határozza meg a teljes STP topológiát és ahhoz képest kell állítani az összes többi értékét…
Konklúzió
PVST+ (vagy RPVST, de ez esetben MST oldalon PVST+-ként kerül kezelésre az interface, elveszítjük a RPVST előnyeit) és MST összekapcsolásánál kritikus fontosságú, hogy hová kerül a root.
Amennyiben az MST domain-be úgy viszonylag egyszerű a helyzet.
Amennyiben a PVST+-ba kerül a root:
- VLAN1 prioritását úgy állítsuk, hogy root legyen a switch
- VLAN2-4094 prioritását VLAN1 értékénél kisebbre kell állítanunk.
Tehát: “VLAN 2-4094 < VLAN 1 < MST”
