Tag Archives: split horizont forwarding

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.  

vswitch_switching_details_no_need_for_STP

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.

vswitch_switching_details_broadcast

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