"Mert a csomagok sosem hazudnak."

MST – PVST+ kompatibilitás

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:

  1. A root bridge az MST domain van
  2. 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”

 

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.