Podcast: descărcare (Lungime: 18:45 — 18.1 MB)
- ce este VSS?
- ce face VSS?
- VSL (Virtual Switch Link)
- redundanța VSL
- Ce se întâmplă când supraveghetorul activ eșuează?
- Ce se întâmplă când o legătură VSL eșuează?
- Ce se întâmplă atunci când un port non-VSL eșuează?
- Ce se întâmplă când toate porturile non-VSL eșuează?
- ce se întâmplă atunci când VSL complet cade?
ce este VSS?
în primul rând vom defini VSS. VSS înseamnă Virtual Switching System, iar când vorbim despre VSS vorbim despre un cluster, nu despre o stivă. O stivă nu este altceva decât adăugarea de porturi și aici vorbim despre montarea unui cluster cu tot ceea ce înseamnă, oricum, nu vă faceți griji dacă acest lucru sună puțin criptic, deoarece explicarea acestui lucru este tocmai scopul acestui audio.
VSS vă permite să convertiți două comutatoare independente într-un comutator nou, mai mare. Acest lucru poate fi montat cu Cisco 4500, 6500 și 6800 care au hardware-ul specific pentru VSS, adică nu merită niciun 6500 pe care îl găsim, pentru a monta un VSS avem nevoie de versiuni software specifice și hardware specific.
VSS permite combinarea a două comutatoare pentru a realiza o singură entitate de rețea logică din perspectivele planului de control și gestionare.
pentru ca protocoalele de rutare să funcționeze corect prin furnizarea unei singure entități, Cisco utilizează tehnologia SSO (IOS Statefull SwitchOver) și extensiile NSF (Non Stop Forwarding).
desigur, noul comutator virtual din exterior va arăta ca o singură entitate, ca și cum ar exista un singur computer și nu două.
ce face VSS?
- la nivel de management unifică SNMP, SSH, telnet ….
- la nivelul 2 este responsabil pentru BPU-urile, LACP-ul, gest-ul de la Mac-uri …
- nivelul 3 este responsabil pentru protocoalele de rutare, rutare …
după cum vă puteți da seama, acest lucru depășește cu mult ceea ce ar fi o stivă simplă
și în ceea ce privește procesarea pe comutatorul activ efectuează programarea redirecționării DFC-urilor în cadrul VSS și în plus față de programul PFC (policy feature card) de la procesor la comutator în modul de așteptare.
PFC (policy feature card) al supervizorului activ va efectua căutările traficului care intră prin swtich virtual activ și PFC al celuilalt comutator care intră prin celălalt comutator. Și DFC – urile vor face același lucru pe cardurile lor.
știți deja acest lucru, dar CFC-urile nu iau nicio decizie, deoarece decizia va fi transmisă supraveghetorului, în cazul în care cineva mai are un card de acest tip.
VSS permite gestionarea centralizată a tuturor, indiferent dacă BGP, STP, OSPF, LACP, orice doriți.
VSL (Virtual Switch Link)
VSS am comentat deja că este un grup de două comutatoare, dar, desigur, aceste comutatoare vor trebui să li se alăture într-un fel, spre deosebire de o stivă care se face de obicei cu cabluri proprietare aici unirea comutatoarelor se face printr-un VSL (Virtual Switch Link), care nu este altceva decât un etherchannel de port 10 sau 40G, acest lucru permite echipelor care formează VSS împreună, personal nu văd nici un folos în separarea două switch-uri care se formează în VSS, dar știi că, dacă îl găsiți și servește îl puteți folosi.
traficul care trece prin VSL este încapsulat cu antetul VSH (Virtual Switch Header), lucru interesant pe care îl cunoașteți mai mult decât orice, deoarece antetul VSH are o lungime de 32 de octeți, în cazul în care trebuie să transmiteți pentru aproximativ 10g distanță pe care o luați în considerare dimensiunea cadrului.
odată ce ați pus cablurile care vor forma VSL, va trebui să îl porniți, pentru că acesta intră în joc un protocol numit LMP (Link Management Protocol) care verifică dacă legăturile sunt corecte, schimbă ID-ul comutatoarelor și apoi informațiile necesare pentru a comunica ambele șasiuri.
atunci va trebui să verificăm dacă atât software-ul, cât și hardware-ul sunt compatibile pentru a decide ulterior ce computer va fi activ și ce copie de rezervă pentru planul de control al VSS.
aici vine un protocol numit RRP (rol Resolution Protocol) care face doar asta, verificați dacă totul este compatibil și selectați un comutator activ și un comutator de așteptare.
și aici începe carnea problemei, deoarece verificările pot fi corecte sau nu, dacă sunt corecte, inițializează totul și swtitch-ul este NSF/SSO (redirecționare Non-Stop / comutare Statefull), acest lucru este bun, dar dacă ceva nu merge bine, VSS este în modul RPR (redundanță Route-Processor) și toate modulele sunt oprite. Aici poate exista o problemă reală, când vedeți că computerele rămân în modul RPR, aceasta este ceea ce nu vom dori niciodată să vedem și prima dată când o vedem vrem să ieșim de acolo alergând, dar este într-adevăr pentru că există ceva în neregulă, Fără mai mult, singurul lucru pe care va trebui să-l facem este să respirăm și să căutăm diferențele.
redundanța VSL
cu siguranță vă dați seama că VSL este o parte fundamentală a VSS, într-adevăr fără VSL nu am avea sincronism între planurile de control ale celor două procesoare, în plus, fără VSL VSS direct nu pornește deoarece SSO nu va putea esubler în viață, deci redundanța VSL este fundamentală.
de fapt, dacă este vorba de două sau patru cabluri VSL depinde de numărul de controlere pe care le avem pe fiecare comutator. De fapt, cu un controler de șasiu este suficient, și dacă avem doar un controler de șasiu ne vom alătura atât șasiu printr-un etherchannel 2 fire.
acum, dacă avem două procesoare, vom folosi un cablu pentru a uni controlerul 1 al comutatorului 1 cu controlerul 1 al swich 2 și altul cu controlerul 2 și apoi o altă pereche de cabluri a celui de-al doilea controler al primului comutator cu cele două ale celui de-al doilea, adică controlerele conectate la cele două ale comutatorului opus și, desigur, acesta este 4 cabluri. De aceea, 2 sau 4 cabluri sunt utilizate pentru redundanța VSL, în funcție de numărul de controlere din fiecare comutator.
după cum vedeți, nu este atât de dificil să înțelegeți funcționarea unui VSS, este ceva nou și, prin urmare, ar putea suna nefamiliar, dar nu este complicat, doar nou
atunci există o problemă care nu are nimic de-a face cu VSL, dar dacă asta are de-a face cu controlul a ceea ce numim dual active, care este un scenariu în care ambele comutatoare care alcătuiesc VSS rămân active, deoarece VSL a căzut complet, acest lucru este rău, foarte rău și pentru a preveni acest lucru avem nevoie de mecanisme de detectare.
aceste mecanisme sunt practic două PAGP+ (pagp îmbunătățit), care este un protocol proprietar Cisco și de aceea nu-mi place și prefer opțiunea BFD care are o configurație puțin mai lungă, vorbesc despre încă două linii, dar ne servește la fel.
acest lucru este ceva ce trebuie să configurați întotdeauna pe primul etherchannel care este configurat, bine, și pe al doilea și al treilea.
atât PAGP+ cât și BFD ne permit să identificăm situația duală activă în comutatoare.
atunci nu uit că există un lucru numit Fast Hello Detection, care a fost introdus mai târziu, dar nu am folosit niciodată, de aceea nu comentez, vă spun doar că există și că este o altă opțiune care din ceea ce am văzut este configurată foarte ușor.
și dacă este detectat un dual activ, ce se întâmplă? mmmm, pentru că unul dintre ei este repornit pentru a resinconiza din nou, în principiu nu ar trebui să se întâmple nimic, dar nu este o situație de dorit.
oricum, dacă credeți că vom dedica câteva minute scenariilor de erori cu VSS.
Ce se întâmplă când supraveghetorul activ eșuează?
aici va trece pur și simplu monitorul în standby și asta este, dacă ați fi configurat preemtion în momentul recuperării defectului, acesta ar fi din nou activ. Personal, nu cred că este o idee bună să aveți preemtion înființat pentru că, cel puțin pentru mine, îmi place că atunci când lucrurile fac naveta fără nevoie, este cu mine în fața a ceea ce se poate întâmpla. Și dacă utilizați comutatoare egale, nu are prea mult sens că unul este preferat, deși am văzut oameni punând un comutator cu preemțiune, deoarece este în stânga celorlalte lucruri, deci poate că nu sunt suficiente motive.
Ce se întâmplă când o legătură VSL eșuează?
într-adevăr nimic, vom primi o alarmă, ne vom uita la port, la cablu și la recuperarea defecțiunii, că normal ar fi că a fost un SFP rupt îl schimbăm și să funcționeze.
Ce se întâmplă atunci când un port non-VSL eșuează?
la fel ca înainte
Ce se întâmplă când toate porturile non-VSL eșuează?
asta înseamnă că toate porturile care nu sunt de la procesor nu reușesc, această situație am văzut doar atunci când comutatorul intră în modul RPR (Route-Processor Redundancy)