Nexus 7000 vPC-configuratievoorbeeld voor automatisch herstel
Inhoud
Inleiding
Dit document beschrijft hoe u de virtuele optie PortChannel (vPC) voor automatisch herstel op de Nexus 7000 kunt configureren.
Voorwaarden
Vereisten
Er zijn geen specifieke vereisten van toepassing op dit document.
Gebruikte componenten
Dit document is niet beperkt tot specifieke software- en hardware-versies.
De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u de potentiële impact van elke opdracht begrijpen.
Achtergrondinformatie
Waarom hebben we vPC Auo-recovery nodig?
Er zijn twee belangrijke redenen voor deze vPC-verbetering:
- In een stroomuitval of stroomuitval van het datacenter zijn beide vPC-peers die uit Nexus 7000 switches bestaan, uitgeschakeld. Soms kan slechts één van de peers worden hersteld. Aangezien de andere Nexus 7000 nog niet is voltooid, zijn de vPC peer-link en de vPC peer-keeplive link ook uit. In dit scenario komt de vPC niet aan, zelfs niet voor de Nexus 7000 die al op is. Alle vPC configuraties moeten worden verwijderd van het poortkanaal op die Nexus 7000 om het havenkanaal te veroorzaken om te werken. Als de andere Nexus 7000 wordt ingeschakeld, moet u opnieuw configuratiewijzigingen doorvoeren om de vPC-configuratie in alle vPC's te kunnen integreren. In release 5.0(2) en hoger kunt u de opdracht herladen configureren onder de vPC-domeinconfiguratie om dit probleem aan te pakken.
- Om de een of andere reden gaat de vPC peer-link uit. Aangezien de vPC peer-Keeplive nog is ingeschakeld, worden al zijn vPC poorten door dubbele actieve detectie uitgeschakeld met het vPC secundaire peer-apparaat. Vandaar dat al het verkeer door de vPC primaire schakelaar gaat. Om de een of andere reden gaat de vPC primaire schakelaar ook uit. Dit switchprobleem maakt het verkeer zwart sinds de vPC's op het secundaire peer-apparaat nog uit omdat het dubbele-actieve detectie gedetecteerd heeft voordat de vPC primaire schakelaar uit ging.
In release 5.2(1) en hoger combineert de vPC auto-herstelfunctie deze twee verbeteringen.
Configuratie
De configuratie van het automatische herstel van vPC is eenvoudig. U dient het automatisch herstel te configureren onder het vPC-domein op beide vPC-peers.
Dit is een voorbeeldconfiguratie:
Aan switch S1
S1 (config)# vpc domain
S1(config-vpc-domain)# auto-recovery
S1# show vpc
Legend:
(*) - local vPC is down, forwarding via vPC peer-link
vPC domain id : 1
Peer status : peer adjacency formed ok
vPC keep-alive status : peer is alive
Configuration consistency status : success
Per-vlan consistency status : success
Type-2 consistency status : success
vPC role : primary
Number of vPCs configured : 5
Peer Gateway : Enabled
Peer gateway excluded VLANs : -
Dual-active excluded VLANs : -
Graceful Consistency Check : Enabled
Auto-recovery status : Enabled (timeout = 240 seconds)
vPC Peer-link status
---------------------------------------------------------------------
id Port Status Active vlans
-- ---- ------ --------------------------------------------------
1 Po1 up 1-112,114-120,800,810
vPC status
-----------------------------------------------------------------------
id Port Status Consistency Reason Active vlans
-- ---- ------ ----------- ------ ------------
10 Po40 up success success 1-112,114-1
20,800,810
Aan switch S2
S2 (config)# vpc domain 1
S2(config-vpc-domain)# auto-recovery
S2# show vpc
Legend:
(*) - local vPC is down, forwarding via vPC peer-link
vPC domain id : 1
Peer status : peer adjacency formed ok
vPC keep-alive status : peer is alive
Configuration consistency status : success
Per-vlan consistency status : success
Type-2 consistency status : success
vPC role : secondary
Number of vPCs configured : 5
Peer Gateway : Enabled
Peer gateway excluded VLANs : -
Dual-active excluded VLANs : -
Graceful Consistency Check : Enabled
Auto-recovery status : Enabled (timeout = 240 seconds)
vPC Peer-link status
---------------------------------------------------------------------
id Port Status Active vlans
-- ---- ------ --------------------------------------------------
1 Po1 up 1-112,114-120,800,810
vPC status ----------------------------------------------------------------------
id Port Status Consistency Reason Active vlans
-- ---- ------ ----------- ------ ------------
40 Po40 up success success 1-112,114-1
20,800,810
Hoe werkt het automatisch herstel echt?
In dit deel wordt elk gedrag dat in de achtergrondinformatie wordt genoemd afzonderlijk besproken. De veronderstelling is dat het auto-herstel van vPC wordt geconfigureerd en opgeslagen in de startconfiguratie op zowel switches S1 als S2.
- Een stroomuitval sluit zowel Nexus 7000 vPC-peers tegelijkertijd uit en slechts één schakelaar kan worden ingeschakeld.
- S1 en S2 zijn beide aan. vPC wordt correct gevormd met peer-link en peer-Keeplive op.
- Zowel S1 als S2 worden tegelijkertijd uitgeschakeld.
- Nu kan slechts één schakelaar worden ingeschakeld. S2 is bijvoorbeeld de enige schakel die de macht aanzet.
- S2 wacht op de vPC auto-hersteltijd (de standaardinstelling is 240 seconden die kunnen worden ingesteld met de auto-herstel-vertraging x opdracht, waarbij x 240-3600 seconden is) om te controleren of er een vPC peer-link of peer-Keepistatus aan is. Als een van deze koppelingen is ingeschakeld (peer-link of peer-keeplive status) wordt het automatisch herstel niet geactiveerd.
- Als na de tijdelijke versie beide koppelingen nog niet zijn ingeschakeld (peer-link evenals peer-keeplevstatus), kan vPC auto-recovery en S2 primair worden en wordt deze gestart om stroom op de lokale vPC aan te kunnen. Aangezien er geen gelijken zijn, wordt de consistentiecontrole omzeild.
- Nu komt S1 aan. Op dit moment behoudt S2 zijn primaire rol en neemt S1 een secundaire rol, wordt een consistentiecontrole uitgevoerd en worden passende maatregelen genomen.
- vPC peer-link start eerst en dan de primaire vPC peer krachten uit.
- S1 en S2 zijn zowel op als vPC wordt correct gevormd met peer-link en peer-keeplevend op.
- Om de een of andere reden gaat vPC peer-link eerst uit.
- Aangezien vPC peer-Keeplive nog aan is, detecteert het dubbele actieve detectie. De vPC secondaire S2 schakelt al zijn lokale vPC's uit.
- De vPC primaire S1 gaat uit of wordt opnieuw geladen.
- Deze storing schakelt ook de vPC peer-Keeplive link uit.
- S2 wacht op drie achtereenvolgende peer-keeplevingsberichten die verloren gaan. Om de een of andere reden komt de vPC peer-link aan of S2 ontvangt een peer-Keeplive bericht, en het auto-herstel niet toelaat.
- Als de peer-link echter uit blijft en er drie opeenvolgende peer-keeplevendige berichten verloren gaan, is het vPC auto-herstel mogelijk.
- S2 neemt de rol van primair en stelt zijn lokale vPC in staat, die de consistentiecontrole omzeilt.
- Wanneer S1 de herlading voltooit, behoudt S2 zijn rol van primair en S1 wordt secundair, wordt een consistentiecontrole uitgevoerd en worden passende maatregelen genomen.
Bijvoorbeeld:
S1 wordt uitgeschakeld. S2 wordt de operationele primaire eenheid zoals verwacht. Peer-link en peer-keeplevend en alle vPC links zijn losgekoppeld van S1. S1 wordt niet ingeschakeld. Omdat S1 volledig geïsoleerd is, wordt de vPC er door (hoewel de fysieke links omlaag zijn) ingeschakeld als gevolg van het automatisch herstel en wordt de rol van primair bestand overgenomen. Als peer-link of peer-Keeplive wordt aangesloten tussen S1 en S2, houdt S1 de rol van primair en S2 secundair. Deze configuratie zorgt ervoor dat S2 zijn vPC opschort totdat zowel vPC peer-link als peer-Keeplive wordt ingeschakeld en de consistentiecontrole is voltooid. Dit scenario veroorzaakt verkeer naar zwart gat aangezien de S2 vPC secundair is en de S1 fysieke links uit zijn.
Moet ik auto-herstel van vPC toestaan?
Dit is een goede methode om automatisch herstel in uw vPC-omgeving mogelijk te maken.
Er is een kleine kans dat de optie voor het automatisch terugwinnen van vPC een dubbel-actief scenario creëert. Bijvoorbeeld, als je eerst de peer-link verloor en dan verloor je de peer-Keeplive, zal je dubbel-actief scenario hebben.
In deze situatie blijft elke poort op een vPC-lid adverteren met dezelfde Link Aggregation Control Protocol-ID die het vóór de dubbele-actieve mislukking heeft gedaan.
Een vPC topologie beschermt intrinsiek tegen loops in het geval van dubbel actieve scenario's. In het ergste geval zijn er dubbele frames. Ondanks dit, als een lus-preventie mechanisme, stuurt elke switch Bridge Data Units (BPDU's) door met dezelfde BPDU Bridge-ID als vóór de vPC dual-active defect.
Hoewel niet intuïtief, is het nog steeds mogelijk en wenselijk om door te gaan met het verzenden van verkeer van de toegangslaag naar de aggregatielaag zonder druppels voor huidige verkeersstromen, op voorwaarde dat de tabellen met adresresolutie Protocol (ARP) al bevolkt zijn op zowel Cisco Nexus 7000 Series-peers voor alle benodigde hosts.
Als de nieuwe MAC-adressen door de ARP-tabel moeten worden aangeleerd, kunnen zich problemen voordoen. De kwesties doen zich voor omdat de ARP-respons van de server naar één Cisco Nexus 7000 Series apparaat kan worden gehashed en niet naar het andere apparaat, wat het voor het verkeer onmogelijk maakt om correct te stromen.
Stel echter voor dat, voordat de situatie zojuist was beschreven, het verkeer gelijk was verdeeld naar zowel Cisco Nexus 7000 Series-apparaten door een juiste PortChannel-configuratie en een gelijkwaardige Multipath-configuratie (ECMP). In dit geval blijft server-to-server en client-to-server verkeer doorgaan met het voorbehouden dat single-bijlage hosts die rechtstreeks zijn aangesloten op de Cisco Nexus 7000 Series niet kunnen communiceren (bij gebrek aan een peer link). Bovendien kunnen nieuwe MAC-adressen die op één Cisco Nexus 7000 Series zijn geleerd niet op de peer worden geleerd, omdat dit het retourverkeer veroorzaakt dat op het peer Cisco Nexus 7000 Series-apparaat aankomt om te overstromen.
Raadpleeg pagina 19 van de Cisco NX-OS software Virtual PortChannel: Grondbegrippen voor meer informatie.
Verifiëren
Er is momenteel geen verificatieprocedure beschikbaar voor deze configuratie.
Problemen oplossen
Er is momenteel geen specifieke troubleshooting-informatie beschikbaar voor deze configuratie.
Gerelateerde informatie
FeedbackContact Cisco
- Een ondersteuningscase openen
- (Vereist een Cisco-servicecontract)