Tag Archives: pvst

Spanning Tree PVID- and Type-Inconsistencies

M-am ciocnit de curând cu o problemă in care două switch-uri Ethernet refuzau să se înțeleagă unul pe celălalt. Imaginați-vă scenariul in care aveți un switch în companie, pe care îl administrați și pe care încercați sa-l interconectați cu un alt switch, sa-i zicem al unui furnizor de servicii, pe a cărui configurație nu o cunoașteți și nu aveți cum s-o schimbați. Ambele switch-uri sunt Cisco. Problema e că în anumite configurații pe switch-ul companiei comunicațiile prin respectivul interconect se întrerup, în plus uneori consola switch-ului mai și afișează mesaje cu STP inconsistencies. Până la urmă problema sa dovedit a fi de fapt un regim normal de funcționare a switch-urilor și reprezintă o funcție specifică a STP-ului prin care porturile între switch-uri sunt blocate în caz că există diferențe in configurația acestora. De exemplu în cazurile când pe un trunk dot1q, pe capete, nu coincid VLAN-urile native sau un port în trunk este interconectat cu un altul configurat ca acces mode. Ca să înțeleg mai bine respectivele procese am încercat să modelez situația intr-un laborator pe GNS3. Mai jos vedeți un intro teoretic și observațiile din lab.

Despre STP și tip-uri de STP

Fără a intra în discuții lungi legate de protocolul STP cred ar fi interesant să reamintesc doar că acesta este implementat pe toate switch-urile Ethernet și că are grijă să evite formarea buclelor logice într-o rețea cu bucle fizice, or orice rețea cu redundanță formează inevitabil bucle fizice. O buclă într-o rețea e nocivă pentru performanța acesteia dacă nu chiar distructivă și trebuie evitată cu orice preț. STP-ul e un protocol în continuă evoluție așa că în timp au existat mai multe variații, unele standarde IEEE, altele versiuni Cisco proprietary. Să revizuim cele mai importante din ele: 

  • STP-ul tradițional, descris in standardul IEEE 802.1D, minimum pe un switch Ethernet, o singură instanță pentru toate VLAN-urile pe switch (MST – Mono Spanning Tree). Pe un switch Cisco, regim implicit pe porturile configurate in mode acces.
  • Per-VLAN STP (PVST), Cisco proprietary, cu instanțe STP separate pe fiecare VLAN activ, funcționează doar pe trunk-uri Cisco ISL. Pe un switch Cisco, regim implicit pe porturile configurate ca trunk-uri ISL.
  • Per-VLAN STP (PVST+), identic cu PVST dar funcționează și pe trunk-uri 802.1q. Pe un switch Cisco, regim implicit pe porturile configurate ca trunk-uri 802.1q.
  • Rapid STP (RSTP), standard IEEE, varianta îmbunătățită pentru STP-ul tradițional 802.1D, oferă un timp de convergență mai rapid. Incorporat în 802.1D.
  • Rapid-PVST+, Cisco proprietary, varianta rapidă pentru instanțele PVST+
  • Multiple STP (MSTP), standard IEEE, evoluție STP/RSTP, permite crearea mai multor instanțe STP pe același switch, mai multe VLAN-uri pot fi asociate cu aceeași instanță MSTP.

Despre VLAN 1 și native VLAN pe un trunk dot1q

VLAN-ul cu ID-ul 1 există pre-creat pe orice switch Cisco Catalyst, nu poate fi șters și are o semnificație aparte. Pe switch-urile Cisco, VLAN 1 e folosit pentru transportul mesajelor unor protocoale de control și ca VLAN nativ in configurația implicită a unui trunk dot1q. Următoarele protocoale folosesc VLAN 1 pentru transportul propriilor mesaje: (1) CDP, (2) VTP, (3) DTP, (4) PAgP. Mesajele DTP au specificul că sunt transportate întotdeauna untagged, prin VLAN-ul nativ, care pe un trunk dot1q in configurația sa implicită coincide cu VLAN-ul 1. Celelalte protocoale folosesc VLAN 1 indiferent dacă e nativ sau nu pe trunk. În caz că nu e nativ, acestea vor fi încapsulate in frame-uri tagged (marcate cu VLAN 1). Pe un switch Cisco Catalyst, STP-ul schimbă mesaje pe toate VLAN-urile admise în trunk, inclusiv și pe VLAN-ul 1.

În acest context, de obicei, recomand studenților mei următoarele două practici: (a) să nu folosească în nici un fel VLAN-ul 1 pentru transportul de date și (b) să schimbe VLAN-ul nativ implicit din VLAN 1 într-un oarecare alt VLAN ID. VLAN-ul 1 cât și noul VLAN nativ să rămână rezervate exclusiv pentru protocoale de control.

Despre mesaje PVST+ BPDU

Funcționarea protocolului STP (PVST+) se bazează pe un schimb continuu de mesaje intre switch-urile topologiei de rețea. Mesajele STP sunt numite mesaje BPDU (Bridge Protocol Data Unit) și sunt folosite de switch-uri pentru stabilirea arborelui de Spanning Tree. Din arbore se deduc porturile pentru a fi deconectate astfel încât să se excludă formarea buclelor L2. În variantele per-VLAN a STP-ului (PVST/PVST+), grupuri de mesaje BPDU sunt transmise pentru fiecare instanță/VLAN de STP.

Următoarele reguli se respectă la transmiterea mesajelor BPDU PVST+ pe un trunk 802.1q: 

  • Pentru VLAN-ul nativ, switch-ul va transmite mesaje BPDU in formatul STP-ului clasic, untagged și pe o adresa MAC rezervată STP-ului: 0180.c200.0000 (IEEE STP MAC).
  • Pentru VLAN-ul nativ, switch-ul va dubla fiecare mesaj din punctul precedent cu BPDU-uri in format PVST+, transmise untagged și pe o adresă MAC rezervată protocolului PVST+ 0100.0ccc.cccd. Acestea mai sunt numite mesaje SSTP (shared spanning tree). Diferența dintre un mesaj clasic STP și PVST+ este într-un field adițional de tip TLV (PVID) adăugat la capătului BPDU-ului. Field-ul TLV indică numărului VLAN-ului căruia îi aparține mesajul BPDU. TLV-ul e în format pe 3x octeți: (a) type – întotdeauna zero (b) length – întotdeauna 2 și (c) value – respectiv numărul VLAN-ului.
  • Pentru restul VLAN-urilor active, switch-ul va transmite mesaje in format PVST+, tagged cu numărul VLAN-ului și cu destinație pe adresa MAC rezervată protocolului PVST+ 0100.0ccc.cccd.

BPDU-urile menționate în primul punct sunt de format STP și pe o adresa destinație STP tocmai pentru a asigura compatibilitatea intre un switch Cisco cu PVST+ și un switch clasic IEEE ce funcționează pe o singură instanță STP. O instanță STP (MST) pe un switch IEEE se asociază cu instanța STP a VLAN-ului nativ pe un switch PVST+ într-un așa numit domain CST (Common Spanning Tree).

BPDU-urile SSTP au rolul de a detecta diferențele dintre configurațiile porturilor pe capetele unui trunk, mai precis deosebiri dintre numărul VLAN-ului nativ. Diferențele intre VLAN-urile native la capetele unui trunk duc pe deoparte la apariția fenomenului de VLAN hopping (frame-urile dintr-un VLAN sar intr-un alt VLAN) și pe de altă parte împiedică funcționarea corectă a STP-ului pe acele VLAN-uri, fapt ce poate provoca instabilități și bucle. Din moment ce un switch Cisco  recepționează un mesaj SSTP pe unul din porturile sale trunk, acesta va compara valoarea din TLV (PVID) cu VLAN-ul nativ configurat pe respectivul port, daca acestea nu coincid portul va fi trecut in statut inconsistent și blocat pentru forwarding de frame-uri.

BPDU-urile SSTP sunt intenționat asamblate în frame-uri cu o adresă destinație rezervată PVST-ului. Scopul e ca într-o topologie mixtă cu switch-uri IEEE și switch-uri Cisco cu PVST+ mesajele BPDU SSTP să treacă neconsumate de STP-ul din switch-ul IEEE. Dacă SSTP-ul ar avea o destinație IEEE STP MAC atunci acesta s-ar fi oprit pe primul switch IEEE fiind consumat de procesul lui STP (de fapt interpretat ca o dublură la BPDU-ul STP inițial).

STP_inconsistencies_stp_sstp_pvst_diagram

Spanning Tree PVID- and Type-Inconsistencies

Să încercăm acum să confirmăm afirmațiile de mai sus într-o topologie pe lab. Pentru simplitate vom folosi GNS-ul in care vom porni routere Cisco configurate cu module Etherswitch. Spre norocul nostru, Etherswitch-urile pe routere Cisco in GNS suportă Spanning Tree-ul și încă în varianta PVST+.

Așadar, pe un router Cisco 3600 cu Etherswitch (NM-16ESW) configuram VLAN-urile și una din interfețe în regim de trunk 802.1q. Pe trunk, re-configurăm VLAN-ul nativ din 1 într-un alt VLAN, de exemplu in VLAN 5. Din lista de dispozitive, aducem un switch sintetic (Ethernet Switch) pe care il conectam cu un port al său la trunk-ul pe Etherswitch – o facem pentru a ține interfața trunk întotdeauna up/up. Vedeți mai jos, topologia și configurația pe router.

STP_inconsistencies_lab_diagram

Acum e cazul să pornim wireshark-ul pentru o captură de pachete pe segmentul R1-Fa0/0 – SW1-1. Vedeți mai jos screen-ul cu rezultate. Din captură se observă clar cum Etherswitch-ul transmite un BPDU STP, untagged pe adresa STP-ului (pachet 1), după care dublează mesajul cu un BPDU PVST+, untagged pe adresa PVST+ și PVID=5 (pachet 3, marcat și desfășurat) și câte un BPDU pentru fiecare VLAN activ pe switch, inclusiv VLAN=1, in format PVST+ cu PVID-ul și tagg-ul 802.1q corespunzător VLAN-ului. 

STP_inconsistencies_stp_sstp_pvst_wireshark_captured

Să încercăm acum să extindem topologia din GNS3 prin a adăuga încă un router Cisco cu modul Etherswitch pe care îl vom interconecta cu primul printr-un link. Vom verifica acum reacția switch-urilor (Etherswitch) la următoarele divergențe în configurația porturilor ce le interconectează (de la R1 la R2):

  • Trunk (native 1) to Acces (VLAN 1)
  • Trunk (native 1) to Acces (VLAN 5)
  • Trunk (native 1) to Trunk (native 5)
  • Trunk (native 5) to Trunk (native 5)

Primele două cazuri dau același rezultat, port-ul access pe router-ul R2 este blocat iar in consola se afișează mesajul cu Inconsistent port type ..

STP_inconsistencies_access_mode_syslog_message_case_a

sau pentru cazul doi (diferența e doar in numărul VLAN-ului)

STP_inconsistencies_access_mode_syslog_message_case_b

din acest moment port-ul e blocat pentru comutație de frame-uri. Statutul poate fi verificat cu show spanning-tree summary din care se aflăm numărul de port-uri blocate per VLAN și show spanning-tree inconsistent ports din care găsim portul blocat.

STP_inconsistencies_access_mode_blocked_status

Rezultatul ne re-confirmă un regim normal de funcționare prin care port-urile configurate in mod acces sunt blocate automat în cazul în care primesc mesaje BPDU pe adresă SSTP or un așa mesaj poate fi primit doar dacă la capătul opus se află un port configurat in mod trunk. Porturile se blochează doar pe partea acces nu și pe trunk.

De menționat că există o excepție la regulă și poate fi observată doar pe switch-urile Catalyst – testat personal pe switch-uri reale. Pentru cazul când VLAN-ul nativ pe portul trunk coincide cu VLAN-ul pe interfața acces și ID-ul VLAN-ului este 1, portul totuși nu este blocat.

Să trecem la al treilea caz cu interfețe in trunk pe ambele capete dar cu configurații diferite pentru VLAN-ul nativ. Din moment ce unul port-uri este pornit, STP-ul pe ambele switch-uri reacționează și blochează porturile pentru amândouă VLAN-uri native. 

STP_inconsistencies_access_mode_syslog_message_case_trunk_to_trunk

ambele port-uri pe amândouă VLAN-uri sunt blocate:

STP_inconsistencies_access_mode_syslog_message_case_trunk_to_trunk_inconsisten_ports

Acum, dacă e să modificăm VLAN-urile native pe porturile trunk astfel încât să coincidă (al patrulea caz) vom observa cum porturile pe VLAN-urile respective se vor debloca automat.

Pe final, câteva referințe care pentru mine s-au dovedit a fi extrem de utile:

  1. blog.ine.com – PVST+ Explained (link)
  2. cisco.com – Troubleshooting Spanning Tree PVID- and Type-Inconsistencies (link)
  3. cciethebeginning – Differences between PVST and PVST+ (link)
  4. PVST+ BPDU frame format (link)
  5. InformIT – CCNP Practical Studies (link)