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.

Configurații cu VLAN-uri pe un virtual switch

Oferta produselor de virtual networking disponibile pe host-urile de virtualizare VMware ESXi constituie astăzi soluții complete și mature pentru nevoile de comunicații ale mașinilor virtuale. Switch-urile virtuale VMware (standard/distribuit) ne permit să construim rețele sigure, robuste, scalabile și în același timp flexibile. Ar fi de neconceput ca în produsele de virtual networking să lipsească mecanismul rețelelor virtuale VLAN or avantajele acestora ca flexibilitate și securitate sunt greu de estimat. VMware implementează standardul 802.1q pentru crearea și transportul prin trunk-uri a rețelelor virtuale LAN. Configurația VLAN-urilor se realizează la nivelul grupurilor de porturi și pot fi transportate prin interfețe fizice către switch-uri externe sau chiar direct în interiorul VM-urilor.

Configurațiile pentru VLAN-uri pe un switch virtual VMware sunt posibile în una din următoarele trei variante disponibile (fiecare în parte sau mixt):

  • VLAN tagging/untagging pe switch-ul virtual (Virtual Switch Tagging sau VST)
  • VLAN tagging/untagging direct în Guest OS (Virtual Guest Tagging sau VGT)
  • VLAN tagging/untagging pe switch-ul fizic extern (External Switch Tagging sau EST)

Să analizam pe scurt fiecare mod de configurare în parte: 

VLAN_configurations_virtual_switch_all_modes

Primul caz presupune o conexiune de tip trunk 802.1q de la host-ul ESXi la switch-ul extern, prin care primul va primi/transmite din/în exterior frame-uri Ethernet tagguite. De cealaltă parte VM-urile conectate la un grup de porturi configurat ca VST operează cu frame-uri untagged. În așa fel switch-ul virtual devine dispozitivul care își asumă sarcina de decapsulare/re-încapsulare dot1q a frame-urilor Ethernet în drumul lor de la VM spre rețeaua externă și invers. La configurare, grupul de porturi este asociat cu un VLAN și doar cu unul singur. În ilustrația de mai sus, configurația VST (prima de la stânga) se reprezintă prin două grupuri de porturi configurate pentru două VLAN-uri: 110 și 24. VM-urile conectate în aceste grupuri de porturi vor accesa fiecare doar VLAN-ul propriului grup de porturi. De remarcat că pe un switch virtual pot exista mai multe grupuri de porturi asociate cu același VLAN. Chiar dacă sunt posibile, se recomandă totuși consolidarea comunicațiilor pentru un VLAN într-un singur grup de porturi, excepție pot fi configurațiile în care pentru grupuri distincte se doresc setări de teaming și politici de securitate specifice – politicile de securitate și teaming ca și VLAN-urile se configurează la nivelul grupului de porturi.

În cazul cu Virtual Guest Tagging, frame-urile tranzitează nemodificate switch-ul virtual și pornesc/ajung de la/la VM-uri tagguite cu 802.1q. Sarcina de untagging revine sistem-ului de operare din interiorul mașinii virtuale în care de obicei se creează sub-interfețe asociate cu fiecare VLAN in parte. VM-ul poate fi dotat cu orice virtual NIC cu excepția VLANCE (Flexible fără VMware Tools) care din start nu știe să interpreteze frame-uri tagguite 802.1q. În ilustrație (pe centru), primele 2 VM-uri (de la stânga) sunt conectate într-un grup de porturi VGT prin care obțin acces la toate VLAN-urile din trunk-ul spre switch-ul extern. Un grup de porturi pe un switch virtual standard (vSS) se configurează în regim VGT dacă se specifică 4095 pentru ID-ul VLAN-ului (+1 peste maximul posibil de prezentat prin 12 biți din standardul 802.1q). Configurația VGT pentru un grup de porturi pe un switch distribuit (vDS) se setează un pic altfel, aici în loc de 4095 (all VLANs) se permite de specificat lista de VLAN-uri (ID-urile separate prin virgulă sau linița la range) acceptate pentru tranzit in grupul de porturi VGT – într-un fel ceva similar cu allowed VLANs pe interfețe trunk la switch-urile Cisco. Specificul VGT-ului pe un switch distribuit il face util atunci când dintr-un motiv sau altul (de obicei din perspectivă de securitate), se dorește ca grupul de porturi VGT să acceseze doar un subset din VLAN-uri în loc de All VLANs.

Mai jos se prezintă configurația VGT pentru un grup de porturi pe un switch standard (vSS) și respectiv pe un switch distribuit (vDS): 

VLAN_configurations_virtual_switch_VGT_mode

Cel de-al treilea mod de configurare pentru un group de porturi pe un switch virtual: External Switch Tagging (EST) reprezintă de fapt configurația fără VLAN-uri. VLAN-urile dacă și există se opresc pe switch-ul fizic frame-urile ajungând untagged la host-ul ESXi. Portul pe switch-ul fizic spre host-ul ESXi se configurează în regim fără dot1q (pe switch-urile Cisco switchport mode access). Dat fiind beneficiile VLAN-urilor regimul cu EST (fără VLAN-uri) e rar utilizat in practică, poate doar in unele scenarii in care rețeaua fizică nu are implementat VLAN-uri or NIC-urile fizice pe host-ul ESXi nu au suport pentru dot1q (greu de imaginat). In ilustrație, VM-urile sunt conectate la un grup de porturi a cărui comunicații au loc untagged până la switch-ul fizic. Pentru a configura un grup de porturi pentru EST acesta se asociază cu VLAN ID = 0.

De menționat că regimurile pentru grupurile de porturi pot fi mixate pe un switch virtual. Un grup de porturi poate fi configurat doar în unul din moduri, pe când mai mult grupuri configurate diferit pot exista în același timp pe același un switch virtual.

Pe lingă modurile explicate mai sus switch-ul virtual distribuit (vDS) mai oferă regimul cu Private VLAN (PVLAN) dar ăsta e un subiect pentru un alt articol, până aici doar trei. 

LVM (Logical Volume Manager)

          Deseori studentii chiar din prima lectie de LPI, ma intreaba ce inseamna LVM 🙂 Si ca sa nu fac copy/paste de pe wiki incerc sa explic in 2 cuvinte sa fie pe intelesul tuturor:

LVM (Logical Volume Manager) – Este un nivel de abstractizare, care ne permite sa folosim 1 sau mai multe discuri rigide (S/HDD) ca o singura entitate, dupa care aceasta entintate o putem partitiona dupa nevoi.

Nota!: Este importat de memorat, ca partitia /boot/ nu poate fi utilizata ca partitie LVM deoarece GRUB nu "intelege" partitiile LVM si respectiv nu poate citi fisierele de configurare si imaginea kernelului, ca urmare nu vom fi capabili sa pornim sistemul de operare.


Spre exemplu avem un JBOD, sau sa luam un exemplu mai simplu – 3 HDD-uri de dimensiuni diferite, fie 10, 20, 30 GB (Total 60Gb). Cu ajutorul tehnologiei LVM unim toate aceste HDD_uri in unul Logic, dupa care il partitionam dupa necesitate.
LVM

Cum lucram cu LVM ?
In LVM avem 3 nivele de abstractizare, si un set de comenzi pentru fiecare nivel care este intuitiv simplu de memorat:

Nivele de abstractizare Comenzi de lucru (lista incompleta)
1. PV (Physical Volume) — Discurile fizice, pot fi atit partitii aparte cat si discurile rigide in intregime.

pvcreate – initializeaza discurile fizice pentru a fi folosite in LVM
pvdisplay – afiseaza informatii despre discurilor fizice
pvremove – sterge un volum fizic

2. VG (Volume Group)  – Grupul de discuri care vor face parte din LVM  (Prin crearea grupei, noi indincam care partitii sau HDD-uri vor face parte din LVM)

vgcreate – creaza grupa de volume
vgdisplay – afiseaza informatii despre grupele de volume
vgreduce – sterge un grup volum

3. LV (Logical Volume) – Partitiile sau partitia logica care va/vor fi create din grupul de volume (VG).

lvcreate – creaza volumul logic
lvdisplay – afiseaza informatii despre volumele logice
lvremove – sterge un volum logic

Trecem la lucru practic:

Pentru a lucra cu LVM avem nevoie de setul de comenzi mentionate anterior, deci instalam pachetul LVM2, in caz ca el deja nu este instalat.

Pentru a vedea ce discuri avem in sistem, ce capacitate, care unde este montat executam lsblk:

Ca rezultat vedem ca la noi in sistem sint 3 HDD-uri sda, sdb si sdc.
sda – care e partitionat in 3, si pe care e instalat sistemul de operare
sdb si sdc – 2 HDD-uri care sint absolut noi, fara oricare file sistem (FS) si partitii.

Scopul nostru este de a crea un LVM din aceste 2 HDD-uri sdb si sdc.

Initializam discul sdb si sdc pentru a fi folosit in LVM:

Acum cream un Volum Group (discul virtual care este format din mai multe partitii sau hdd-uri) cu un nume user friendly

(!) Atrageti atentia ca dupa comenzile pvcreate si vgcreate am indicat doar discurile care vor face parte din LVM

Dupa ce am creat grupul de volume care vor face parte din LVM ne-a mai ramas doar sa cream volumele sau partitiile logice LV (Logical Volumes) :

Sa presupunem ca vrem sa cream 3 partitii logice (Total avem 2Gb, HDD1 + HDD2 = 1Gb +1Gb)
1 = 1.5Gb
2 = 128Mb
3 = 384Mb

Unde:
-n – este optiunea pentru numele partitiei
-L sau –size  – este optiunea pentru marimea partitiei.
MyVG – este numele Grupei de volume

Partitiile (Volumele logice) create vor aparea in /dev/[nume_vg]/ , care de fapt sint niste symlink-uri user friendly

 

Pasul urmator consta in formatare partitiilor sub un anumit file sistem, sau chiar si swap.

ulterior aceste partii pot fi montate si utilizate.

Scopul a fost atins! Ca rezultat am obtinut un disc Logic (Volume Group) din 2 discuri a cate 1Gb, care ulterior a fost repartitionat in 3 partitii.


Acum ca presupunem ca peste ceva timp am mai procurat un HDD (de 4Gb, acest HDD fiind deja al 4-a dupa numar)  care la fel dorim sa-l includem in LVM-ul deja existen. Ca urmare in loc de 2Gb vom avea 6Gb. Deci adaugam noul disc in LVM-ul deja existent:

Dupa cum vedem, hdd-ul a fost adaugat cu success in LVM, acum verificam:

 

In caz ca dorim sa excludem un HDD din LVM  parcurgem pasii urmatori:


Administrare GUI, pentru cei mai putini harnici:
Ca alternativa de administrare a LVM puteti folosi system-config-lvm, care desigur trebuie instalata in sistem

lvextend_ubuntu_root_visual

Sper ca acest articol a adus ceva lumina la capitolul LVM

Enjoy

Configuration Logger pe routere Cisco

Uneori e bine să ai la îndemână istoricul instrucțiunilor ce au fost aplicate pentru modificarea configurației pe un router Cisco. Comanda show history poate să afișeze un așa istoric dar are neajunsul că e legat de sesiunea de consola/linie VTY așa că odată ieșit din terminal se pierde și istoricul. Începând cu Cisco IOS 12.3 .. se introduce funcționalitatea Configuration Change Notification and Logging, care configurată poate înregistra istoricul modificărilor de configurație independent de sesiunile in care au fost executate. Pe deasupra, aceasta poate fi configurat în așa fel încât istoricul să reziste la reload-ul de echipament. Funcția de logger de configurație poate fi utilă în troubleshooting atunci când ai de exemplu nevoie să identifici ultimele modificări de configurație ce au dus la o problemă sau să urmărești comenzile executate de mai mulți administratori în diferite sesiuni ș.a.m.d. Până la configuration logger identificarea schimbărilor de configurație era posibilă doar prin a compara linie cu linie running-config-ul curent cu o copie din trecut a configurației – incomod și fără detalii legate de ordinea instrucțiunilor și autorul lor.

Informațiile reținute de configuration logger includ:

  • comandă IOS executată
  • modul de configurație specific in care a fost executată comanda
  • numele utilizatorului (autentificat in sesiunea terminal) ce a executat comanda
  • un număr de secvență consecutiv a comenzii 

Logger-ul înregistrează doar comenzile ce au dus la modificarea configurației nu și cele de afișare sau comenzi incomplete/eronate. Comenzile sunt înregistrate într-un log circular a cărui lungime poate fi setată din timp.

Să încercăm acum o configurație, cu un simplu router Cisco cu logger de configurație setat. Vom executa câteva comenzi din contexte de utilizatori diferite (în sesiuni de consolă), după care vom afișa istoricul instrucțiunilor stocat de configuration logger. Testele de mai jos sunt executate în GNS3 pe un router 3700 cu IOS 12.4(15)T7 (C3725-ADVENTERPRISEK9-M).

configuration_logger_cisco_network_map

Așadar, pe routerul din schemă aplicăm următoarele configurații:

  1. utilizatori definiți local (mark.smith/jane.doe) și autentificare pentru linia de consola (line con 0)

  1. activare configuration logger, executată în modul de configurare archive – log config prin logging enable. Mai jos, logging size pentru lungime log și hidekeys pentru a ascunde (sub asterisc) password-urile in log.

Continue reading

Set nou de carte pentru studenții orelor de VMware

Devine deja o tradiție ca studenții claselor de VMware să primească cadouri sub formă de carte.  La fel s-a întâmplat și cu grupa curentă pentru care tocmai am primit noul set de cărți. De remarcat silința administratorilor academiei care au depus tot efortul ca cadourile să existe și ca acestea să ajungă la studenții noștri într-un timp cât mai scurt de la lansarea grupei. 

WP_20150303_012

Sper să le fie de mare ajutor în inițiativa lor de studiu și le urez într-un ceas bun.

 

Cum de accesat vSphere 6.0 public beta ?

Pentru că am fost întrebat de studenți cum de accesat vSphere 6.0 din public beta, fac un scurt guide în cele ce urmează. Pentru început accesăm pagina dedicată programului Beta pe VMware Communities: https://communities.vmware.com/community/vmtn/vsphere-beta

acces_vSphere6_0_beta_VMwareCommunity_Join_Beta

Pe dreapta, facem click pe Join Now. Pe pagina de autentificare ne logăm cu un utilizatorul pentru VMware (simplu user, nu neapărat asociat cu un contrat pentru licențe vSphere).

Pe pagina VMware Master Software Beta Test Agreement (MSBTA) Agreement completăm un formular scurt (job title/company/country) după care confirmăm agreement-ul. Click Submit.

Pe pagina următoare confirmăm un alt agreement cu vSphere Program Rules agreement,  după care trecem automat pe pagina cu detalii pentru download și chei beta: 

acces_vSphere6_0_beta_VMwareCommunity_download_page

În continuare totul e simplu, click pe Download Beta – RC Build pentru a descărca versiunile 6.0 pentru ESXi și vCenter Server.

Despre timestamp in log-uri pe ESXi

Uneori mai ajungem să analizăm înregistrări în log-uri pe host-uri ESXi. Pentru referință, acestea sunt întotdeauna însoțite cu un timestamp (marcaj de timp) care ne ajută să localizăm în timp un eveniment sau altul. Valoarea timestamp-ului la un moment dat se deduce din valoarea clock-ului de sistem pentru acel moment, așa că pentru o localizare corectă a evenimentelor avem nevoie de un clock setat corect sau și mai bine sincronizat la o sursa de timp de referință. Sincronizarea la o sursă de referință comună e cu atât mai importantă cu cât avem de corelat mai mult evenimente pe mai multe sisteme separate.

Ceea ce vreau să descriu mai jos e modul in care se formează timestamp-urile in log-urile pe ESXi. Pentru claritate vom face următoarele câteva teste simple:

  • configurăm serverul ESXi pentru o sincronizare a ceasului de sistem la o sursă de timp de referință.  
  • verificam valorile pentru system time pină și după sincronizarea cu sursa de referință
  • producem un eveniment pe ESXi după care analizam în log-uri amprenta lăsată de acesta. Verificăm modul în care se formează timestamp-ul.

Așadar, pe ESXi (eu am folosit unul nested in VMware Workstation) accesăm setările de timp prin vSphere Client – Host – Configuration – Software – Time Configuration. În fereastra deschisă verificăm valoarea curentă Date & Time care cel mai probabil e abătută de la timpul și data corectă. Tot de aici se observă că nu avem setat nici un server sursă de timp de referință (NTP server) – configurație implicită. 

Printr-un click pe Properties (link dreapta sus) deschidem fereastra Time Configuration în care reconfigurăm timpul și data la valorile curente. Intenționat, introducem o abatere mică pe timp (de câteva minute) astfel încât să observăm mai târziu efectul sincronizării cu un server NTP. Se recomandă ca înainte de a configura serverul NTP de ajustat manual timpul si data la cât mai aproape de valorile curente, motivul nu-l cunosc dar intuiesc că sincronizarea are loc iterativ și cu cât ceasul de sistem e mai aproape de adevăr cu atât mai puține iterați au loc deci și o durata mai scurtă pentru perioada de sincronizare totală (trebuie verificat). 

În fereastra Time Configuration click pe Options …  după care in NTP Daemon (ntpd) Option – NTP settings specificam un server NTP (din Internet sau intern din rețeaua companiei). Tot de aici (general settings) ne asigurăm că avem pornit clientul și că acesta va porni automat cu pornirea serverului ESXi.

about_esxi_timestamps_NTP_daemon_options

Așteptăm câteva minute după care comparăm valorile pentru timpul pe ESXi și ceasul de referință – acesta ar trebui să ajungă identice. Într-adevăr in cazul meu NTP-ul și-a făcut treaba și am obținut un timp identic cu sursa de referință.

about_esxi_timestamps_NTP_initial_time

Verificam aceeași data și timp cu următoarele două comenzi din consola ESXi –ului (un pic delayed pentru că am luat screen-urile la diferite momente de timp):

about_esxi_timestamps_time_from_console

Se observă un lucru interesant: Timpul obținut din CLI e cu două ceasuri mai devreme decât ora din vSphere Client. Există o diferență de două ore, 9:22 in comparație cu 11:22. Ora curentă e cea cu 11:22, iar timpul -2 e timpul in reprezentare UTC (timpul universal coordonat). De unde știe ESXi-ul să adauge exact 2 ore că prezinte ora curentă în vSphere Client ? Pentru că nu am configurat nici-unde în altă parte Time Zone intuiesc că acesta se scoate tot prin NTP (trebuie verificat).

De ce m-am legat de subiectul ăsta e pentru că ESXi-ul folosește ca timestamp in log-uri tocmai valoarea în UTC și nu cea curentă (pe care o citim pe ceasul de mănă). Deci odată apucat de analizat log-uri e important să luăm în calcul și ajustarea de +2 ore: la timestamp-ul din log adăugăm două ore ca să ajungem la timpul curent.

Mai este un moment important de remarcat. Plus două ore menționate mai sus sunt valabile doar pentru perioada de iarna nu și cea de vara când va trebui să adăugam deja +3 ore la timestamp-urile din log-uri. Diferența se datorează sistemului de  Daylight Saving Time.  Valorile de +2/+3 reprezintă fusul orar in care se află Republica Moldova, pentru alte țări se folosesc valorile corespunzătoare fusului orar.

Pe final să generam un eveniment pe ESXi după care să urmărim amprenta in unul din log-uri. Cel mai simplu e sa pornim un VM după care sa analizam vmware.log la VM-ul respect. Cu fiecare re-pornire de VM fișierul vmware.log pornește de la început așa că în cazul nostru vom urmări doar evenimentele legate de ultima pornire a VM-ului. Așadar, am pornit VM-ul TEST-VM la ora 11:55 după care am deschis fișierul vmware.log din folderul VM-ului pe datastore (excerpt mai jos):

about_esxi_timestamps_crop_vmware.log

Din screen re-confirmăm că timestamp-ul e deplasat cu 2 ore în trecut (-2) față de ora curentă: 9:55 in comparație cu 11:55. De menționat că în interfață peste tot se afișează totuși ora curent, ca exemplu am urmărit data creării fișierului vmware.log în datastore browser care este afișat ca 11: 55 (coincide cu moment pornirii VM-ului).