Author Archives: Valerian Ceauș

Rețele Private VLAN (PVLAN) – part I

Recentele ore de teorie și laborator dedicate rețelelor Private VLAN m-au cam lăsat cu o groază de notiție pe care ca să nu le pierd în timp cred că am să le expun aici într-un nou articol. Acesta va include o introducere în rețele PVLAN, exemple de utilizare, condiții pentru switch-urile ce tranzitează VLAN-uri private și alte subiecte. Informațiile de aici vor prinde bine pentru un următor articol în care planific să descriu acțiunile din laboratorul dedicat rețelelor PVLAN realizat cu studenții claselor VMware.

Introducere în rețele Private VLAN (PVLAN)

Odată cu apariția VLAN-urilor a devenit posibilă segmentarea unui switch fizic pe mai multe switch-uri logice. Prin interconectarea switch-urilor fizice prin porturi de tip trunk aceleași VLAN-uri (switch-urile logice) pot deja acoperi mai multe switch-uri fizice. Un port trunk, la ieșire, va marca fiecare frame cu numărul VLAN-ului din care a pornit pachetul și la intrare va interpreta numărul VLAN-ului pentru a comuta corect frame-ul pe porturile din respectivul VLAN. Frame-urile pe un trunk 802.1q sunt marcate cu numărul VLAN-ului prin inserarea în header-ul de Ethernet a 4 octeți noi, din care 12 biți sunt rezervați pentru numărul VLAN-ului (VLAN ID). Cu 12 biți dedicați ID-ul VLAN-ului se pot defini până la 4094 de VLAN-uri (de fapt disponibile mai puține datorită câtorva VLAN-uri rezervate: 1,1001-1005). Fiecare VLAN reprezintă un domeniu de broadcast aparte și de regulă se asociază cu un singur subnet de rețea. VLAN-urile sunt complet izolate între ele. Comunicațiile între VLAN-uri pot fi asigurate prin dispozitive L3 cu interfețe în acele VLAN-uri. Introducerea VLAN-urilor simplifică mult topologia fizică a rețelei garantând funcționarea mai multor rețele logice pe același dispozitive fizice (switch) – e ca și cum ai consolida mai multe servere virtuale pe un host fizic doar că aici vorbim de mai multe rețele logice pe un singur switch fizic. Folosirea VLAN-urilor îmbunătățește scalabilitatea rețelei prin localizarea broadcast-ului în domenii de broadcast mai mici și ne oferă o izolare între acestea prin blocarea traficului L2 între VLAN-uri.

Cu toate beneficiile aduse de VLAN-urile tradiționale acestea suferă totuși de câteva neajunsuri:

  • scalabilitate redusă ca număr de VLAN-uri posibile (4094 din care mai trebuie de scos VLAN-urile rezervate).
  • complexitate rețea L3 – fiecare VLAN are nevoie pentru routing de câte o interfață pe un dispozitiv L3 fie el router, firewall sau interfață virtuală pe un switch L3.
  • risipă de adrese IP – pe fiecare subnet asociat cu un VLAN se vor pierde câte două adrese IP una pentru numărul și alta pentru broadcast-ul rețelei. Pe deasupra o adresa IP va fi rezervată pentru default gateway-ul subnet-ului.

Imaginați-vă un scenariu cu hosting de servere virtuale (VPS) în care fiecare client primește un VLAN separat pentru comunicații de rețea. E de înțeles că într-un așa caz numărul maxim de clienți va fi limitat la numărul de VLAN-uri disponibile (din cele 4094 minus câteva ID-uri rezervate mai trebuie scoase VLAN-urile pe care însuși hoster-ul și le-a rezervat, de exemplu pentru networking-ul de management, vMotion, FT ș.a.m.d așa ca numărul la drept vorbind e și mai mic). Sigur, există o problemă de scalabilitate în această abordare.

Rețelele Private VLAN vin să acopere o parte din aceste neajunsuri. Conceptul de Private VLAN se bazează pe ideea restricționării comunicațiilor la nivel de switch între porturi sau grupuri de porturi asociate cu unul din VLAN-urile existente dar care pot în același timp accesa nerestricționat un oarecare grup de porturi dedicat. În porturile restricționate se vor conecta nodurile protejate iar în cele nerestricționate se vor conecta interfețele unor dispozitive partajate în rețea, ca de exemplu interfața router-ului default gateway. Toate nodurile vor fi configurate ca făcând parte din același subnet IP. În așa fel, prin Private VLAN e posibilă o izolare la nivel L2 a dispozitivelor aflate în același subnet IP.

Funcționarea PVLAN-urilor se bazează pe segmentarea unui VLAN standard numit Primary Private VLAN în sub-VLAN-uri auxiliare Secondary Private VLANs. Acestea din urmă sunt posibile de două tipuri: Secondary Isolated Private VLAN și Secondary Community Private VLAN. Într-un Private VLAN pot exista doar un singur Isolated Private VLAN și unul sau mai multe Community Private VLANs. Porturile de acces sunt configurate fie direct în Primary VLAN fie în unul din sub-VLAN-urile secundare. Funcție de VLAN-ul asociat, un port acces în PVLAN poate fi: (a) promiscous port – configurat în Primary Private VLAN (b) isolated port – configurat în Isolated Private VLAN și (c) community port – configurat în unul din Community Private VLANs. Nodurile din VLAN-urile secundare pot comunica liber cu cele din VLAN-ul primar și sunt restricționate să comunice fie în grupuri (Community VLANs) fie  complet izolate între ele (Isolated VLAN).

Note: În documentația VMware, Primary Private VLAN mai este numit Promiscous Private VLAN.

Să analizăm un exemplu de rețea a cărei topologie este ilustrată mai jos: 

private VLANs - sample topology

Într-o rețea pe două switch-uri avem configurat un Private VLAN cu (a) Primary VLAN 5 (b) Isolated VLAN 155 și (c) un Community VLAN 17. Switch-urile au configurate porturi de acces pentru: (a) Primary VLAN – în care sunt conectate router-ul și serverul de backup (b) Isolated VLAN – ce are conectate 3x servere și (c) Community VLAN  17 – cu alte 3x servere. Fâșiile hașurate pot fi interpretate ca domenii de broadcast create de VLAN-urile secundare. Switch-urile sunt interconectate printr-un trunk 802.1q standard (în continuare vor urma mai multe detalii despre tranzitul de Private VLANs).

Pentru topologia și configurația descrisă mai sus:

  • router-ul și server-ul de backup din Primary VLAN 5 vor putea comunica cu toate serverele din VLAN-urile secundare (VLAN 17, 155).
  • serverele din Community VLAN  17 vor putea comunica între ele precum și cu router-ul și serverul de backup din Primary VLAN 5. Acestea nu vor putea însă accesa serverele conectate in Isolated VLAN 155.
  • serverele din Isolated VLAN 155 sunt restricționate să comunice doar cu router-ul și server-ul de backup.

Pe switch-uri pot fi create mai multe Private VLAN-uri. Un număr de sub-VLAN asociat cu un VLAN primar nu poate fi re-utilizat pe un alt VLAN primar. Comunicațiile în interiorul VLAN-ului primar rămân izolate de celelalte VLAN-uri definite pe switch.

Ca și altădată (vezi de ex. Explicație pentru vSwitch Security Policies) am încercat și acum să inventez un model prin care sa-mi explic cumva mai simplu fenomenele ce au loc într-un Private VLAN. Vedeți mai jos o ilustrație pentru modelul meu de Private VLANs. Avem aici drumuri și porți. Drumurile reprezintă căile pe care circulă frame-urile în interiorul switch-ului iar porțile sunt porturile pe switch. Fiecare drum reprezintă un VLAN dintr-un Private VLAN (VLAN-ul primar și cele secundare). Nu toate drumurile sunt la fel, unele sunt pe dublu sens – VLAN-ul primar și VLAN-ul community cu excepția segmentelor până la porțile promiscous, altele pe un singur sens – VLAN-ul izolat. În desen, drumul pentru VLAN-ul primar (5) este marcat cu albastru, cel pentru VLAN-ul izolat (155) marcat cu verde și cel pentru VLAN-ul community (17) marcat roșu. Drumurile au desenate marcaje care indică sensul mișcării, pe alocuri mai sunt și indicatoarele de circulație (observați la stânga pe segmentul de la portul community la portul promiscous). Porțile la rândul lor pot fi de unul din următoarele trei tipuri: community, isolated sau promiscous, corespunzător configurațiilor pentru porturile pe switch. În desen mai avem porți ce corespund porturilor trunk pe switch. Printre altele, schema din model transpune topologia din rețeaua discutată în exemplu de mai sus, aceleași tipuri și număr de porturi (porți).

private VLANs - PVLAN model

Modelul este guvernat de câteva reguli ce stabilesc modul de deplasare a frame-urilor:

  • fiecare tip de poartă folosește drumul lui pentru deplasarea dinspre port a frame-urilor. Astfel frame-urile dintr-un port community vor pleca întotdeauna pe drumul roșu (Community VLAN), frame-urile dintr-un port isolated vor pleca pe drumul verde (Isolated VLAN) și cele din promiscous pe drumul albastru (Primary VLAN).
  • porțile promiscous accepta intrarea frame-urile de pe toate trei drumuri
  • porțile community accepta intrarea frame-urilor de pe drumurile promiscous și isolated
  • porțile isolated accepta intrarea frame-urilor doar de pe drumul promiscous.
  • prin porțile trunk trec toate trei drumuri și toate sunt dublu-sens.

Să încercăm acum să deducem din model traseele parcurse de frame-uri pentru câteva conversații de rețea în cadrul respectivul Private VLAN:

  • dintre un nod conectat într-un port community pe un switch la un nod într-un port promiscous pe alt switch. Pe direcția dinspre community spre promiscous frame-urile își vor începe traseul pe drumul roșu marcate fiind cu Community VLAN 17 după care vor trece prin porturile trunk de pe un switch pe alt switch după care în final vor ajunge pe portul promiscous. Pe direcția opusă, frame-urile vor părăsi portul promiscous pe drumul albastru marcate cu Promiscous VLAN 5, după care vor trece prin porturile trunk de pe un switch pe alt switch, după care vor ajunge pe portul community.
  • dintre un nod conectat într-un port community pe un switch pe  un nod conectat pe un port în același community. Pe ambele direcții, frame-urile vor circula pe același drum roșu, marcate fiind cu Community VLAN 17, își vor începe traseul de la un port community după care vor trece peste porturile trunk și se vor încheia într-un alt port community.
  • dintre un nod conectat într-un port isolated pe un switch la un nod conectat pe alt switch într-un port promiscous. Pe direcția dinspre isolated spre promiscous frame-ul va porni pe drumul verde, marcat cu Isolated VLAN 155 după care va trece peste porturile trunk pe celălalt switch și își va încheia traseul în portul promiscous destinație. Pe calea întoarsă, frame-ul va porni pe drumul albastru, macat cu Primary VLAN 5 după care va trece peste porturile trunk și își va încheia traseul pe portul isolated destinație.
  • nu sunt posibile căile între porturi community și porturi isolated și nici între porturi din același VLAN isolated, pur si simplu traseul și sensul drumurilor nu permit (vezi în desen).

Pun aici punct că mi se primește prea lung textul. În următoarele părți vom analiza exemple tipice de utilizare PVLAN, condiții impuse switch-urilor ce tranzitează VLAN private, tipuri de porturi PVLAN trunk.

Configurare vCenter și nested ESXi în lab (part II)

În prima parte a articolului am descris pas cu pas procedura pentru instalarea și configurarea server-ului vCenter pentru o configurație tipică de laborator. În partea a doua am să continui cu instalarea a două host-uri ESXi nested. Lista de activități va include: instalarea și configurarea inițială a două host-uri ESXi nested; actualizarea imaginilor ESXi până la ultimul update disponibil; instalarea VMware Tools for nested ESXi; înregistrare host-uri ESXi nested în inventarul server-ului vCenter.

Instalare și configurare host-uri ESXi nested

Scenariul de laborator – descris pe scurt in prima parte a articolului, presupune crearea a două host-uri ESXi nested care, împreună cu server-ul vCenter instalat anterior, pot fi folosite ulterior ca și platformă pentru alte scenarii de laborator. Pe o așa configurație se pot încerca teste de la cele mai simple, gen vMotion, clustere HA și DRS, dvSwitch s.a.m.d, până la construcții complexe cu multiple produse VMware: vSphere Data Protection, vSphere Replication ș.a.m.d, limita fiind doar în imaginație.

Așadar, în cele ce urmează vom merge pe următorul workflow:

  • creăm un VM cu caracteristici potrivite pentru un host ESXi nested
  • instalăm o imagine fresh de ESXi 5.5 pe VM-ul preparat anterior
  • aplicăm o configurație de bază pentru host-ul ESXi nested
  • actualizăm imaginea ESXi până la ultimul update disponibil.
  • instalăm pachetul VMware Tools for Nested ESXi
  • înregistrăm host-ul ESXi nested în inventarul server-ului vCenter
  • se repetă punctele de mai sus și pentru un al doilea host ESXi nested.

Creare VM ca gazdă pentru un host ESXi 5.5 nested.

Pentru ca o mașină virtuală să poată să găzduiască cu succes un host ESXi nested va trebui ca aceasta să corespundă unei configurații specifice: pe deoparte să dețină un minim de resurse hardware 4GB RAM/2x vCPU necesare pornirii ESXi-ului nested și pe de altă parte să aibă activat mecanismul de virtualizare a funcției de virtualizare hardware (VHV). Fără de ultima va fi practic imposibil de rulat VM-uri nested de 64 de biți peste host-ul ESXi nested.  

  • inițiem procesul pentru crearea unui VM nou. Pentru aceasta, din vSphere Client conectat la server-ul vCenter din laboratorul DNT – atenție nu la cel din scenariu, click dreapta pe containerul vAPP legat de student – Create New Virtual Machine. Încercarea de a crea VM-ul într-un alt vAPP decât cel asociat va eșua din lipsa de drepturi – fiecare student poate crea/gestiona VM-uri doar în contextul containerului cu care a fost asociat.
  • în wizard-ul pornit (a) pe pagina Configuration se alege varianta Custom (b) în Name and Location se specifică un nume pentru VM, nu e obligatoriu dar e bine de ținut cont de recomandarea de nume pentru VM-uri in lab: numele VM-urilor trebuie să pornească POD-0X- unde X numărul POD-ului urmat de un scurt string ce ar reflecta destinația VM-ului. În cazul meu am folosit titlurile POD-02-ESXi-01 și POD-02-ESXi-02 pentru primul și respectiv pentru al doilea host ESXi nested (c) la faza cu storage se selectează datastore-ul RAID10-store – până când unicul disponibil (d) în Virtual Machine Version se lasă pe opțiunea sugerată: Virtual Machine Version 8 (e) pe pagina Guest Operating System pentru OS se bifează Others și pentru versiune se selectează Other (64-bit). Dacă se dorește se poate completa câmpul cu descriere, exemplu VMware. Se observă că dropdown-ul cu OS-uri nu ne oferă o opțiune pentru nested ESXi, e și de înțeles, lista conține doar OS-urile supported de VMware or configurațiile cu nested ESXi nu sunt suportate în producție ele fiind adecvate doar în scenarii de laborator (f) pe pagina cu CPUs se asigură un minim de două procesoare virtuale – fie ca core-uri într-un socket fie ca socket-uri aparte (g) în Memory se alocă un spațiu de RAM pentru ESXi-ul nested. Atenție nu mai puțin de 4GB. În cazul meu am folosit 8GB RAM. Poate fi schimbat mai târziu (h) la Network, configurăm un număr de NIC-uri virtuale, poate fi unul sau mai multe, eu am ales 4x. Se configurează fiecare NIC ca conectat în grupul de porturi dvPortGroup-STUDENTS pe switch-ul distribuit dvSwitch-LAB. Atenție, procesul de creare a VM-ului va eșua în caz că se alege un alt grup de porturi decât cel menționat – studenții sunt admiși să folosească doar acel grup de porturi. Tipul adaptorului se lasă E1000 sugerat implicit (k) pe pagina cu SCSI Controller, se lasă pe implicitul LSI Logic Parallel  (l) în Select a disk se alege opțiunea pentru crearea unui disk virtual nou, după care pe pagina următoare se specifică: i. capacitatea disk-ului virtual – un 80 GB suficient pentru început, se poate de redimensionat mai târziu, ii. modul de alocare a spațiului, obligatoriu în Thin Provision – atenție, implicit se propune opțiunea cu Thick Provision Lazy Zeroed care e cel mai lacom mod ca spațiu consumat or spațiul pe LAB e cam limitat. Dacă ați creat un VM cu un așa disk, distrugeți disk-ul inițial și recreați-l din nou dar deja în formatul Thin (m) restul paginilor se trec pe valori implicite. Vedeți mai jos un screen cu câteva fragmente din configurația VM-ului destinat host-ului ESXi nested:

config_vCenter_neste_ESXi_part_II_create_VM_for_nested_ESXi

  • modificăm Guest OS-ul din VM. Pentru acesta din proprietățile VM-ului, pe pagina Options, în General Options – Guest Operating System deschidem lista cu OS-uri din care selectăm valoarea cu VMware ESXi 5.x (în versiuni precedente titlul mai includea cuvântul experimental). Lista respectivă, spre deosebire de cea din wizard-ul de creare a VM-urilor include și OS-uri unsupported de VMware. Unsupported nu neapărat înseamnă că nu funcționează, pur si simplu pentru acestea VMware nu dă nici un fel de garanții.
  • upgradăm VM-ul de la versiunea 8 la versiunea 10. Anterior, în wizard, versiunea maximă posibilă de selectat a fost 8 fiind o limită de GUI nu și de maxim pe host-ul ESXi. Începând cu 5.0, VMware nu mai dezvoltă client-ul vSphere Client (C#) concentrându-și toată atenția doar pe vSphere WEB Cilent, de aceea tot ce ține de funcții și opțiuni în versiunile noi vSphere nu mai sunt incluse in clientul vechi inclusiv și numere noi de versiuni de VM-uri (9 pentru 5.1, 10 pentru 5.5). Note: Dacă wizard-ul pentru crearea VM-ului era să fie inițiat din clientul WEB atunci versiunea VM-ului se putea selecta din start pe 10 așa că punctul curent nu mai era nevoie de executat. Totuși, dacă ați pornit-o in vSphere Client, upgrade-ul pentru VM se poate de făcut printr-un click dreapta pe VM după care Upgrade Virtual Hardware. Versiunea noua a VM-ului poate fi verificată în VM version pe pagina Summary a VM-ului și ar trebui să coincidă cu vmx-10. De menționat, că după upgradarea VM-ului la ultima versiune, editarea proprietăților acestuia va fi posibilă doar din clientul WEB.
  • activăm mecanismul virtualizării funcției de virtualizare hardware (VHV). De menționat că aceasta va fi posibil doar dacă s-au executat corect precedentele două puncte (guest OS in VMware ESXi 5.x și Virtual Machine version in vmx-10), în caz contrar opțiunea din GUI de activare a mecanismului va fi marcată ca inactivă. Pentru a activa VHV-ul se poate de mers pe una din două căi: (a) fie prin adăugarea în fișierului de configurare a VM-ului a secvenței vhv.enable=”true”  – destul de complex dar și imposibil cu privilegiile pe LAB a studenților (b) fie prin WEB Client, recomandat. Pentru Web Client, se deschide proprietățile VM-ului cu Edit Virtual Machine Settings după care din Virtual Hardware – CPU se bifează parametrul: Hardware Virtualization – Expose hardware assisted virtualization to the guest OS.

​Instalare imagine ESXi 5.5 în VM-ul destinat host-ului ESXi nested.

În continuare vom instala o imagine ESXi 5.5 pe VM-ul creat anterior pentru host-ul ESXi nested.

  • montăm ISO-ul cu setup-ul pentru VMware ESXi. Pentru aceasta, din vSphere WEB Client deschidem proprietățile VM-ului, trecem pe secțiunea Virtual Hardware, unde în CD/DVD drive 1 specificăm Datastore ISO File. În fereastra Select File alegem fișierul: VMware-VMvisor-Installer-5.5.0.update02-2068190.x86_64.iso, folder: RAID10-Store\ISO. Pentru comoditate iso-ul setup-ului a fost încărcat din timp pe datastore-ul din LAB, e posibil să nu fie tocmai ultimul build așa că dacă se dorește se poate de descărcat un iso mai nou pe pagina de download VMware (aveți nevoie de un simplu cont pe site). Note: Am ales să montăm ISO-ul din vSphere WEB Client din simplu motivă că după upgrade-ul de versiune a mașinii virtuale proprietățile acesteia pot fi modificate deja doar prin WEB Client și deloc prin vSphere Client.
  • se pornește VM-ul, fie din WEB Client fie din vSphere Client. Se lasă să pornească procesul de setup pentru ESXi (fereastră cu sur pe galben și progress bar)
  • în continuare se parcurge wizard-ul pentru instalare ESXi: (a) pe pagina Welcome .. click pe Enter (Continue) (b) în EULA click pe (F11) Accept and Continue (c) în Select a Disk to Install or Upgrade mergem de acord cu unica opțiune: disk-ul virtual de 80GB creat anterior – spațiul de stocare va fi folosit atât pentru ESXi-ul propriu-zis cât și ca datastore VMFS pentru VM-uri nested pe acest ESXi (d) în keyboard layout click (Enter) Continue cu US default (e) pe pagina Enter a root password specificăm o parola cu confirmare pentru root-ul ESXi. Urmează un proces automat cu reboot pe final – câteva minute.

Configurare inițială pentru ESXi-ul  nested

Vom continua prin a aplica o configurație de bază pe host-ul ESXi nested. Vom re-configura ESXi nested din consola VM-ului ce îl găzduiește accesând Direct Console User Interface (DCUI).

  • ne autentificam pe consola DCUI ESXi . Pentru asta, din consola VM-ului care ar trebui să afișeze pagina de standby DCUI (sur pe galben) se apasă pe <F2> Customize System/View Logs care schimbă view-ul pe un dialog pentru introducerea credențialelor pentru autentificare. Se introduce username-ul root și password-ul lui (setat la faza de instalare ESXi).
  • în System Customization se trece pe Configure Management Network unde vom configura: (a) în Network Adapters vom bifa toate adaptoarele disponibile – anterior am configurat pe VM patru vmnic-uri vmnic0-3. Toate adaptoarele vor face parte din vSwitch0 și vor participa in team pentru interfața de management vmk0 ESXi (b) în IP Configuration se trece de pe configurația cu DHCP implicit, pe configurație cu parametri setați manual: Set static IP address and network configuration. Setăm o adresă IP din intervalul recomandat pentru numărul POD-ului și o mască de rețea de 16 biți, în cazul meu am folosit IP-ul: 172.16.22.41(.42 pentru al doilea host ESXi), Subnet Mask: 255.255.0.0. In general studentul e liber să folosească orice adrese IP pe care le consideră potrivite, condiția e doar ca să nu coincidă cu ceva deja setat pe LAB (c) în IPv6 Configuration deconectăm stack-ul IPv6 prin de-bifarea: Enable IPv6 .. – implicit bifat (d) în DNS Configuration setăm drept server DNS IP-ului server-ul vCenter din LAB – care a fost configurat și ca server DNS. În câmpul Hostname specificăm un nume pentru ESXi – care pentru simplitate poate să coincidă cu numele VM-ului, în cazul meu: pod-02-esxi-01 (e) în Custom DNS Suffixes formăm numele zonei DNS setate pe serverul DNS (vCenter), in cazul meu: lab.local. Aplicam configurațiile de mai sus prin abandonarea meniului cu Management Network. Mai mult ca sigur se va propune reboot-area host-ului ESXi, se confirmă dialogul după care host-ul pleacă automat in reboot.
  • între timp, se configurează o înregistrare A NAME pe serverul DNS corespunzătoare numelui host-ului ESXi. Pentru aceasta, pe serverul DNS (vCenter) se deschide consola serverului DNS: DNS Manager. De aici, click dreapta pe zona lab.localNew Host (A or AAAA). În fereastra New Host se specifică hostname-ul ESXi-ului și adresa IP ce-i corespunde: pod-02.esxi-01 și respectiv 172.16.22.41. Se asigură că bifată opțiunea Create associated pointer (PTR) record.
  • e bine ca după restart-ul ESXi-ului de făcut un test de networking pe acesta. Pentru asta, din DCUI se accesează System CustomizationTest Management Network. Implicit se încearcă ping-ul pe adresa IP a server-ului DNS (ping address #0) și rezoluția numelui hostname (resolve hostname) plus ping pe acel IP (IP-ul ESXi-ului). În Resolve Hostname completăm hostname-ul până la FQDN astfel încât să includă și sufixul DNS. Note: primul ping va eșua pentru că pe server-ul DNS (vCenter) funcționează firewall-ul din Windows care implicit blochează ICMP-ului, dacă se dorește, se poate de permis ICMP-ul prin activarea (enable) a regulilor File and Printer Sharing (Echo Request .. )

config_vCenter_neste_ESXi_part_II_configure_ESXi

Actualizare imagine ESXi până la ultimul update disponibil

Chiar dacă va fi folosit într-un mediu de test e bine totuși ca și ESXi-ul din lab să fie actualizat up-to-date. În cele ce urmează vom aplica peste imaginea existentă ESXi ultimele update-uri disponibile pe depot-ul de download VMware folosind linia de comandă și accesând Internet-ul peste server-ul proxy din LAB.

  • configurăm accesul la linia de comandă CLI. CLI-ul îl vom accesa peste SSH așa că va trebuie pentru început de activat SSH-ul pe host-ul ESXi. Pentru aceasta, ne conectăm cu vSphere Client pe IP-ul host-ului ESXi nested (172.16.22.41), atenție nu IP-ul vCenter-ului din LAB sau din POD dar pe ESXi-ul instalat în p. precedent. Folosim credențialele root-ului. Odată autentificați, accesăm Configuration – Security Profile (software) – Services – Properties. În fereastra Service Properties facem click pe SSH (implicit e in statut Stopped) după care pe butonul Options (stânga jos). În ESXi Shell (TSM) Options click pe Start Ok.
  • deschidem consola ESXi prin SSH. Din clientul preferat SSH (recomandat putty.exe) deschidem o sesiune pe IP-ul host-ului ESXi (172.16.22.41). Client-ul SSH poate fi pornit din orice loc din lab de unde aste acces pe IP la ESXi-ul nested, exemplu din VM-ul cu Win7 din POD-ul studentului. Pentru autentificare prezentăm credențialele root-ului.
  • verificăm versiunea curentă pentru imaginea ESXi (build number). O putem face prin două căi: fie prin vSphere Client conectat la host-ul ESXi (pe ribon deasupra tab-urilor), fie prin CLI cu esxcli system version get. În cazul meu, am pornit cu un build ESXi de 2068190 ce corespunde imaginii: VMware ESXi 5.5 Update 2 (pentru un lookup build_number-to-version puteți folosi de exemplu lista de aici).

config_vCenter_neste_ESXi_part_II_update_ESXi_get_verssion

  • pachetele de actualizări le vom descărca direct de pe depot-ul de download VMware din Internet așa că în comenzile din CLI va trebui de specificat în plus la adresa depot-ului și detaliile serverului http proxy. In LAB, Internet-ul îl accesăm prin server-ul proxy aflat pe IP-ul 172.16.0.39 și folosind port-ul 8080. Atenție, în caz că folosiți procedura de mai jos pentru un alt sistem decât LAB-ul și accesați Internet-ul printr-un proxy ce funcționează pe un alt port decât 8080 atunci, suplimentar, veți trebui să adăugați o regulă în plus pe firewall-ul ESXi. Adevărul e că ESXi-ul își are un firewall al lui, care implicit blochează majoritatea porturilor de comunicații lăsând deschise doar anumite porturi specifice serviciilor de ESXi. Din fericire, port-ul folosit de proxy-ul din LAB: 8080, e deschis cu una din regulile existente de firewall (regula pentru serviciul vsanvp) așa că nu mai e nevoie de manipulări în plus pe acest subiect. Pentru mai multe detalii legate de reguli de firewall custom pe ESXi vă recomand să consultați KB 2008226. În caz că accesați Internet-ul peste NAT veți trebui să porniți una din regulile de firewall deja existente – implicit oprită: httpClient (outgoing 80,443) – o puteți face fie din CLI (esxcli network firewall ruleset set -e true -r httpClient) fie din vSphere Cilent (Security Profile – Firewall – Properties – check httpClient). Încă odată, în LAB nu avem nevoie de modificări în plus pe firewall-ul ESXi.
  • așa cum ESXi-ul nested are configurat server-ul vCenter ca server DNS, care la rândul lui este unul izolat de DNS-ul zonelor din Internet, rezultă că ne va fi imposibil să avem o rezoluție cu succes pentru host-uri din Internet. În general, prin rețeaua din LAB izolată, practic devine imposibil de soluționat host-uri pentru zone din Internet. Ce este interesant totuși, dintr-un browser setat cu http proxy rezoluția de nume are loc cumva prin proxy și nu tradițional cu request-uri pe IP-ul serverului DNS (setat in tcp/ip settings), dar asta nu funcționează și pentru CLI-ul ESXi așa că în acest caz va trebui să aplicăm un workaround. Vom crea pe DNS (vCenter) o zona cu numele vmware.com în care vom crea o înregistrare A Name cu numele hostupdate legată de unul din IP-urile reale de Internet. IP-urile le aflăm de pe un PC cu acces la Internet prin nslookup pentru FQDN-ul hostupdate.vmware.com. Mie mi-a dat IP-ul: 23.40.163.43, dar fiți atenți că acesta se poate schimba așa că e bine ca de fiecare dată se verificați valorile. Pentru a crea o zonă pe server-ul DNS deschideți consola serviciului DNS (pe server-ul vCenter) după care în forward lookup zone porniți wizard-ul pentru crearea unei noi zone (vmware.com). După ce ați creat zona, adăugați în aceasta o înregistrare pentru hostupdate cu IP-ul aflat mai sus. Pe final, verificați cu nslookup rezoluția pentru FQDN-ul hostupdate.vmware.com pornit direct pe server-ul vCenter (cel din POD-ul vostru).
  • executăm următoarea comandă ESXCLI pentru a verifica lista de actualizări disponibile in depot-ul VMware pe Internet: 

note 1: pe output-ul comenzii am aplicat un filtru cu grep pentru a scoate în evidență ultimele bundle-uri de actualizări disponibile pentru versiunea 5.5 de ESXi. În titlul bundle-ului după cratimă după versiunea ESXi urmează release date-ul codat in forma YYYYMM.. așa că indicând in argument-ul grep-ului anul si luna se poate de îngustat output-ul până la ultimele actualizări. Fără filtru, comanda va afișa o listă lungă de bundle-uri pentru toată perioada și pentru toate versiunile ESXi 5.x – listă greu de interpretat.

note 2: bundle-urile de update sunt cumulative așa că pentru a actualiza un host până la ultima versiune va fi suficient de aplicat doar ultimul bundle de update. Nu e deloc nevoie de aplicat update-uri consecutive pentru a ajunge la ultima versiune pentru imaginea ESXi.

config_vCenter_neste_ESXi_part_II_update_ESXi_get_update_bundles

Din lista de bundle-uri de update disponibile la momentul întocmirii articolului, ultimele update-uri sunt cele care încep cu: ESXi-5.5.0-20150402001-xx. Din acestea (două), vom alege pe cel cu sufixul standard ca fiind complet (include toate actualizările inclusiv vmware-tools). 

  • executăm următoarea comandă ESXCLI pentru a aplica pe imaginea ESXi bundle-ul de update selectat:

odată pornită, comanda poate să dureze până se execută și poate crea impresia că e blocată așa că înarmați-vă cu puțină răbdare și așteptați un răspuns pe consolă. Vedeți mai jos, replay-ul pentru o execuție reușită a comenzii, din output am scos o parte din lista ce ne afișează numărul de VIB-uri ce nu au fost atinse de update (destul de lungă). 

config_vCenter_neste_ESXi_part_II_update_ESXi_apply_update_bundles

  • reboot-ăm host-ul ESXi fie din CLI cu comanda reboot fie din vSphere Client. După reboot, verificăm încă odată versiunea imaginii ESXi, fie din lina de comandă cu esxcli system version get fie cu vSphere Client: 

config_vCenter_neste_ESXi_part_II_update_ESXi_version_check_after_update

se observă că avem deja un build number superior celui de până la update (2638301 vs 2068190) care e ultimul la momentul întocmirii articolului.

De remarcat că procedura de actualizare a unui host ESXi poate fi realizată și fără acces direct la Internet. Pentru aceasta se descarcă în prealabil a bundle-ul de update de pe portalul de download VMware după care se încarcă pe unul din datastore-urile ESXi-ului. În linia de comandă, ca argument la ESXCLI-ul de update se va specifica drept depot path-ul pe datastore. Pentru detalii cum de făcut asta  puteți consulta articolul (vladan – how to patch free vmware esxi). Este la discreția voastră cu ce metodă să mergeți, ambele funcționează.

Instalare pachet VMware Tools for Nested ESXi

Deloc obligatoriu dar totuși recomandabil, este ideea de a instala pachetul VMware Tools for Nested ESXi pe imaginea host-ului ESXi nested. După install, acesta vine ca un pachet VIB încadrat în image profile-ul ESXi. Prin VMware Tools for Nested ESXi vom putea: (a) obține informații despre OS-ul ESXi-ului nested direct pe ESXi-ul ce-l găzduiește (adresa IP, hostname .. ) – se vor citi cu vSphere Client/WEB Client în summary pentru VM-ul cu nested ESXi și (b) deconecta/restarta corect ESXi-ul nested cu comenzi shut down guest/restart guest din ESXi-ul ce-l găzduiește. Pentru mai multe detalii verificați referințele aici și aici. Trebuie de menționat că în versiunea 6.0 de ESXi VIB-ul pentru VMware Tools for Nested ESXi face parte deja ca implicit din image profile-ului ESXi așa că dacă încercați 6.0 atunci pasul ăsta este ca și cum exectutat.

  • pentru a instala VMware Tools for Nested ESXi vom folosi linia de comandă. VIB-ul îl vom descărca din Internet odată cu executarea comenzii de install prin specificarea în argumente a adresei depot-ului de download. Ca și în cazul cu actualizarea imaginii ESXi va trebui de adăugat pe DNS o înregistrare A Name pentru host-ul download3.vmware.com și IP-ul de Internet ce-i corespunde – la momentul întocmirii articolului acesta a fost: 23.64.211.51. Despre cum de creat o înregistrare pe DNS vedeți mai sus textul cu actualizarea ESXi-ului.
  • din CLI, executăm următoarea comandă ESXCLI pentru a instala VIB-ul cu VMware Tools for Nested ESXi

Note: versiunea curentă pentru VMware Tools for Nested ESXi este de 9.7.1 dar se poate schimba în timp așa că înainte de a porni comanda de install verificați pe site-ul proiectului (aici) în instructions numărul ultimei versiuni și corectați corespunzător link-ul de download.

config_vCenter_neste_ESXi_part_II_install_vmware_tools_for_nested_esxi

se rebotează host-ul ESXi nested, după care se verifică statutul VMware tools din vSphere Client conectat la vCenter-ul din LAB și focusat pe VM-ul cu ESXi nested: 

config_vCenter_neste_ESXi_part_II_vmware_tools_for_nested_esxi_status

Înregistram host-ul ESXi nested în inventarul server-ului vCenter

Acum că avem vCenter-ul și unul din host-urile ESXi nested instalate și configurate putem să înregistrăm ESXi-ul pe vCenter. Pentru aceasta, din vSphere Client conectat la server-ul vCenter (din POD-ul studentului) în inventar se face click dreapta pe numele datacenter-ului (acesta se creează în prealabil) după care se alege Add Host … În wizard-ul pornit, (a) pe pagina Connection Settings în Host specificăm FQDN-ul pentru host-ul ESXi nested: pod-02-esxi-01.lab.local precum și credențialele pentru root. După Next va apărea un dialog pentru confirmarea certificatului, click Yes. (b) restul pașilor din wizard se parcurg cu valori implicite (no license/no lockdown mode).

Instalarea și configurarea unui al doilea host ESXi nested

Așa cum scenariul presupune prezența a două host-uri ESXi nested, se vor parcurge pașii descriși pentru primul ESXi și pentru un al doilea ESXi nested. Diferențele vor fi doar in hostname și adresă IP de management, care în cazul meu vor fi pod-02-esxi-02 și respectiv 172.16.22.42.

Cu asta închei partea a doua și finală a articolului pentru configurarea componentelor dintr-un prim scenariu de laborator recomandat studenților claselor de VMware realizat pe platforma de laborator DNT.

Configurare vCenter și nested ESXi în lab (part I)

Ca să continui cu subiectul platformei de laborator VMware (început aici, aici și aici) am să încerc în cele ce urmează să descriu pas cu pas configurarea componentelor dintr-un prim scenariu de laborator. Scenariul presupune instalarea a două host-uri ESXi nested și a unui server vCenter. Conținutului articolului am sa-l organizez pe două parți: în prima parte am să descriu instalarea și configurarea server-ului vCenter și a doua va fi dedicată configurării host-urilor ESXi nested.

Dacă e să generalizez, atunci ceea ce vom avea de făcut va fi să:

  • instalăm de la zero un server vCenter Server 5.5 pe Windows și ca să nu risipim resurse vom folosi același VM și ca server DNS (necesar pentru un setup corect de vCenter).
  • instalăm două host-uri ESXi nested (ca VM-uri in lab) cu o configurație potrivită pentru networking-ul din mediul de laborator.
  • actualizăm imaginile pe host-urile ESXi nested până la ultimul update disponibil.
  • instalăm pe hosturile ESXi nested pachetul cu VMware Tools for nested ESXi.
  • înregistrăm host-urile ESXi nested pe server-ul vCenter instalat anterior.

Pentru o reprezentarea grafică vedeți desenul de mai jos:

config_vCenter_neste_ESXi_part_I_general

Instalare și configurare server vCenter Server

În scenariul de laborator vom instala și configura un server vCenter bazat pe Windows. Sigur, e posibil de încercat și varianta pe Linux: vCSA. Pentru exemplu, totuși, am ales varianta pe Windows pentru că ne oferă mai multă granularitate la instalare și parcă e mai didactic așa. Pe același VM cu serverul vCenter vom configura in prealabil rolul de server DNS. Vom avea nevoie de DNS până a începe install-ul server-ului vCenter, ultimul având nevoie de DNS pentru un setup corect, mai multe detalii urmează. Pentru a nu pierde timpul pe instalarea de la zero a sistemului de operare Windows Server vom folosi o imagine template pre-instalată din timp.

Mai jos va urma procedura pentru instalarea și configurarea serverului vCenter in LAB. Pașii din descriere au fost executați pe viu folosind un utilizator cu privilegii identice ca a unui student cu acces standard la mediul de laborator. Prin aceasta am mai verificat odată setările pentru drepturi de acces la mediul de laborator. VM-urile le-am găzduit in POD-02. 

  • desfășurăm un VM cu Windows Server folosind unul din template-urile pre-instalate. Pentru acesta, din vSphere Client conectat la server-ul vCenter de laborator (172.16.0.4) accesăm view-ul VMs and Templates. În folder-ul TEMPLATES click dreapta pe template-ul LAB-Win2k12r2-TEMPLATE. Pornim wizard-ul de setup prin Deploy Virtual Machine from this Template. În wizard vom specifica: (a) în Name and Location numele VM-ului, care ca recomandare e bine să corespundă convenției de nume deja discutate – prefixul POD-0X urmat de un string ce reflecta destinația funcțională a VM-ului: Name: POD-02-vCenter-01 (b) în Host and Cluster selectăm LAB-Cluster (c) în Resource Pool selectăm containerul alocat: STD-POD-A02 – fiecare student are asociat un POD și doar în acesta are dreptul să creeze/gestioneze VM-uri (d) în Storage ne asigurăm încă odată ca avem o alocare pentru disk-ul virtual de tip Thin Provisioning – implicit se selectează Same format as source care pentru template-ul respectiv înseamnă Thin dar ca deprindere e bine totuși de arătat în mod evident formatul. Ca destinație de stocare nu avem altă opțiune decât unicul datastore Raid10-Store (e) în Guest Customization se lasă implicit pe Do not customize (f) în Ready to Complete verificăm încă odată opțiunile alese, confirmăm cu Finish. E bine aici de bifat Edit virtual hardware pentru a accesa fereastra cu proprietățile VM-ului (până la desfășurarea template-ului).
  • ajustăm configurația VM-ului, verificăm ca viitorul VM să aibă asigurate cel puțin următoarele resurse hardware: (a) 2x vCPU (b) 8192 MB RAM. Template-ul, implicit, va crea un VM cu 2x vCPU-uri și 12GB RAM. Confirmăm proprietățile VM-ului, după care automat pornește procesul de desfășurare a template-ului. Procesul poate să dureze mai multe minute – la mine a durat aproape 4 min. Un timp foarte bun dacă e să compar cu cât timp era să pierdem dacă instalam tradițional OS-ul.
  • configuram network-ul destinație pentru VM. Pentru aceasta cu Edit SettingsNetwork Adapter – Network Connect selectăm dvPortgroup-STUDENTS (dvSwitch-LAB ca rețea destinație. Implicit, template-ul creează un VM detașat de rețea.
  • pornim VM-ul după care urmărim în consolă procesul de inițializare a sistemului de operare. În fereastra de autentificare folosim user-ul Administrator cu parola standard asdfgh1!
  • odată autentificați pe server executăm următoarele configurații în OS: (a) adresă IP care trebuie să corespundă spațiului de adrese recomandat 172.16.2X.0/24 unde X e numărului POD-ului, în exemplu am folosit IP-ul 172.16.22.20/16. Atenție, folosiți o mască de 16 biți (cea sugerată la formarea adresei IP). Nu se mai configurează nimic altceva, nici default gateway nici servere DNS. Verificăm conexiunea de rețea cu un ping la server-ul proxy 172.16.0.39. (b) in Internet Options – LAN Settings specificăm adresa IP și port-ul pentru server-ul Proxy: 172.16.0.39, tot aici, obligatoriu, bifăm: bypass proxy server for local address și în excepții prin advanced specificam wildcard-ul 172.16.*.* (c) redenumim Computer Name în așa fel încât ca să coincidă cu numele VM-ului: POD-02-vCenter-01. Restart Guest OS. (d) dacă se insistă se poate și de verificat/aplicat ultimele actualizări pentru OS.

Pentru a realiza un install corect și complet pentru serverul vCenter vom avea nevoie de o infrastructură DNS funcțională. DNS-ul ar trebui să dețină în forward lookup zone și reverse lookup zone înregistrări cu hostname-ul (FQDN) și IP-ul server-ului vCenter. Deși setup-ul pentru cazul când DNS-ul lipsește se limitează doar la câteva warrning-uri lăsând ca procesul în ansamblu să se încheie cu succes, recomandarea generală este totuși în a avea un DNS configurat corespunzător. Afirmații despre requirements-ul pentru DNS le găsim în documentația pentru vCenter (VMware vSphere Documentation Center): DNS Requirements for vSphere (link)

Ensure that the vCenter Server is installed on a machine that has a resolvable fully qualified domain name (FQDN). To check that the FQDN is resolvable, type nslookup your_vCenter_Server_fqdn at a command line prompt. ….  Ensure that DNS reverse lookup returns a fully qualified domain name when queried with the IP address of the vCenter Server.

Pentru a acoperi această cerință vom implementa un server DNS care pentru economie de resurse îl vom instala pe VM-ul cu server vCenter. Cel mai probabil așa configurație nu e supported pentru un setup în producție, dar pentru un mediu de laborator e mai mult ca ok. Cum se face asta pentru un server vCenter pe Linux verificați link-ul. Pentru Windows puteți urma următoarea procedură: 

  • pe VM-ul destinat vCenter-ului instalăm rolul de DNS Server. Pentru asta, din Server Manager click pe Manage – Add Roles and Feature, în wizard selectăm: DNS Server. Parcurgem restul paginilor din Wizard pe default. Așteptăm ca install-ul să finalizeze.
  • vom configura server-ul DNS ca responsabil de o zona DNS la alegere – în exemplu am ales zona lab.local. Pentru aceasta, deschidem DNS Manager în ierarhie, click dreapta pe Forward Lookup Zone – New Zone. În wizard de crearea a zonei specificăm: (a) zone type: primary (b) zone name: lab.local (c) restul pașilor se lasă cu opțiunile implicite.
  • fără a închide consola DNS-ului se inițiază crearea unei zone reverse lookup, pentru acesta click dreapta pe reverse lookup zone – New Zone, în wizard vom specifica: (a) zone type: primary (b) IPv4 Reverse Lookup Zone (c) în Network ID indicăm network ID-ul pentru subnet-ul rezervat lab-ului: 172.16.22.0. (d) restul pașilor se lasă cu opțiunile implicite.
  • configurăm lab.local ca și sufix DNS pentru conexiunea de rețea a server-ului vCenter. Pentru acesta, din TCP/IP settings pe conexiunea de rețea, în Advanced Settings – DNS în căsuța DNS suffix for this connection indicăm numele lab.local.
  • în Use the following DNS server addresses, specificăm 127.0.0.1 (loopback) ca Preferred DNS server.
  • din consola server-ului DNS, inițiem crearea unei înregistrări noi de tip CNAME în zona lab.local. În fereastra deschisă, în câmpul Name specificăm hostname-ul server-ului vCenter: POD-02-vCenter-01 și în IP address adresa IP: 172.16.22.20. Se asigură că bifa Create associated point (PTR) record este setată – parametru va asigura crearea automată a unei înregistrări în reverse lookup zone.
  • se verifică setările DNS. Pentru aceasta, din linia de comandă se pornește utilitarul nslookup în care se solicită consecutiv rezoluția de nume pentru FQDN la serverul vCenter: POD-02-vCenter-01.lab.local și rezoluția reverse pentru IP-ul server-ului vCenter: 172.16.22.20. Ambele rezoluții trebuie să reușească, dacă nu au mers mai verificați odată pașii de mai sus.

Pentru comoditate, am înregistrat într-un screencast pașii din procedura descrisă mai sus:

Acum că avem toate pre-rechizitele pentru a instala server-ul vCenter, vom continua cu:

  • montăm ISO-ul cu setup-ul server-ului vCenter Server 5.5 la VM. Pentru aceasta, din Edit Settings la VM, click pe CD/DVD Drive. Pe dreapta, se asigură că bifele pentru Connected/Connected at Power On sunt setate iar in Device Type selectăm Datastore ISO File. Cu Browse accesăm folder-ul ISO de pe datastore și de aici selectăm fișierul ISO: VMware-VIMSetup-all-5.5.0-2183112-20140901-update02.iso.
  • in VM, dacă nu s-a lansat automat, pornim aplicația de setup vCenter (splash). În fereastră, inițiem instalarea vCenter-ului printr-un click pe Simple Install. Pentru simplitate am ales formatul cu instalare automat pentru toate componentele vCenter.
  • În wizard-ul Simple Install Setup: (a) EULA: I accept the terms. .. (b) în Select network interface  alegem interfața cu adresa IP IPv4 (c) în pre-requisites check verificăm să nu avem erori. Un warrning totuși se va afișa: cel cu Machine is not domain joined, care poate fi liber ignorat – nu e deloc obligatoriu un domain AD pentru instalarea cu succes a serverului vCenter (d) în vCenter Single Sign-On Information specificăm un password cu confirmare pentru administratorul serviciului SSO si a serverului vCenter. Se verifică complexitatea password-ului așa că indicați o parola complicată. Important ca această parolă să fie reținută undeva pentru că mai târziu cu aceasta se va accesa pentru prima data vCenter-ul. (e) restul paginilor din wizard se parcurg cu valorile lor implicite.  Se așteaptă câteva minute până când setup-ul se încheie. Posibil ca pe parcurs să primiți un dialog cu mesajul: Stop running this script ? ..  pe acesta îl puteți ignora printr-un click pe No.
  • în următoarea fază automat se va porni install-ul pentru următorul component, primul a fost SSO-ul, urmează vCenter WEB Client-ul. La un moment dat se va cere să acceptați certificatul SSL, click Yes. Întreg procesul rulează automat.
  • urmează setup-ul pentru Inventory Service care la fel a automat.
  • pe final pornește install-ul serviciului vCenter. În wizard: (a) pe pagina License Key ignorăm cu Next. Cheile de licență le vom instala mai târziu. (b) în Database Options lăsăm opțiunea implicită cu Install a Microsoft SQL Server 2008 Express instance. Vom merge cu o configurație pe SQL Sever Express tocmai potrivită în lab (c) în vCenter Server Service account information lăsăm bifat Use Windows Local System Account iar în Fully Qualified Domain Name înlocuim valoarea sugerată: IP-ul vCenter-ului, cu numele de domain al acestuia: POD-02-vCenter-01.lab.local. (d) restul paginilor din wizard se parcurg cu valorile implicite.
  • în continuare (opțional), vom instala browser-ul Chrome, acesta e mai light și are Adobe Flash Player-ul pre-instalat, ultimul fiind obligatoriu pentru accesul la vSphere WEB Client.
  • accesăm WEB Client-ul din browser-ul Chrome, pentru aceasta formăm în browser adresa: https://172.16.22.20:9443/vsphere-client. Pe pagina de autentificare specificăm credențialele pentru administratorul SSO/vCenter: Administrar@vsphere.local/password. Obligatoriu, numele utilizator trebuie să conțină sufixul domain-ului local: @vsphere.local. Mai târziu, se va configura SSO-ul ca default  identity source așa ca să nu mai fie necesar de specificat prefixul.
  • pe final, se poate instala și vSphere Client (opțional), pentru aceeași fereastra din care sa ales setup-ul pentru vCenter se inițiază install-ul pentru vSphere Client. Se parcurge wizard-ul de instalare fără a specifica vreun detaliu.

Vedeți partea a doua a screencast-ului cu install-ul server-ului vCenter:

Până aici avem instalat și configurat server-ul vCenter, in partea a doua a articolului vom instala și configura host-urile ESXi nested.

Mediu de laborator pentru studenții claselor de VMware (part III)

În părțile precedente ale articolului (part I, part II) am descris arhitectura și detaliile pentru configurația serviciilor vCenter, VPN, Proxy pe mediul de laborator DNT VMware. În partea a 3-a, ultima, am să descriu unele activități privind utilizarea enviroment-ului de laborator.

How to connect to DNT VMware LAB via VPN

Vom folosi o conexiune VPN pentru o legătură remote la enviroment-ul de laborator. Pentru acesta:

  • descărcăm client-ul VPN pe site-ul proiectului SoftEther VPN (secțiune download, ~35MB)
  • instalăm pachetul de instalare (banal, next – next .. finish)
  • pornim client-ul VPN, din top menu selectăm Connect – New VPN Connection Settings
  • în fereastra New VPN Connection Settings Properties secțiunea Destination VPN Server specificăm următorii parametri pentru o conexiune nouă: (a) setting name – un nume p/u noua conexiune (b) host name specificăm IP-ul de Internet pe router-ul DNT: 178.168.50.194, (c) port number selectăm din listă numărul 443 (d) dacă in punctele b și c nu sa greșit atunci lista cu Virtual Hub Name ar trebui să se completeze automat cu singura valoare Default pe care o și specificăm.
  • în aceeași fereastră în secțiunea User Authentication Settings specificăm username-ul și password-ul distribuite anterior de instructor pentru fiecare student. Așa cum sa mai zis, user name-ul se ia ca nume/prenume separat prin punct. În drop-down-ul Auth Type ne asigurăm că avem selectat Standard Password Authentication. Click Ok pentru confirmarea configurației. Mai jos, vedeți screen-ul pentru o configurație tipică a conexiunii VPN (exemplu pentru unul din studenți): 

dnt_vmware_lab_enviroment_p3_client configuration

Note: În caz că accesați Internet-ul prin web proxy va trebui să specificați și detaliile server-ului proxy. Pentru aceasta, în secțiunea Proxy Server as Relay (mai jos de Destination VPN server) bifați Connect via HTTP Proxy Server după care faceți click pe Proxy Server Settings. În fereastra Proxy Server Connection Settings specificați numele sau IP-ul serverului proxy, port-ul pe care acesta e configurat să funcționeze și dacă e cazul credențiale pentru autentificare.

  • pe final, în fereastra de bază SoftEther VPN Client Manager inițiem conexiunea VPN nou creată prin click dreapta pe conexiune, connect. Dacă totul a fost făcut corect, conexiunea trebuie să se stabilească cu succes fapt remarcat într-o fereastră de confirmare în care veți observa și IP-ul asignat pe interfața VPN (unul din intervalul 172.16.0.100 – 172.16.0.200). 

dnt_vmware_lab_enviroment_p3_client_connected

În continuare, se va accesa VM-ul cu Win7 legat de POD-ul studentului. VM-ul se accesează prin Remote Desktop (RDP). Adresa IP se deduce simplu, fiind a 10-a adresa in intervalul /24 asociat cu POD-ul studentului, altfel spus: 172.16.2X.10 unde X numărul POD-ului. Pentru autentificare pe VM se folosește user-ul Administrator cu password-ul asdfgh1! (nu schimbați acest password !!!).  Ca alternativă, se poate de lucrat direct pe enviroment fără a mai accesa stația cu Win7, pentru acesta se deschide vSphere Client (WEB Client) direct de pe PC-ul de acasă în care se specifică IP-ul server-ului vCenter din rețeua de laborator 172.16.0.4.

De remarcat, că conexiunea VPN nu este necesară pentru accesul la enviroment-ul de laborator din sălile de studiu DNT. De acolo, vCenter-ul din LAB se accesează direct pe IP-ul său din rețeaua de producție, adică 10.10.1.45.

How to change VPN user password

Nu este obligatoriu, dar totuși, dacă se dorește schimbarea parolei pentru conexiunea de VPN aceasta se va realiza din fereastra Properties a conexiunii VPN. În secțiunea User Authentication Settings se face click pe Change Password (vezi în screen-ul din punctul precedent). În fereastra de Change Password specificăm parola inițială precum și parola nouă plus confirmarea ei. Cred că nu mai merită să reamintesc despre cerințele de complexitate a parolei pentru o conexiune VPN.

How to change vCenter SSO user password

Odată ajunși pe mediul de laborator – in VM-ul cu Win7, studenții vor accesa server-ul vCenter fie prin vSphere Client fie cu Web Client. Pentru a accesa client-ul WEB, in browser (recomandat Chrome Browser pentru că are deja instalat adobe flash player) se va accesa adresa https://172.16.0.4:9443/vsphere-client/  sau pentru sălile de studiu DNT link-ul cu IP din rețeaua de producție https://10.10.1.45:9443/vsphere-client/. Studenții vor folosi drept username numele/prenumele propriu separat prin punct cu un password inițial distribuit de instructor. Dacă se dorește password-ul pentru user-ul vSphere poate fi schimbat. Schimbarea parolei poate fi executată doar din WEB Client după prima autentificare reușită accesând sub-meniul pe top bar. Pentru detalii vedeți imaginea de mai jos:

dnt_vmware_lab_enviroment_p3_vSphere_change_password

How to create a new Virtual Machine

Prima sarcina de realizat pe mediul de laborator sigur va fi crearea unui VM nou. Să vedem pe pași, cum vom crea un VM în vSphere Client:

  • poziționăm cursorul mouse-ului pe containerul vAPP cu care suntem asociat. Click dreapta, New Virtual Machine .. Opțiunea New Virtual Machine .. va fi ne-disponibilă (grayed) în caz că încercați crearea VM-ului într-un container ce nu vă aparține (alt vAPP, pe cluster sau datacenter).
  • în wizard-ul Create New Virtual Machine pe pagina Configuration selectăm după caz Typical sau Custom pentru exemplu vom alege Typical.
  • în continuare, pe pagina Name and Location atribuim un nume pentru noul VM. Ca recomandare, de obicei propun studenților să respecte cu toții o convenție de nume și anume ca toate VM-ul să-și înceapă numele cu titlul POD-ului: POD-0X-<nume VM>  unde X este numărul vAPP-ului personal. De ex pentru 3x VM-uri in vAPP-ul 03 (a) POD-03-ESXi-01 (b) POD-03-ESXi-02 și (c) POD-03-vCenter-01. Măsura va reduce situații de conflict în care mai mulți studenți încep a-și crea VM-uri cu același nume or așa moment se mai întâmplă – fiecare își va începe LAB-ul cu un VM cu ESXi nested cu un nume gen ESXi-01.
  • pe pagina Storage, selectăm datastore-ul destinat VM-urilor. De aici, se poate verifica și spațiul liber pe Datastore. Click Next.
  • în Guest Operating System, selectăm OS-ul și versiunea OS-ul pentru viitorul GuestOS din VM. E foarte important ca OS-ul ales să coincidă cu OS-ul din VM – doar în așa caz se poate garanta o funcționare optima a VM-ului. Ca remarcă, pentru un VM destinat unui ESXi nested selectați: OtherOther (64-bit).
  • pe pagina Network , modificăm corespunzător numărul de NIC-uri necesare pe VM prin How many NICs do you want to connect ? după care specifică tipul adaptorului (E1000, vmxnet) și network-ul in care se dorește a fi conectat VM-ul. În drop-down cu network-urile configurate lista le arată pe toate, dar prin design, studenții se pot conecta doar la grupul de port-uri special configurat pentru network-ul de laborator și anume dvPortgroup-STUDENTS. Chiar dacă disponibil la faza de selecție, specificarea unui altui group de porturi decât cel permis va genera o eroare le închiderea wizard-ului de creare a VM-ului cu eșuarea procesului. În imaginea de mai jos, eroarea produsă după ce s-a încercat a se crea un VM într-o altă rețea decât cea admisă pentru lab (LAB_STP_S). 

dnt_vmware_lab_enviroment_p3_vSphere_error_message

  • pe următoarea pagină Create a disk specificăm capacitatea disk-ului virtual în Virtual Disk Size și obligatoriu, modul de alocare a spațiului in Thin Provisioning. Atenție, wizard-ul,  implicit propune modul de alocare Thick Provision așa ca e foarte important a nu se scăpa cu vederea acest settings. Avem nevoie de Thin pentru a folosi cât mai eficient spațiul pe datastore-ul enviroment-ului de laborator.

Note: În principiu, procesul de creare a VM-ului din WEB Client în mare parte coincide cu procesul pe vSphere Client. O mică excepție totuși există, în Web Client la un moment dat se cere de ales vCenter/Datacenter în care să creezi viitorul VM or pe respectivele containere studenții nu au acces. Ca workaround, la acea fază, selectați ca destinație mai jos pe ierarhie folderul TEMPLATES setat în lab pentru stocarea template-urilor de VM-uri. Ca atenționare in plus, pe WEB Client modul de alocare a disk-ului virtual e prezentat și mai puțin evident în fereastra de dialog și la fel implicit e pe Thick așa că double attention here.

How to Enable virtualized HV (Hardware Virtualization) for a VM

Scenariile de laborator vor utiliza pe larg host-uri ESXi nested cu VM-uri nested peste acestea. Pentru a permite rularea de VM-uri nested de 64 biți, va trebui ca pe VM-ul ce găzduiește ESXi-ul nested de activat virtualizarea funcției de virtualizare hardware (VHV). O putem face fie prin a adăugă parametrul vhv.enable=”true” în fișierul de configurație VMX a VM-ului cu ESXi fie prin settings-ul VM-ului din WEB Client. Prima metodă e oarecum mai complicată și are nevoie de permissions în plus per student pe datastore pe când metoda cu GUI e una simplă și comodă. Recomand studenților configurația prin GUI.

Așadar, pentru a activa VHV-ul pe un VM destinat unui ESXi nested se va deschide din WEB Client proprietățile VM-ului cu Edit Virtual Machine Settings  după care din Virtual Hardware – CPU se va bifa parametrul: Hardware Virtualization – Expose hardware assisted virtualization to the guest OS.

dnt_vmware_lab_enviroment_p3_VHV_enable

De remarcat că respectivul parametru va fi imposibil de bifat (grayed out) dacă VM-ul nu are un hardware version de cel puțin vmx-09. Implicit, VM-urile sunt create în versiunea 08 așa că până activa VHV-ul va trebui de upgradat mașina virtuala la o versiune hardware mai superioara (din client deodată pe vmx-10). Pe deasupra, pentru ESXi-uri nested se va specifica ca Guest OS opțiunea cu VMware 5.x.

Temă pentru acasă

Primul scenariu de laborator recomandat pentru studenți este în a:

  • să instaleze 2x servere ESXi 5.5 nested cu alocarea de suficiente resurse ca pentru mai târziu să fie posibilă crearea pe acestea a altor VM-uri (2x vCPU-uri, 8GB RAM, 60GB virtual disk, 4x vmNICs).
  • să realizeze configurația inițială pentru networking-ul ESXi-ului nested.
  • să updateze ESXi-urile noi create până la ultima actualizare disponibilă.
  • să instaleze VMware Tools for nested ESXi.
  • să instaleze într-un VM pe ESXi-ul nested, de la zero, server-ul vCenter 5.5 pe Windows 2k12.
  • să aducă în inventarul vCenter-ului noi instalat host-urile ESXi nested.

Rezultatul primului scenariu de laborator va juca rolul de platformă pentru unele scenarii ulterioare așa că e important ca aici din prima totul să fie făcut corect.

Până aici tot, închei cu descrierea platformei de laborator DNT destinată orelor practice VMware și care poate fi accesată 24 din 24 de oriunde se poate ajunge la Internet. Sper să le fie de mare ajutor studenților mei și ca până la urmă să rămân cu senzația că sa muncit cu folos în acest sistem.

Mediu de laborator pentru studenții claselor de VMware (part II)

În prima parte a articolului am făcut o descriere generală pentru arhitectura enviroment-ului folosit de studenții claselor de VMware pentru executarea scenariilor practice de laborator. În partea a doua voi încerca să intru în detaliile legate de configurațiile pe serverele vCenter, VPN și Proxy. Urmează și o treia parte (ultima) în care voi descrie pas cu pas activități de bază pe mediul de laborator.

Configurație vCenter Server

Server-ul vCenter joacă rolul de aplicație de management pentru resursele server-ului fizic, este realizat ca și mașină virtuală și găzduit pe același server cu mediul de test. Server-ul vCenter va fi accesat de către studenți prin vSphere Client sau vSphere WEB Client pentru ași crea/gestiona propriile mașini virtuale potrivite scenariilor de laborator.

VM-ul pentru server-ul vCenter (LAB-vCenter-01s) are alocat 2x vCPU-uri, 12GB RAM și un spațiu de stocare pe disk de 60GB. Server-ul are două interfețe de rețea: una conectată în rețeaua de producție setată cu IP-ul 10.10.1.45/24 și alta conectată în rețeaua de laborator (izolată) setată cu IP-ul 172.16.0.4/16. Primul IP va fi folosit pentru accesul la vCenter din sălile de studiu DNT iar al doilea IP pentru access prin conexiune remote prin VPN.

Autentificarea pe server-ul vCenter are loc cu utilizatori creați în SSO pe domain-ul vsphere.local. Fiecare student își are propriul username și password. Username-ul e format din nume/prenume separat cu punct. Domain-ul vsphere.local este setat ca default așa că sufixul @vsphere.local poate fi omis la specificarea username-ului in căsuța de autentificare. Password-ul inițial, generat de instructor poate fi schimbat mai târziu de către student prin procedura de change password din interfața web client – mai multe detalii vedeți in partea a 3-a a articolului.

Networking-ul virtual, în laborator, este realizat pe un switch distribuit (dvSwitch-LAB) cu două grupuri de port-uri pre-configurate: (a) dvPortgroup-PRODUCTION și (b) dvPortgroup-STUDENTS, primul cu uplink-uri in rețeaua de producție și al doilea izolat pentru VM-urile din scenariile de laborator. Tehnic, din rețeaua STUDENTS (de laborator) nu ai cum să ajungi în PRODUCTION. Din două grupuri, studenții au dreptul să atașeze VM-uri doar pe grupul STUDENTS, orice tentativă de a accesa grupul de porturi de producție va genera un mesaj de eroare cu access denied. Grupul de porturi STUDENTS este configurat cu Promiscous Mode, MAC Address Changes și Forget Transmis ca Accept – configurație obligatorie pentru ESXi-urile nested conectate pe acel grup de porturi.

Rețeaua de producție are asociat subnet-ul 10.10.1.0/24 și cea de laborator 172.16.0.0/16. Spațiul de adrese /16 în rețeaua de laborator nu este controlată în nici un fel, studenții fiind liberi să utilizeze orice IP le este comod. Totuși, pentru comoditate, am împărțit intervalul în grupe de /24, fiecărui student revenindu-i un spațiu din acestea. Regula e simplă, un POD are asociat un interval 172.16.2X.0/24, unde x e numărul podului (de la 1 la 9), fiecare student cu POD-ul lui. Segregarea pe spații de adrese separate va reduce situațiile cu conflicte de adrese IP. Chiar dacă legați de spații /24 studenții vor continua să folosească mască de 16 biți în configurațiile proprii de rețea.

In laborator, folosim următoarea distribuție de adrese IP: 

dnt_vmware_lab_enviroment_p2_IP_addresses

Pentru a accesa pe mediul de laborator, studenții vor iniția o conexiune VPN prin care vor ajunge să fie conectați în rețeaua STUDENTS și auto-configurați cu un IP din intervalul VPN DHCP. În continuare se poate de mers fie cu conexiune direct de pe PC-ul de acasă prin vSphere Client la serverul vCenter fie printr-o sesiune RDP la VM-ul cu Windows 7 preinstalat și configurat cu toate necesare. Fiecare POD are configurat un VM cu Windows 7, configurat cu networking, remote desktop activat și cu aplicații necesare scenariilor de laborator pre-instalate. VM-urile respective au fost configurate cu al 10-lea IP din intervalul asociat POD-ului. In tabel mai sus, aceste IP-uri sunt prezentate in paranteze.

Accesele la resursele server-ului fizic și pe obiectele vCenter-ului au fost configurate în așa fel încât studenții să fie limitați doar la acțiuni necesare sarcinilor de laborator fără a putea influința configurația globală a mediului de laborator. Mai mult, fiecare student își are propriul container in care poate crea/gestiona VM-uri ne-având privilegii pe containere vecine și alte obiecte in vCenter. 

Configurația accesului pe vCenter se bazează pe:

  • roluri de utilizator custom: (a) Power Users for DNT Students (b) Read Only for DNT Students, primul moștenit din  rolul embedded Virtual Machine Power Users (sample) și respectiv al doilea moștenit din rolul Read-Only.
  • rolul de  Power Users for DNT Students a fost augmentat cu privilegii specifice pentru obiectele Datastore, Virtual Machine și Networking. Privilegiile respective au fost găsite empiric pe parcursul primei săptămâni de exploatare a mediului de laborator.
  • pe SSO-ul vCenter-ului este definită grupa de utilizatori vmware-class-std care include toată lista de utilizatori studenți.
  • pe ierarhie, la nivel de vCenter, grupul vmware-class-std a fost configurat cu rolul de Read Only for DNT Students fapt ce va permite accesul la inventarul vCenter și va asigura vizibilitate read-only peste toate obiectele vCenter.
  • pentru a putea executa activități legate de creare/gestionare VM-uri fiecare student a fost configurat ca Power Users for DNT Students pe container-ul vAPP cu care a fost asociat (un POD per student)
  • pentru avea acces la datastore-ul host-ului ESXi, grupul de utilizatori vmware-class-std a fost configurat ca Power Users for DNT Students pe containerul datastore-ului (Raid10-Store).
  • pentru a putea anexa VM-urile din laborator la networking-ul izolat de lab, grupul de utilizator vmware-class-std a fost configurat ca Power Users for DNT Students pe grupul de porturi dvPortgroup-STUDENTS. Atenție, doar pe grupul de porturi STUDENTS nu și PRODUCTION.
  • pentru a putea re-utiliza template-uri de VM-uri, a fost creat folderul TEMPLATES in view-ul VMs and Templates pe care sa configurat accesul ca Power Users for DNT Students pentru grupul de utilizatori vmware-class-std. Pentru a re-utiliza template-uri, studenții vor copia cu drag-and-drop template-ul nou creat din root-ul arborelui in folder-ul TEMPLATES. După această mișcare template-ul devine disponibil a fi utilizat – mai multe detalii vedeți in partea a 3-a a articolului.

Vedeți mai jos configurația privind alocarea de drepturi pe obiectele vCenter-ului: 

dnt_vmware_lab_enviroment_p2_permissions

Configurație Server VPN

Server-ul VPN permite accesul  remote la mediul de laborator, este realizat ca și mașină virtuală și se bazează pe o soluție SoftEther VPN (Windows). Ca și vCenter, VM-ul cu VPN are două interfețe, una public conectată in rețeaua de producție și configurată cu IP-ul 10.10.1.10 și a alta conectată în rețeaua studenților și configurată cu 172.16.0.1. Pe router-ul DNT-ului la Internet avem configurat un port-mapping de pe IP-ul public 178.168.50.194 pe IP-ul serverului VPN 10.10.1.10 pe port-ul 443. Serverul VPN funcționează pe deasupra și ca server DHCP pentru segmentul STUDENTS cu distribuire de IP-uri din intervalul 172.16.0.100-172.16.0.200. Pe stația remote pentru acces la VPN se instalează SoftEther VPN Client care poate fi descărcat gratuit pe site-ul SoftEther (click aici)

Fiecare student are propria pereche nume utilizator/password cu care se autentifică pe serverul VPN. Username-ul se formează din numele/prenumele studentului separat prin punct. Parola inițială este distribuită de instructor și poate fi oricând schimbată de utilizator. Despre cum de configurat o conexiune nouă pe client și cum de schimbat parola inițială aflați în partea a 3-a articolului.

Pe serverul VPN avem realizate următoarele configurații:

  • virtual HUB (default) configurat în bridge (prin Local Bridge Settings) cu a interfața ce pleacă in rețeaua STUDENTS. Implicit, bridge-ul e format cu interfața în PRODUCTION. Schimbarea bridge-ului pe altă interfață garantează ca conexiunea de VPN să va termina în rețeaua izolată de laborator și nu cea de producție.  

De remarcat că pentru a funcționa corect, interfața bridged a serverului VPAN (partea STUDENTS) trebuie conectată într-un grup de port-uri pe switch-ul virtual în care Promiscous Mode este in Accept or acest requirement în cazul nostru este asigurat automat. Așa cum menționasem mai sus grupul de porturi STUDENTS are configurat Promiscous Mode împreună cu celelalte două politici în Accept.

  • VPN-ul este configurat cu Split Tunneling astfel încât, odată conectat pe VPN, utilizatorul continuă să acceseze rețelele proprii și Internet-ul prin propria conexiune Internet și nu prin link-ul de VPN – pe client, apare o singură rută: cea spre rețeaua 172.16.0.0/16 ca directly connected prin interfața VPN-ului.
  • restul configurațiilor pe serverul SoftEther VPN rămân în condiția lor implicită

Configurație Proxy Server

Destinația inițială a server-ului Proxy a fost in a asigura accesul la WEB-ul (http, https) Internet-ului din rețeaua izolată de laborator. In lab, poți avea nevoie de Internet atunci când de exemplu dorești să aplici actualizări pe un ESXi nested or să descarci un tool sau orice altceva. În astfel de cazuri, pentru a accesa Internet-ul trebuie doar de configurat în proxy settings adresa private a server-ului proxy 172.16.0.39 cu portul 8080. Ca remarcă, toate VM-urile cu Win7 pe care studenții intră prin RDP au deja pre-configurate proxy server (tot aici, bifat bypass proxy server for local addresses și adăugat ca excepție network-ul 172.16.*.*).

Pe parcurs, ca workaround la o problema reachability, serverul Proxy a fost configurat și ca port mapping cu scopul de a permite accesul din rețeaua izolată de laborator la IP-ul de management vmk0 a host-ului ESXi aflat in rețeaua de producție. Mapping-ul e făcut doar pentru câteva porturi necesare funcționarii consolei la VM-uri din vSphere Client (TCP: 902, 9443, 443).

Problema de reachability menționată se descrie simplu: din moment ce deschizi din vSphere Client consola la un VM, client-ul inițiază o conexiune TCP pe portul 902 direct pe vmk0 a host-ului ESXi chiar daca vSphere Client este conectat pe IP-ului serverului vCenter. Consola folosește un path direct de la client la ESXi ocolind serverul vCenter. Așa cum, în arhitectura mediului de laborator vmk0 (interfața de management ESXi) este configurată pentru rețeaua de producție (cu IP-ul 10.10.1.120) rezultă că orice tentativă de a deschide o consolă la un VM din rețeaua de laborator duce într-o consolă failed și un mesaj cu reachability issues .. unable to connect.

Pentru a explica soluția realizată prin proxy, vedeți pentru început următoarea reprezentare grafică (errata: in desen numărul portului 903 trebuie inlocuit cu 902): 

dnt_vmware_lab_enviroment_p2_port_proxy_conf

In schemă avem 2x VM-uri, primul e VM-ul cu PROXY și al doilea un VM cu Win7. Serverul PROXY este conectat în același timp și in rețeaua de producție (PRODUCTION) împreună cu management-ul ESXi (vmk0) și în rețeaua de laborator (STUDENTS). VM-ul cu Win7 e conectat doar in rețeaua de laborator. In momentul in care se încearcă a deschide consola la un VM, aplicația vSphere Client inițiază o conexiune directă la managementul ESXi ocolind serverul vCenter. Așa conexiune nu are cum să aibă loc pentru că clientul și managementul ESXi se află în rețele diferite.

Ca workaround la problema descrisă s-au făcut următoarele configurații:

  • pe VM-urile cu Win7 s-au creat interfețe Loopback pe care s-au setat IP-ul de management a host-ului ESXi 10.10.1.120/32. Așa cum, in rețeaua de laborator nu exista un default gateway, loopback-ul va permite un routing pentru IP-ul ESXi-ului. Comunicațiile pentru 10.10.1.120 se vor întoarce în stack-ul de networking.
  • pe VM-urile cu Win7 s-au configurat translări de adresă IP prin așa numite port proxy-uri, create cu netsh. Port proxy-ul se setează per port și face translarea adresei destinație dintr-un IP în alt IP. Minim pentru deschiderea consolei avem nevoie de translare pentru portul TCP 902, totuși pentru siguranță fiecare stație mai are translare și pentru porturile 9443 și 443. Următorul code batch a fost executat pentru crearea translărilor port proxy (primele 3x linii, ultimele 3x e codul care le distruge): 

dnt_vmware_lab_enviroment_p2_port_proxy_cmd

Efectul port proxy-ului este ca ori de câte ori întră în stack-ul de networking un pachet cu destinație 10.10.1.120 și port 902 acesta să fie translat intr-un pachet cu destinație 172.16.0.39 cu același port. Altfel spus, pentru cazul nostru, toate pachetele destinate comunicațiilor consolei de VM-uri din vSphere Client vor fi supuse translării respective.

  • pe server-ul proxy este configurat o translare cu efect invers și anume destinația pe 172.16.0.39 pe port-ul 902 va fi translată în 10.10.1.120 pe același port. Modul realizării configurației depinde de soluția serverului proxy, pentru cazul nostru unde am folosit un CCProxy, settings-ul arată așa:

dnt_vmware_lab_enviroment_p2_port_map_proxy_server

Așadar, dacă e să parcurgem acum calea comunicațiilor pentru consola pe VM aceasta ar trece prin următoarele faze:

  • consola inițiază o conexiune pe IP-ul de management a host-ului ESXi 10.10.1.120 pe portul 902.
  • pachetele cu destinație 10.10.1.120 ajung pe interfața Loopback după care sunt întoarse în stack-ul de networking
  • întoarse pachetele sunt translate din destinația 10.10.1.120 pe IP-ul server-ului proxy 172.16.0.39 (doar acele pachete ce au ca destinație 10.10.1.120 și port destinație 902)
  • pachetele translate sunt plasate pe cealaltă interfața din VM 172.16.21.10 și sunt livrate către VM-ul cu serverul Proxy.
  • ajunse pe server-ul Proxy pachetele inițiate de aplicația consolei sunt supuse unei translări repetate prin care IP-ul destinație 172.16.0.39 este translat la valoarea inițială de 10.10.1.120 astfel încât să fie posibilă livrarea către interfața de management ESXi. (vor fi translatate doar pachetele cu IP-ul destinație 172.16.0.29 și port 902)
  • pachetele translate repetat vor fi plasate pe stack-ul de networking unde vor fi rutate pe interfața legată în rețeaua de producție (10.10.0.39)
  • în final pachetele vor ajunge pe interfața de management ESXi vmk0 cu IP-ul 10.10.1.120.

Pe desenul de mai sus, path-ul cu translări de IP-uri este ilustrat cu săgeți linie continue albastre.  Path-ul logic este ilustrat cu linie orange întreruptă.

Trebuie să recunosc că există o soluție mai simplă la problemă, însuși studenții mi-au sugerat-o atunci când le povesteam de arhitectură. Adevărul e că se poate și fără de interfața de loopback, IP-ul 10.10.1.120 poate fi liber setat ca secondary IP pe prima interfață – verificat, funcționează. Cool, încântat de așa studenți.

Aici pun punct descrierii detaliilor de configurație la serviciile ce fac ca mediul de laborator să funcționeze. În partea a 3-a (ultima) am să descriu într-o manieră How To mai multe activități pe care le poate executa un student pe mediul de test.

Mediu de laborator pentru studenții claselor de VMware (part I)

Ca parte a ofertei de curs VMware, DNT Training Center oferă studenților săi acces la resursele proprii de laborator. În cadrul orelor practice fiecare student poate accesa capacități rezervate pentru realizarea individuală a oricărui scenariu de laborator. Mai nou, mediul de laborator DNT poate fi accesat deja și de acasă și este disponibil 24/24. Astfel, studenții noștri pot accesa resursele de laborator oricând le este comod și de oriunde au acces la Internet. Legătura se realizează printr-o conexiune VPN peste Internet. Specificul laboratoarelor VMware, in comparație cu cele din alte cursuri, e că aici e nevoie de resurse hardware considerabile. Dacă la Cisco spre exemplu îți era suficient un PC de o capacitate medie pentru a rula Packet Tracer-ul sau/și GNS3-ul aici ai nevoie de mult mai mult – un singur PC dacă nu e dotat cu discuri SSD și cu memorie RAM peste 10GB poate să nu-ți fie suficient. Printr-un enviroment de laborator accesat de acasă încercăm să acoperim acest neajuns în așa fel încât studenții să obțină cunoștințe și deprinderi practice de cea mai înaltă calitate. În cele ce urmează, am să încerc să descriu cum a fost realizat proiectul mediului de laborator, configurațiile specifice pe acesta și unele recomandări pentru studenți. Voi organiza conținutul pe 3x parți:

  1. Part I (curent): prezentare generală, descriere arhitectura.
  2. Part II: detalii configurație servere vCenter, VPN, WEB Proxy
  3. Part III: ghid How to pentru studenți

Arhitectura mediului de laborator

Pentru început, să vedem ce obiective trebuiau asigurate de viitorul mediu de laborator:

  • acces 24 din 24, de oriunde este access la Internet-ul (acasă, serviciu)
  • acces controlat prin nume utilizator și password – personal per student
  • resurse hardware rezervate pe fiecare student in parte
  • capacitate de a rula host-uri ESXi nested cu VM-uri nested pe acestea
  • mediul de laborator izolat de rețeaua de producție DNT
  • acces la mediu de lab inclusiv și din sălile de studiu DNT

Mediul de laborator e construit pe un singur server fizic, supradotat, resursele căruia sunt partiționate între studenți cu o parte din ele rămânând rezervate pentru propriile servicii. Serverul fizic are instalat VMware ESXi 5.5 gestionat de un server vCenter Server 5.5 realizat ca și mașină virtuală pe același mediu. Adițional, alte două VM-uri lucrează pentru a asigura serviciile de VPN și Web Proxy. Studenții vor folosi resursele alocate prin crearea de mașini virtuale proprii care vor funcționa fie ca gazde pentru host-uri ESXi nested fie ca servere pentru unele servicii necesare scenariilor de laborator.

Serverul fizic reprezintă un workstation model DELL Precision T5500 dotat cu următoarele resurse hardware:

  • două procesoare Intel Xeon X5570, 2,93GHz, 8MB cache, 4 core-uri cu HT, care în sumă ne asigură un total de 16 procesoare logice.
  • o capacitate RAM de 144 GB, DDR3-1333Mhz, ECC Registered Memory
  • controller de disk-uri RAID Controller (PERC) H310, no WT/WB cache. UPD:01.05.2015 (PERC) H700, read cache/write back cache, cache memory size 512 MB, BBU.
  • 8x disk-uri SATA 2.5'', 300GB, 10K RPM configurate într-o matrice RAID 10, care în ansamblu de asigură un total de 1.2 TB capacitate de stocare alocabilă și un aproximativ de 500 IOPS pe write  și 1000 IOPS pe read. Întreaga capacitate formează datastore-ul VMFS pentru stocare VM-urilor din laboratoare.
  • adițional 2x disk-uri SATA, 300GB conectate direct în controler-ul pe motherboard, folosite separat ca două datastore-uri VMFS pentru stocarea de imagini ISO și template-uri de VM-uri.
  • 3x adaptoare de rețea GbE, unul embedded in motherboard (Broadcom BCM5761) și celelalte 2x ca parte dintr-o extensie PCIe (Intel 82571EB). In general, adaptoarele vor funcționa în paralel într-un team activ conectate la rețeaua de producție cu excepții pentru câteva laboratoare realizate in clasă în care două din NIC-uri vor fi re-comutate pe switch-urile Cisco din kit-ul de CCNA/CCNP.

Să analizăm acum elementele ce formează arhitectura mediului de laborator VMware DNT. Pentru o reprezentare grafică vedeți schema de mai jos. 

dnt_vmware_lab_enviroment_p1_lab_architecture

Așadar, următoarele elemente formează arhitectura mediului de laborator:

  • host-ul ESXi – serverul fizic despre care s-a vorbit mai sus, are instalat un ESXi 5.5 (la momentul articolului în build: 1623387 – 5.5 update 1). Imaginea ESXi a fost instalată pe un removable flash memory stick de 4GB, montat într-un port USB intern.
  • networking-ul fizic de la host-ul ESXi la router/switch-ul intern DNT (CRS125-24G-1S-2HnD-IN). Implicit, toate 3x NIC-uri pe host-ul ESXi sunt conectate la rețeaua DNT (team).
  • la nivel de IP, partea de producție din rețeaua enviroment-ului de la lab e separată de networking-ul din sălile de studiu și Wi-Fi. Pentru aceasta pe router-ul DNT a fost creat un network aparte asociat cu un subnet în intervalul 10.10.1.0/24. În acest network este conectat vmk-ul de management a host-ului ESXi, precum și câte una din interfețele VM-urilor vCenter, Proxy, VPN (interfața public)
  • partea de lab din rețeaua mediului de laborator e formată pe un grup de porturi izolat (fără uplink-uri în networking-ul fizic) pentru care se recomandă folosirea intervalului de IP-uri 172.16.0.0/16. Aici se vor conecta VM-urile din scenariile de laborator și tot aici prin interfețele secundare (interfața private) sunt conectate VM-urile serviciilor vCenter, Proxy, VPN. VM-urile create în laborator pot fi anexate doar pe acest network și orice tentativă de a te conecta pe celălalt group de porturi (producție) va duce inevitabil la eroare de drepturi de acces. E lesne de înțeles că de aici nu se poate de ajuns în rețeaua de producție.
  • server vCenter Server 5.5, element central în arhitectura mediului de laborator, folosit pentru gestionarea și accesul la resursele host-ului ESXi fizic. Configurat cu două interfețe, una in rețeaua de producție cu IP-ul 10.10.1.45 și alta în cea de laborator cu IP-ul 172.16.0.4. Studenții se vor conecta la server-ul vCenter cu vSphere Client or cu Web Client, folosind IP-ul 172.16.0.4, pentru a crea/controla VM-uri din propriile scenariile de laborator. Pe server-ul vCenter (SSO) sunt definiți utilizatori (vsphere.local) pentru fiecare student în parte, grupuri de utilizatori, roluri și permisiuni pe obiecte din inventar.
  • server WEB Proxy pentru access din rețeaua izolată de la laborator la rețeaua Internet. Are două interfețe, una conectată in rețeaua de producție și are configurat IP-ul 10.10.1.39 și alta în rețeaua de laborator cu IP-ul 172.16.0.39. Proxy-ul folosește port-ul TCP:8080. Pe client, pentru a accesa Internetul va trebui de configurat corespunzător proxy settings.
  • server VPN pentru acces remote din Internet la rețeaua de laborator. Are două interfețe, una în rețeaua de producție configurată cu IP-ul 10.10.1.15 și alta în rețeaua de laborator cu IP-ul 172.16.0.1. Fiecare student folosește propriul set username și password. Odată conectat, PC-ul remote ajunge în rețeaua de laborator și se auto-configurează prin DHCP cu un IP din intervalul 172.16.0.100-172.16.0.200.  Pe router-ul DNT, este configurat un port mapping intre IP-ul public DNT 178.168.50.194 și IP-ul server-ului VPN 10.10.1.15 pe portul 443. Server-ul VPN, este configurat să primească conexiuni pe portul TCP:443.
  • VM-uri cu Windows 7 pre-instalat și pre-configurat pentru fiecare student. VM-urile sunt conectate in rețeaua de laborator, pre-configurate manual cu un IP, Remote Desktop pornit și au pre-instalate vSphere Client și Chrome Browser. Odată conectat la mediul de laborator, studenții își deschid prin RDP propriul desktop cu Windows din care încep a-și execută task-urile necesare scenariului de laborator. Ca alternativă, e posibil și lucru cu vSphere Client (WEB Client) printr-o conexiune directă de pe PC-ul de acasă, dar asta cu siguranță va însemna un GUI mai greoi din cauza bandwith-ului redus la conexiunea de Internet a DNT-ului. VM-urile cu Windows 7 folosesc toate același password:asdfgh1! pentru utilizatorul Administrator.
  • pool-uri de resurse sub forma de vApp-uri pentru fiecare student in parte. La nivel de vApp se configurează rezervarea de RAM (câte 10GB de memorie garantată) și drepturile de acces per student. Studenții vor putea crea VM-urile doar in contextul vApp-ului de care a fost asociat. 

Vedeți mai jos screen-ul la inventarul server-ului vCenter pe mediul de laborator VMware DNT. Se observa clar VM-urile de infrastructura (vCenter, VPN, Proxy) și pool-urile de resurse alocate studenților (STD-POD-A01..A09).

dnt_vmware_lab_enviroment_p1_vCenter_inventory

Serverul fizic este montat pe poliță în rack-ul echipamentelor de laborator DNT, alături de routere și switch-uri Cisco și e conectat la o sursă de alimentare neîntreruptibilă UPS. Așa cum rack-ul cu echipamentul de laborator se află în una din sălile de studiu DNT, a fost important ca server-ul nou să fie unul cât mai silențios – de unde și decizia de a folosi un echipament de tip workstation pe rol server în loc de un server Rack Mounted, ultimul generând un nivel de zgomot considerabil.

dnt_vmware_lab_enviroment_rack_mount

În următoarele părți din articol voi descrie configurațiile specifice pe serverele vCenter, VPN, Proxy precum și un guide How To pentru cele mai de bază acțiuni pe mediul de laborator.

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)

Captură frame-uri dot1q in Wireshark dintr-un VM pe ESXi

Într-un test de laborator recent am încercat să realizez o captură de pachete pentru frame-urile ce tranzitează o interfață trunk pe un switch Cisco. Pentru aceasta, am folosit o mașină virtuală pe un ESXi pe care am instalat Wireshark-ul. VM-ul l-am conectat pe un switch virtual dedicat al cărui singur uplink l-am cuplat direct la switch-ul fizic. Pe switch-ul virtual grupul de porturi a fost configurat cu transport de VLAN-uri către VM-uri – mod cu Virtual Guest Tagging (VLAN ID = 4095) și in regim cu Promiscous Mode = Enabled setat din politicile de securitate pe grup. Portul spre ESXi pe switch-ul fizic l-am configurat ca destinație de mirroring la interfața trunk monitorizată. Schema conexiunilor o vedeți mai jos:

dot1q_tagged_capture_scheme

Până aici totul a fost simplu și mă așteptam ca totul să funcționeze corect, dar nu a fost așa. E adevărat că din moment ce am pornit captura, pachetele aparținând mai multor VLAN-uri au început să ajungă în raportul de Wireshark. Totul părea as expected cu o singură dar importantă excepție: frame-urile înregistrate erau lipsite de header-ul lor original fiind re-încapsulate în frame-uri non-802.1q. Acestea arătau ca și cum făceau parte dintr-un singur VLAN și doar informațiile din header-ul IP-ului mai sugera VLAN-ul origine a pachetelor.

dot1q_tagged_capture_dot1q_stripped

Colegul meu Iurie mi-a sugerat o explicație pentru fenomenul observat. Adevărul e că unele drivere de NIC-uri in configurația lor implicită sunt obligate să re-încapsuleze frame-urile cu tag 802.1q în frame-uri Ethernet fără tag-uri. Așa de exemplu o fac NIC-urile Intel și Broadcom (more info). În VM-ul cu Wireshark am folosit un adaptor Intel emulat (E1000) care se pare că in configurația sa are același comportament ca și conterpart-ul lui fizic – acela de a lipsi frame-urile de header-ul original 802.1q. Mi-a venit atunci în cap să înlocuiesc vNIC-ul din VM cu un alt model disponibil dar se pare că până la urmă E1000 instalat inițial rămâne a fi unica opțiune funcțională. Să revizuim fiecare tip de adaptor disponibil pentru VM-uri pe un host ESXi (pentru mai multe informații totuși, vedeți articolul VMware KB1001805):  

  • adaptor Flexible ce poate funcționa fie in regim cu emulare a dispozitivului AMD PCnet32 (VLANCE) fie in regim sintetic ca vmxnet funcție de disponibilitatea componentelor vmware tools. Nici unul din dispozitive nu știe să opereze cu frame-uri 802.1q – acestea sunt pur și simplu ignorate de vNIC, cel mai probabil pentru că dă un CRC greșit.
  • vmxnet2, vmxnet3 – dispozitive sintetice care înțeleg frame-uri 802.1q dar care totuși sunt limitate în configurația pe driver. Bunăoară, un astfel de dispozitiv poate fi asociat doar cu un singur VLAN, frame-urile din restul VLAN-urilor fiind ignorate. Un VLAN se asociază cu un NIC vmxnet2/3 prin parametru VLAN ID din setările Advanced Settings pe NIC (vezi screen-ul de mai jos)

REM: Se pare că există o excepție pe Linux pentru vmxnet3 care accepta asocierea cu mai multe VLAN-uri (more info in additional information din KB1004252) dar încă nu am verificat să văd cum e.

  • E1000, E1000e – NIC-uri ce emulează dispozitivele Intel 82545EM (Intel PRO/1000 MT)  și respectiv Intel 82574. Ultimul mai nou, disponibil doar in Guest OS-uri recente. Pe un Windows 7/ Windows 2008R2 poate fi instalat doar E1000. Ca și analogul fizic dispozitivele emulate știu să interpreteze frame-uri 802.1q.

Așadar, din toate opțiunile posibile doar E1000 rămâne a fi valid pentru use case-ul nostru. În teorie, pe un VM cu un adaptor E1000 s-ar putea de interpretat frame-uri cu header 802.1q ba chiar să le lăsăm să treacă nemodificate mai sus spre o aplicație Wireshark. Implicit, E1000 scoate header-ul 802.1q așa că va trebui să ajustăm unii parametri din configurația driver-ului ca acesta să lase frame-urile nemodificate.

De menționat că la adăugarea unui dispozitiv E1000 la un VM, de regulă, automat sunt instalate driverele distribuite cu sistemul de operare (in cazul meu MS Windows). Acestea diferă de cele originale Intel și sunt limitate ca posibilități de configurații adiționale. Așa că pentru început va trebui să înlocuim driverele Microsoft cu drivere Intel. Pentru un ghid detaliat revizuiți KB-ul VMware: KB1004252. In KB scopul înlocuirii driver-ului e pentru a face posibilă instalarea extensiilor Intel Advanced Network Services (ANS) – din care mai departe să se creeze sub-interfețe asociate cu mai multe VLAN-uri și e altul decât scopul nostru de a modifica configurația driver-ului în așa fel încât frame-urile să treacă cu header-ul lor original. Pe scurt, pentru a înlocui driver-ul pentru un NIC E1000 într-un VM cu OS Windows:

  • se descarcă pachet-ul de instalare ce conține driverul pentru Intel PRO/1000 MT. Articolul dă un link direct dar poate fi gasit cu search pe pagina de download Intel.
  • se despachetează pachet-ul de instalare (prowinx64.exe) – eu am folosit WinRAR-ul.
  • manual se instalează driver-ul dispozitivului. Din proprietățile adaptorului se accesează Update Driver Software Browse my computer .. – Let me pick from a list of .. – Have Disk după care se specifică calea către fișierul inf: pro1000\winx64\ndis61\e1g6032e.inf.

REM: De menționat că driverele pot fi instalate doar in regim manual așa cum e descris mai sus, executarea directă a pachetului de instalare nu instalează drivere – acesta e destinat pentru instalarea extensiilor Intel Advanced Network Services (ANS)

  • se reboot-ează VM-ul. Din acest loc dacă e nevoie pot fi instalate și extensiile ANS (care arată ca tab-uri in plus in fereastra standard de configurare a unui NIC). Prin ANS se pot realiza mai multe configurații suplimentare gen sub-interfețe asociate cu VLAN-uri, team-inguri de high availability și load balancing ș.a.m.d Chiar dacă oferă configurații in plus ANS-ul nu are settings-ul căutat de noi pentru livrarea nemodificata a frame-urile dot1q prin NIC spre aplicații.

În screen mai jos, Advanced Settings pentru un adaptor VMXNET3 și tab-uri de configurație Intel Advanced Networking Services în fereastra de configurație a unui adaptor E1000 (Intel PRO/1000 MT):

dot1q_tagged_capture_NIC_advanced_settings

Acum că ne-am înarmat cu drivere originale Intel, putem încerca re-configurarea driver-ului pentru ca acesta să lase nemodificate frame-urile cu header dot1q. Pentru un sistem de operare Microsoft Windows pașii de parcurs sunt descriși în următorul articol Intel: My Sniffer is Not Seeing VLAN, 802.1q, or QoS Tagged Frames și de fapt se reduc la introducerea în regiștrii sistemului de operare a parametrului MonitorModeEnabled=1.  Din articol, MonitorModeEnabled=1 e descris ca: „(Store bad packets. Store CRCs. Do not strip 802.1Q vlan tags)  și este exact ceea ce căutăm.

De aici încolo lucrurile au început să nu mai funcționeze. Am încercat pașii descriși în articol pentru reconfigurarea driver-ului dar fără nici un efect, toate frame-urile tagged ca și înainte erau re-încapsulate în frame-uri non-dot1q. Posibil am dat de un bug, posibil să fi făcut eu ceva greșit dar până la urmă așa și nu a mai funcționat. Dacă cuiva totuși i sa primit configurația, scrieți-mi un mail, sunt nerăbdător să confirm că funcționează.

Așa cum procedeul de mai sus nu a mai fost posibil, până la urmă am găsit o altă soluție alternativă. Se pare că pe sistemele de operare Linux driver-ul pentru PRO/1000 MT in configurația lui implicită nu re-încapsulează frame-urile dot1q, fapt remarcat în articolul Intel menționat mai sus: „For Linux … By default, the driver in promiscuous mode does not strip VLAN tags.În așa fel, soluția finală a fost să re-instalez in VM-ul cu Windows un distributiv Linux (am folosit Ubuntu) pe care am pus Wireshark-ul. Fără nici o setare in plus, după pornirea capturii, Wireshark-ul a început să înregistreze frame-uri în formatul lor original, nemodificate, cu header 802.1q. Includ mai jos un screen cu detaliile la câteva pachete înregistrate in VM-ul cu Linux.

dot1q_tagged_capture_dot1q_Linux_notstripped

Articole menționate în text:

 

Explicație pentru vSwitch Security Policies

Uneori, pentru a explica studenților mei cât mai simplu subiecte complexe recurg la prezentări prin modele. Așa am ajuns să construiesc modelul de mai jos pentru a lămuri simplu (sper că a ieșit mai simplu) setările pentru politicile de securitate pe un switch virtual VMware. 

vswitch_security_policies_first_screen

Așadar, să le luăm pe rând (pe schemă de jos in sus ):

  • tubul de jos e un switch-ul virtual (vSS sau vDS)
  • pe switch avem un port (chenar galben) la care avem conectat un VM (de sus)
  • portul pe switch/VM are două conducte: una pentru traficul de intrare (ingress) și alta pentru traficul de ieșire (eggress). În documentația VMware direcția traficului se definește în raportul cu port-ul pe switch-ul virtual.
  • portul pe switch este dotat cu robinete pentru ambele direcții. Robinetele pot fi in una din două poziții: deschis – traficul trece prin conductă, închis – traficul este blocat. Ambele robinete funcționează în ansamblu: ambele se închid și deschid in același timp.
  • poziția robinetelor pe portul pe switch este dirijată de hypervizor (atenție nu de administrator prin settings-ul MAC Address Changes), detalii urmează.
  • mai sus pe schemă ajungem pe portul NIC-ului din interiorul VM-ului (chenar galben).
  • portul pe VM are câte un filtru dirijat montat pe conducte pentru fiecare direcție: unul pentru traficul de ieșire din VM (stânga) și altul pentru traficul de intrare (dreapta).
  • filtrele sunt dirijate și pot avea două poziții: fie filtrează (reject) fie sunt deschise (accept).
  • filtrele sunt pentru blocarea unui anumit tip de trafic și nu pentru tot traficul integral.
  • filtrul pentru traficul de ieșire din VM (stânga) este controlat de valoarea pentru Forget Transmits din configurația switch-ului sau a grupului de porturi (vezi screen mai jos, fereastra din stânga).
  • filtrul pentru traficul de intrare din VM (dreapta) este controlat de valoare pentru Promiscous Mode din configurația switch-ului sau a grupului de porturi (vezi screen mai jos, fereastra din stânga).
  • spre deosebire de robinetele MAC Address Changes dirijat de hypervizor filtrele din portul VM-ului sunt dirijate direct de administrator prin setările promiscous și forget.
  • pe fiecare filtru este montat câte un contor (manometru) pentru numărarea octeților/pachetelor ce tranzitează conductele RX/TX.
  • contoarele sunt realizat in Guest OS. De exemplu pe un sistem de operare Microsoft Windows acestea pot fi citite din Activity pe statutul la Local Area Connection Settings (în screen mai jos, fereastra din dreapta, activity)
  • este foarte importantă poziția contoarelor în raport cu filtrul. Bunăoară, pachetele ce întră în VM-uri sunt numărate după filtru, astfel încât sunt numărate doar pachetele ce au trecut de filtru. Identic și pentru contorul pachetelor ce părăsesc VM-ul acesta va număra doar pachetele ce au trecut de filtru.

vswitch_security_policies_second_screen

  • valorile implicite pentru setările din politică sunt: (a) Promiscous Mode: Reject, (b) MAC Address Changes: Accept, (c) Forget Transmis: Accept. Acestea pot fi setate la nivel de switch și suprapuse (override) la nivelul grupului de port-uri. Pentru un switch distribuit VMware e posibilă suprapunerea setărilor și la nivelului unui port specific de VM.
  • pe desen, mai sus de port-ul VM-ului se află Guest OS-ul și aplicațiile

Să luăm pe rând fiecare opțiune din politică.

Promiscous Mode

In regim normal un nod de rețea conectat într-un switch Ethernet primește doar frame-uri Ethernet destinate lui, adică frame-uri a cărui adresa MAC destinație coincide cu propriul MAC. Aici se mai adaugă și frame-urile broadcast – cele ce au o adresa destinație cu toți de 1. Configurația cu Promiscous Mode setat în Reject corespunde exact acestui mod de funcționare – cadrele a cărui MAC destinație nu coincid cu MAC-ul VM-ului sunt blocate pe filtrul de intrare (promiscous). Contorul pachetelor RX din Guest OS va număra doar frame-urile trecute de filtru.

Pe de altă parte dacă Promiscous Mode este setat in mode Accept, filtrul de intrare nu mai blochează frame-urile străine VM-ului lăsându-le să treacă fără obstacole. Practic, configurarea Promiscous in Accept înseamnă transformarea grupului de porturi în porturi de HUB.

Când avem nevoie de regimul promiscous in accept ? Atunci când se dorește ascultarea traficului dintr-o rețea (sniffing), de exemplu in scenarii cu servicii IDS/IPS in VM-uri. VM-ul cu IDS/IPS se conectează intr-un grup de porturi configurat cu promiscous mode setat in accept.

Configurarea regimului Promiscous in Accept trebuie făcut cu atenție și doar dacă e argumentat. Adevărul e că din moment ce se acceptă trecerea pachetelor străine in VM-uri acestea din urmă devin responsabile de prelucrarea pachetelor care cândva erau blocate de hypervizor și asta nu înseamna nimic altceva decât overhead in plus pe VM-uri. Din interes, urmăriți într-un experiment simplu contorul pachetelor recepționate pe un VM conectat intr-un grup de porturi setat cu promiscous in mode accept.  Lăsați VM-ul silențios ca activitate de rețea. Într-un final veți urmări valori în schimbare pentru contorul pachetelor recepționate chiar dacă acestea nu aparțin VM-ului. Totuși, dacă e nevoie de promiscous in accept pentru un VM conectat într-un grup de porturi se recomandă separarea acestuia de restul VM-urilor intr-un grup de port-uri aparte pe care se va activa regimul promiscous. Astfel, VM-urile din grupul inițial nu vor fi afectate de regimul promiscous. Pentru un switch distribuit (vDS) promiscous mode in activ poate fi setat per port așa că aici lucrurile sunt mai simple.

Forget Transmits

Filtrul Forget Transmits funcționează pe direcția de ieșire a pachetelor din VM și blochează toate frame-urile a căror MAC sursă nu coincide cu MAC-ului VM-ului (de fapt MAC-ul efectiv pe NIC-ul respectivului a VM).

Apare o întrebare: De unde in Guest OS să se ia frame-uri a căror MAC sursă diferă de MAC-ul VM-ului ? Răspunsul e simplu, din aplicații și aici am in vedere aplicații de genul GNS3 cu routere conectate prin cloud la un network extern sau VM-uri intr-un VMware Workstation sau ESXi nested.

Implicit e setat ca Accept. 

MAC Address Changes

Configurația pentru MAC Address Changes dirijează cu capacitatea hypervizorului de a bloca portul (robinetele) pe virtual switch in cazuri când Guest OS-ul întreprinde tentative de substituire a adresei MAC setată inițial pe NIC-ul VM-ului. Mai precis, daca MAC Address Changes e setat ca Reject hypervizorul va bloca robinetele odată cu modificare adresei MAC asociate inițial cu NIC-ul VM-ului și invers dacă MAC Address Changes este setat ca Accept hypervizorul va ignora orice tentativă de substituire a adresei  MAC și va lăsa robinetele tot timpul deschise. Pe scurt, dacă am numi adresa inițială setată pe NIC (BIA) ca MAC[i] (initial) și adresa MAC substituită MAC[e] (efective) atunci efectul la MAC Address Changes s-ar putea de prezentat astfel:

  • Pentru MAC Address Changes = Reject (a) dacă MAC[i]<>MAC[e] atunci blochează robinetele sau (b) dacă MAC[i]=MAC[e] atunci lasă robinetele deschise
  • Pentru MAC Address Changes = Accept indiferent daca MAC[i] coincide sau nu cu MAC[e] robinetele sunt lăsate neatinse de MAC Address Changes.

De remarcat, că contorul din Guest OS pentru pachetele ieșite din VM vor fi numărate chiar dacă portul a fost blocat de MAC Address Changes și e de la sine înțeles că în același timp contorul pentru pachete primite va rămâne intact.

Important de menționat faptul că MAC Address Changes nu reacționează în nici un mod la frame-urile generate din aplicații (GNS3, VMware Workstation .. ) dor la cele a sistemului de operare, la fel cum și filtrul Forget Transmits nu poate filtra frame-uri din OS cu adresa MAC substituită. Confirmat in teste pe laborator.

Implicit este setat ca Accept.

Menționasem mai sus că hypervizorul detectează substituirea in OS a adresei MAC setate pe NIC. Întrebarea e: Cum e posibil asta ? Nu am un răspuns confirmat dar intuiesc că lucrurile stau cam asa: Odată ce se încarcă sistemul de operare valoarea pentru adresa MAC burrned (ROM) in NIC-ul VM-ului este citită și plasată pe o adresă well know din RAM-ul VM-ului. Adresa well know poate fi una common pentru toate sistemele operare sau specifică per OS. Sistemul de operare va folosi această valoare ca adresa MAC sursă pentru toate frame-urile generate de SO. Acum, dacă se intervine, din OS se poate schimba valoarea MAC-ului din RAM într-o altă valoare (effective MAC) în așa fel încât frame-urile ulterioare să plece deja cu MAC-ul nou. Substituirea MAC-ului mai este numită MAC address spoofing și e folosită in unele scenarii de atac de rețea. Dat fiind faptul că VM-ul aparține hypervizorului, acesta din urmă are acces la RAM-ului VM-ului și deci poate citi direct valoarea MAC-ului substituit de pe adresa well know menționată mai sus. In așa fel hypervizorul poate să compare valoarea adresei MAC atribuită inițial și valoarea de facto folosită de OS și in continuare în funcție de MAC Address Changes poate bloca sau nu porturile pe switch.

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.