Tag Archives: stp

What can happen if unexpected switch is inserted into network ?

It’s interesting to notice how one of the most used protocol in LANs STP (Spanning Tree Protocol) is so weak from a security standpoint. What I want today is to put a simple test scenario build in a Packet Tracer lab that illustrate what can happen if by mistake (or by an informed hacker) and some specific switch configuration a new switch is introduced into an existing network. Let assume the network topology illustrated in picture below (a screen taken from a running simulation in Packet Tracer apps). As can be seen, the topology is based on Cisco’s layered model with dedicated switches for network core and distribution/access (actually a particular case with distribution and access layers collapsed in a single one). Usually, switches used in core are more powerful in term of performance than other – these should have sufficient capacity to switch all aggregated traffic between network modules interconnected by core (in our simple topology the network core connect user’s access switch with data center distribution/access module). The network is fully redundant and protected from single-point-of-failure – there are redundant paths as well as spare switches. As a result of redundancy the network topology inevitably forms physical loops, which without a proper handling are translated in a logical loops. As is known, logical loops ca be detrimental for network performance and operations (if not completely destructive). In such a condition, once caught, a broadcast frame will spin endless in closed loop, more, they will tend to accumulate and form what is known as a broadcast storm (in typical size network is a matter of seconds, even just by ARP requests). As a result of storm, broadcast traffic will eat precious switch/link bandwidth resources leaving less (or nothing) for legitimate traffic. Above that, other negative effects of loops are: MAC address table entries flapping, occurrence of duplicate unicast frames, flooding connected end-nodes with looped broadcast and others. 

What can happen if unexpected switch is inserted to network-networkdiagram

The role of STP protocol is to prevent logical loops creations by ensuring one logical path in a network with multiple physical paths. The STP protocol will intentionally block all off the redundant paths that could cause a loop and in case of active path failure will dynamically react by re-activating (put in forwarding state) of some previously blocked paths. The STP is a distributed protocol, which run on all switches and that use a special format frames named BPDU (Bridge Protocol Data Units) for inter-switch coordination. The logic of STP is based on following two steps: (a) a root bridge (master switch) election and (b) a spanning tree algorithm (STA) running in determination what paths should be open for forwarding and what should be left blocked. Election of Root Bridge take place by comparing bridge priority together with switch MAC address of each switch involved in a specific STP instance (values are exchanged by BPDU messages). The switch with lower value Priority/MAC will win the election. The bridge priority, is a configurable parameter and by default has the value of 32768 on all switches, if not changed in advance the only factor that influence the root bridge election remain switch MAC address. Usually, an administrator will involve and change bridge priority in such a way that a specific switch can be designated as a Root Bridge – normally one of the core switches (more on why those will come). In second stage, the STA on every switch will calculate the cost of each logical path to the root bridge, select the path with least cost and use that path for traffic forwarding, other paths that do not form a best way to Root Bridge for other switches are left in blocking state. Path costs are calculated as a sum port cost consecutive to the root bridge. Port costs is based on values predefined by IEEE standard for each possible Ethernet bandwidth (e.g. 100Mbps have a port cost of 19, 1GbE cost of 4, lower speed higher cost).

In our topology, we can already observe the results of STP protocol actions: some links are active (ports on both ends are in forwarding state, shown by green circle) and some other links are blocked (one port at one of the end of link are leaved in blocked state shown by orange color circle). In that state, there are no any of L2 logical loops. Let’s try to explain how STP did that. If briefly:

  • One of the core switches (in picture from left) are designated as a Root Bridge. That was done by setting a lower (245776) bridge priority than the default value of 32768. Without that, Root Bridge can become any of switches from the topology (actually that with lower switch MAC address table). For backup purposes, the other core switch is configured with a bridge priority (28672) greater than first switch but lower than default value. In case of primary core switch failure the second core switch will gain (trough STP election) the Root Bridge role. The Root Bridge role assignment and configured bridge priority value can be checked from the output of show spanning-tree privileged mode command (see picture below, show command on SW1).
  • Every switch in topology will calculate the cost of every path leading to the Root Bridge switch and choose the least cost one as a forwarding path. It can be seen by one active path from every switch to root bridge (e.g. for SW3 F0/2 to F0/2 on SW1). Not for this topology, but in case of multiple paths with the same cost the STP algorithm will choose the path that begin with a port whose port_priority/port_ID is lower. The path cost can be viewed from the output of show spanning-tree command (in picture below see at show command for SW3).
  • For the remaining physical links, switches at both ends will negotiate who will leave the port in blocked state (switch with higher Bridge ID). On a link, only one end is leave blocked while the other end is always is passed in forwarding state. See proof on topology screen, here, none of physical links blocked at both ends at the same time. Let’s see for example what happens on the segment between SW3 and SW4, here, SW4 have a lower Bridge ID than SW3 therefore this one will pass his port ]n forwarding state (F0/4). Given that bridge priority of both switches are the same (default value of 32768) result that the factor that make difference when comparing Bridge Priority is MAC addresses – SW4 have a MAC address lower than that of SW3.

What can happen if unexpected switch is inserted to network-show spanning tree output

If now, we will re-draw the topology so that only active paths are shown then a nice tree (hence the term Spanning Tree) can be observed (picture below, left side). As can be seen all traffic flows are aggregated in one of core switch. 

What can happen if unexpected switch is inserted to network-spanning trees

If now, intentionally or by mistake, a new switch with a lower than existed bridge priority is inserted then a suboptimal STP topology can form. Let’s suppose that the new switch with pre-configured bridge priority of 20480 (lowest in topology) is connected directly to SW3. In that case, after STP re-calculation, a new root bridge will be elected (that new switch) and another active/blocked links topology will be established. If compare this topology (shown in picture below) to initial one then differences are obvious. As show in previous picture (right side) all the traffic are now aggregated in SW3 – a switch that is less powerful than the core switches, so a inevitable bottleneck point will occur in this network.

What can happen if unexpected switch is inserted to network-networkdiagram after new switch added

If to look at cost of path from SW3 to root bridge then, now, it become more expensive, which means that path is crossing along more ports. In show spanning-tree command, the value of 57 added by 3 time cost of FastEthernet port (19 as of IEEE standard).

Obviously such scenarios should be avoided. There are techniques like BPDU guard/filter that once configured can automatically block the ports or cancel any BPDU swapping toward such unexpected switches, but this is a subject for another post so enough for today.

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).


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.


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. 


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 ..


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


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.


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. 


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


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)

Particularități comutație pe switch-uri virtuale VMware.

Un switch virtual implementat pe un host de virtualizare VMware în mare parte operează asemănător ca și un switch fizic de Ethernet. În esență, acesta se supune aceluiași model de transparent bridging pe baza căruia funcționează toate switch-urile clasice de Ethernet. Totuși, există și particularități care fac diferențe în funcționare și implementarea de virtual networking. Mai multe despre acestea în textul de mai jos.

Pre-popularea tabelului adreselor MAC

Un switch virtual ca și un switch fizic operează cu același tabel a adreselor MAC. Tabelul adreselor MAC face legătura între portul in care se conectează un nod și adresa MAC a acestuia și e folosit de switch pentru comutația selectivă a cadrelor Ethernet. Pe un switch fizic tabelul adreselor MAC pornește gol completându-se  treptat prin procesul de learning – cadrele Ethernet sunt investigate pentru adresa MAC sursă care se înregistrează ulterior in tabelul adreselor MAC. Interesant e că un switch virtual nu are nevoie de learning-ul adreselor MAC. Datorită faptului că switch-ul virtual aparține aceluiași sistem (hypervizor) împreună cu nodurile conectate în el (mașinile virtuale) devine posibilă pre-popularea din start a tabelului cu adrese MAC – switch-ul virtual știe de la bun început ce mașini virtuale în ce porturi sunt conectate. De aici rezultă că pe un switch virtual nu mai are loc procesul de unicast flooding care pe un switch fizic se întâmpla până la popularea completă a tabelului adreselor MAC. Mai puțin flooding de rețea duce la un overhead mai mic pe VM-uri. La fel, pre-popularea tabelului MAC practic fac imposibile atacurile de tip MAC flooding, un switch virtual fiind protejat prin design împotriva unor astfel de amenințări.

Mecanism intrinsec pentru prevenirea formării buclelor de rețea

O rețea pe switch-uri virtuale exact ca și o rețea pe switch-uri fizice are nevoie să fie tot timpul disponibilă. Cerința de disponibilitate pentru switch-uri virtuale e cu atât mai mare cu cât numărul serviciilor găzduite in VM-uri și care depind de networking e foarte mare datorită factorului de consolidare înalt – e suficient să rupi uplink-ul unui switch virtual ca să pierzi comunicațiile externe pentru toate VM-urile conectate in acel switch. Exact ca și pentru o rețea pe switch-uri fizice în virtual networking disponibilitatea înaltă se asigură prin redundanța componentelor din care face parte. Redundanța se introduce pentru a exclude fenomenul de Single Point of Failure (SPOF). Într-o rețea fizică redundanța este implementată prin dublarea switch-urilor și a link-urilor între switch-uri, de cealaltă parte, în virtual dublarea are sens doar pentru componentele fizice ale rețelei – nu sunt dublate switch-urile sau/și conexiunile la VM-uri ci doar uplink-urile la rețeaua fizică. Uplink-urile reprezintă unicele componente fizice care teoretic pot să cadă, restul reprezintă structuri in software ce nu au cum să se defecteze.

Redundanța într-o rețea duce inevitabil la formarea buclelor. De regulă switch-urile întrerup buclele prin protocolul STP. Cum nu ar părea de straniu un switch virtual nu are implementat protocolul de spaniing tree (STP). Ceea ce face ca switch-ul virtual sa lupte cu formarea buclelor este specificul comutației cadrelor Ethernet de pe un uplink pe alt uplink. Din acest punct de vedere porturile in care sunt conectate VM-urile și cele de uplink diferă un pic, ultimele abătându-se de la logica unui bridge transparent tradițional.

Ceea ce face posibilă implementarea regulilor specifice pentru comutația pachetelor pe uplink-uri este principiul prin care un switch virtual nu va fi folosit niciodată pentru tranzitarea frame-urilor de pe un uplink pe alt uplink. Uplink-urile sunt folosite exclusiv pentru comunicațiile cu exteriorul a mașinilor virtuale conectate în acel switch virtual. E de la sine înțeles că astfel reguli nu pot fi implementate pe switch-uri fizice din simplu motiv că pe acestea nu poți limita tranzitarea traficului de pe un port pe alt port pentru ca nu ai de unde să știi din timp despre destinația în practică a porturilor.

În ilustrația de mai jos frame-ul (de culoare verde) pornit din switch-ul fizic (stânga) prin uplink către switch-ul virtual nu va fi comutat niciodată pe celălalt uplink – și nici nu are nevoie, daca e un frame destinat VM-ul acesta va fi comutat către VM alte frame-uri neavând dreptul să tranziteze switch-ul.  


Nefiind conștient de protocolul STP switch-ul virtual ignoră mesajele BPDU venite de pe switch-urile fizice. Ca practică corectă se recomandă deconectarea STP-ului pe porturile pe switch-urile fizice ce duc spre switch-ul virtual, altfel spus configurate în regim Port Fast. Din moment ce nu există riscul formării buclelor printr-un switch virtual nu mai e nevoie de STP. În plus, fără STP portul pe switch-ul fizic se ridică imediat fără a trece prin fazele lungi până la starea de forwarding ale protocolului STP. O recomandare in plus este activarea BPDU guard pe porturile spre switch-ul virtual, mai ales pe medii in care guest-os-ul nu este controlat de owner-ul infrastructurii și din care se pot origina mesaje BPDU rău intenționate.

Alte particularități

Alte particularități ce țin de comutația pachetelor prin porturile uplink pe un switch virtual:

  • cadrele broadcast generate in VM-uri vor fi comutate pe extern doar printr-un singur uplink nu și peste restul uplink-urilor din team. Uplink-ul este decis de regimul de load balancing setat în politica de teaming. În ilustrația de mai jos (pe stânga) pachetul broadcast generat in primul VM pe stânga este comutat pe restul VM-urilor și pe unul din uplink-uri.
  • broadcast-ul venit de pe un uplink nu va fi comutat pe celelalte uplink-uri din team. În ilustrația de mai jos (pe stânga) pachetul broadcast intrat pe uplink-ul din dreapta este comutat către toate VM-urile din grup nu și pe celelalte uplink-uri din team.


  • frame-urile unicast unknow  (frame-uri pentru extern) vor fi comutate doar pe unul din uplink-urile din team. Care uplink, depinde de decizia mecanismului de load balancing setat pe team. În ilustrație (pe dreapta) frame-ul generat de VM pe un MAC ce nu aparține VM-urilor este comutat pe primul uplink din team. De remarca ca unicast unknow de regula nu ajung la alte VM-uri – doar daca portul nu e configurat ca promiscous mode. În general lipsește fenomenul de flooding cu frame-uri unicast unknow.
  • frame-urile intrate pe uplink cu o adresa MAC destinație alta decât una din adresele VM-urilor vor fi ignorate de către switch-ul virtual. In ilustrație (pe dreapta) frame-ul cu MAC necunoscut este ignorat de switch-ul virtual.
  • un frame generat de un VM ieșit printr-un uplink pe extern nu va fi acceptat dacă se va re-întoarce pe un alt uplink. Mecanismul se mai numește Reverse Path Check și blochează orice frame intrat pe uplink a cărui adresa MAC sursă coincide cu adresa unui VM de-al lui. Pe desen (pe dreapta) frame-ul generat de un VM, scos prin primul uplink și reîntors pe alt uplink nu va mai fi acceptat de switch-ul virtual.

Regulile de comutație specifice pentru uplink-urile pe un switch virtual mai sunt numite și reguli de split horizont forwarding.