Podcast: ladda ner (Längd: 18:45 — 18.1 MB)
Vad är VSS?
först och främst kommer vi att definiera VSS. VSS står för Virtual Switching System, och när vi pratar om VSS pratar vi om ett kluster, inte en stack. En stack är inget annat än att lägga till portar och här talar vi om att montera ett kluster med allt det betyder, hur som helst, oroa dig inte om det här låter lite kryptiskt för att förklara detta är just syftet med detta ljud.
VSS låter dig konvertera två oberoende omkopplare till en ny, större omkopplare. Detta kan monteras med Cisco 4500, 6500 och 6800 som har den specifika hårdvaran för VSS, det vill säga det är inte värt någon 6500 som vi hittar, för att montera en VSS behöver vi specifika mjukvaruversioner och specifik hårdvara.
VSS tillåter kombinationen av två omkopplare för att uppnå en enda logisk nätverksenhet från styr-och hanteringsplanperspektivet.
för routingprotokoll att fungera korrekt genom att tillhandahålla en enda enhet Cisco använder SSO (IOS Statefull SwitchOver) teknik och NSF (Non Stop Forwarding) förlängningar.
naturligtvis kommer den nya virtuella växeln från utsidan att se ut som en enda enhet, som om det bara fanns en dator och inte två.
Vad gör VSS?
- på ledningsnivå förenar SNMP, SSH, telnet ….
- i nivå 2 är ansvarig för BPU: erna, LACP, gest ubicn för Mac: erna …
- nivå 3 är ansvarig för routingprotokollen, routing …
som du kan inse detta går långt utöver vad som skulle vara en enkel stack
och när det gäller behandlingen på växeln aktiv utför programmeringen av vidarebefordran av DFC inom VSS och förutom att programmera PFC (policy feature card) från processorn till växeln i standby-läge.
PFC (policy feature card) för den aktiva handledaren kommer att utföra uppslagningarna av trafiken som kommer in genom den aktiva virtuella swtich och PFC för den andra omkopplaren som kommer in genom den andra omkopplaren. Och DFCs kommer att göra detsamma på sina kort.
du vet redan detta, men CFC: erna fattar inga beslut eftersom beslutet kommer att vidarebefordras till handledaren, om någon fortfarande har ett kort av denna typ.
VSS tillåter centraliserad hantering av allt, om BGP, STP, OSPF, LACP, vad du vill.
VSL (Virtual Switch Link)
VSS vi har redan kommenterat att det är ett kluster av två switchar, men naturligtvis måste dessa switchar ansluta sig till dem på något sätt, till skillnad från en stapel som vanligtvis görs med proprietära kablar här görs föreningen av switcharna via en VSL (Virtual Switch Link), som inte är mer än en etherchannel av port 10 eller 40G, detta gör att de lag som bildar VSS tillsammans, Jag ser personligen ingen två växlar som bildar i VSS, men du vet att om du hittar det och det tjänar du kan använda den.
trafiken som passerar genom VSL är inkapslad med VSH-rubriken (Virtual Switch Header), något som är intressant att du vet mer än någonting eftersom VSH-rubriken har en längd på 32 byte, om du måste sända för cirka 10 G fjärrkontroll som du tar hänsyn till ramens storlek.
när du har lagt kablarna som kommer att bilda VSL måste du starta det, för detta spelar in ett protokoll som heter LMP (Link Management Protocol) som verifierar att länkarna är korrekta, byter ID för omkopplarna och sedan nödvändig information för att kommunicera båda chassit.
då måste vi kontrollera att både programvara och hårdvara är kompatibel för att senare bestämma vilken dator som ska vara aktiv och vilken säkerhetskopiering för VSS: s kontrollplan.
här kommer ett protokoll som heter RRP (Role Resolution Protocol) som gör just det, kontrollera att allt är kompatibelt och välj en aktiv switch och en standby-switch.
och det är här det börjar köttet i saken eftersom kontrollerna kan vara korrekta eller inte, om de är korrekta initierar det allt och swtitch är NSF/SSO (Nonstop Forwarding / Statefull Switchover), det här är bra, men om något går fel är VSS i läge RPR (Route-Processor redundans) och alla moduler är avstängda. Det är här det kan finnas ett verkligt problem, när du ser att datorerna stannar i RPR-läge, det här är vad vi aldrig vill se och första gången vi ser det vill vi komma ut därifrån, men det är verkligen för att det är något fel, utan mer, det enda vi behöver göra är att andas och leta efter skillnaderna.
redundans för VSL
visst inser du att VSL är en grundläggande del av VSS, verkligen utan VSL skulle vi inte ha synkronisering mellan kontrollplanen för de två processorerna, dessutom utan VSL startar VSS direkt inte eftersom SSO inte kommer att kunna esubler i livet, så redundansen för VSL är grundläggande.
faktum är att om det är två eller fyra VSL-kablar beror på antalet styrenheter vi har på varje omkopplare. Egentligen med ett chassi controller är tillräckligt, och om vi bara har ett chassi controller vi kommer att ansluta både chassi med en 2-tråds etherchannel.
nu, om vi har två processorer, kommer vi att använda en kabel för att ansluta styrenhet 1 av switch 1 med styrenhet 1 av swich 2 och en annan med styrenhet 2 och sedan ett annat par kablar i den andra styrenheten för den första omkopplaren med två av den andra, det vill säga styrenheterna anslutna till de två motsatta omkopplarna och det här är naturligtvis 4 kablar. Därför används 2 eller 4 kablar för VSL-redundans, beroende på antalet styrenheter i varje omkopplare.
som ni ser är det inte så svårt att förstå driften av en VSS, är något många nya och därför kanske låter obekant, men det är inte komplicerat, bara nya
då finns det en fråga som verkligen har ingenting att göra med VSL, men om det har att göra med kontrollen av vad vi kallar den dubbla aktiva, vilket är ett scenario där båda omkopplarna som utgör VSS förblir aktiva eftersom VSL har fallit full vi behöver detektionsmekanismer.
dessa mekanismer är i grunden två PAGP+ (enhanced PAgP), som är ett Cisco-proprietärt protokoll och det är därför jag inte gillar det och jag föredrar BFD-alternativet som har en något längre konfiguration, jag pratar om ytterligare två rader, men det tjänar oss samma.
detta är något som du alltid måste konfigurera på den första etherchannel som är konfigurerad, ja, och på den andra och tredje.
både PAGP+ och BFD tillåter oss att identifiera den dubbla aktiva situationen i omkopplarna.
då glömmer jag inte att det finns en sak som heter Fast Hello Detection, som introducerades senare, men jag har aldrig använt, så det är därför jag inte kommenterar, bara berätta att det finns och att det är ett annat alternativ som från det jag har sett är konfigurerat väldigt enkelt.
och om en dual active detekteras, vad händer? mmmm, eftersom en av dem startas om för att resinconize igen, bör i princip ingenting hända, men det är inte en önskvärd situation.
hur som helst om du tror att vi kommer att ägna några minuter till bugscenarier med VSS.
vad händer när den aktiva handledaren misslyckas?
här kommer det helt enkelt att växla bildskärmen till standby och det är det, om du hade konfigurerat preemtion vid tidpunkten för att återställa den trasiga skulle den vara aktiv igen. Personligen tycker jag inte att det är bra att ha preemtion inrättat, för åtminstone för mig gillar jag att när saker pendlar utan behov, är det med mig framför vad som kan hända. Och om du använder lika växlar det inte vettigt att man är att föredra, även om jag har sett folk sätta en switch med preemtion eftersom det är till vänster om andra saker så kanske de inte är tillräckligt skäl.
vad händer när en VSL-länk misslyckas?
verkligen ingenting, vi kommer att få ett larm, vi kommer att titta på porten, kabeln och när vi återställer felet, att det normala skulle vara att det var en trasig SFP vi ändrar det och att arbeta.
vad händer när en icke-VSL-port misslyckas?
samma som tidigare
vad händer när alla icke-VSL-portar misslyckas?
det betyder att alla portar som inte är från processorn misslyckas, den här situationen har jag bara sett när omkopplaren går in i RPR (Route-Processor redundans) läge