Nexus vPC
Virtual Port-Channel är Ciscos MLAG-variant för Nexus-switchar. Båda switchar i paret är aktiva för data plane men den ena noden står för control plane och tar därmed hand om BPDUer och LACPDUer. Det är inte delad management plane (som t.ex. VSS), för att avgöra om noderna i paret har kompatibel konfiguration skickas en kopia med CFS över peer-länken. Alla mac-adresser som switcharna lär sig synkroniseras också med CFS över peer-länken. Se även Cisco EtherChannel.
Initial setup
Aktivera vPC
feature vpc feature lacp
Skapa vrf för keepalive och assigna interface
vrf context VPC-KEEPALIVE interface po1 no switchport vrf member VPC-KEEPALIVE ip address 10.255.255.1/30 no shut
Domänkonfiguration
En VPC-domän har default en restore-delay på 30 sekunder.
vpc domain <number> role priority 1 system-priority 1000 peer-keepalive destination 10.255.255.2 source 10.255.255.1 vrf VPC-KEEPALIVE peer-gateway auto-recovery ip arp synchronize ipv6 nd synchronize
Om man kör FabricPath lägg även till: fabricpath switch-id <id>
Konfigurera vPC peer-link
interface port-channel2 switchport switchport mode trunk spanning-tree port type network #för Bridge Assurance vpc peer-link
Verify
show vpc show vpc peer-keepalive
Konfiguration
Skapa vPCer genom att assigna interface.
interface Ethernet1/20 switchport mode trunk channel-group 20 mode active interface port-channel20 switchport mode trunk vpc 20
LACP
NX-OS har ”graceful convergence” aktiverat som standard. Denna funktion förbättrar hanteringen av handskakningen för LACP. När en PortChannel går mot en enhet som inte kör NX-OS så ska denna funktion stängas av för att minska risken att en individuell port går ner i ”suspended state”.
interface port-channel10 no lacp graceful-convergence
Individual port
Standardparametrarna för hanteringen av individuella portar inom en PortChannel skiljer sig mellan Nexus 7000 och Nexus 5000. När man uppgraderar till nyare NX-OS så läggs "no lacp suspend-individual" till i running config på interface med default-konfiguration, innan syntes inte detta. När Nexus 5000 ansluts till andra nätverksenheter, använd suspend-individual för PortChannel:n.
interface port-channel10 lacp suspend-individual
Verify
show run vpc show vpc brief show vpc role show vpc consistency-parameters vpc 5 show vpc orphan ports show lacp neighbor
vPC Enhancements
Peer-switch
vPC Peer-switch möjliggör för ett vPC-par att presentera sig som en logisk enhet i STP genom att de delar på ett virtuellt bridge ID. Båda peer-enheterna kommer även att skicka ut dessa identiska BPDU:er, samt processa inkommande BPDU:er. Om peer-switch inte är påslaget, är det endast primär-enheten skickar ut BPDU:er och sekundär-enheten agerar proxy för primären och forwarderar inkommande BPDU:er till den över peer-länken. Tack vare peer-switch kortas trafikavbrottet till följd av en peer-krasch ned avsevärt, enlight Cisco själva till under sekunden, på grund av att ingen logisk topologiförändring sker i STP. Det rekommenderas att använda sig av peer-switch i en vPC-domän.
Med peer-switch påslaget är båda peer-enheterna tvugna att ha exakt samma spanning tree-konfiguration för samtliga vPC VLAN. Peer-switch måste även det vara konfigurerat på båda sidor. För att slå på peer-switch:
vpc domain 1 peer-switch
Peer-gateway
vPC Peer-gateway tillåter en vPC peer-enhet att agera gateway för paket som adresserats till den andra peer-enhetens MAC-adress. På så vis behålls routingen lokalt istället för att i onödan traversera peer-länken. Denna funktion är huvudsakligen till för att på ett bättre sätt hantera enheter som inte använder standard-ARP för sin default gateway, till exempel vissa lastbalanserare. Det finns inga nackdelar med denna teknologi och rekommenderas att aktivera i alla vPC-installationer, även denna funktion ska aktiveras på båda peer-enheterna. För att slå på peer-gateway:
vpc domain 1 peer-gateway
ARP Sync
För att snabba upp återskapandet av ARP-tabellen efter exempelvis peer-flap eller att ett SVI gått up kan man använda sig av ARP-synkronisering mellan vPC-enheterna. Efter att något av tidigare nämnda händelser inträffat kommer båda enheterna då att synkronisera sina ARP-tabeller med varandra över peer-länken. Det rekommenderas starkt att alltid aktivera IP ARP synchronization på båda peer-enheterna. För att aktivera ARP sync:
vpc domain 1 ip arp synchronize show ip arp vpc-statistics
Failover Behavior
Olika fel kan uppstå i ett datacenter och vPC har vissa mekanismer för att hantera det. Om peer-länken går ner så används peer-keepalive för att kolla status på peeren. Om båda noder är aktiva kommer sekundären att stänga ner alla sina vPC-portar, detta för att förhindra loopar. Går både peer-länk och peer-keepalive ner samtidigt kan det vara svårt att upptäcka samt möjlig service disruption. Kör man heartbeats på mgmt-porten så märks åtminstone att man tappat mgmt av noderna. Heartbeat-gränser går att konfigurera.
Om hela ena noden går ner så kommer den kvarvarande att ta över all forwardering. Var länkar redan innan device failure överlastade kan det såklart bli traffic drops. Finns det något konfigurationsfel mellan noderna så går inte Consistency Check igenom och då kommer endast den primära noden att vara aktiv för forwardering. Beroende på typ av mismatch så genereras syslog-meddelanden.
show vpc consistency-parameters
Back to Back
Man kan koppla ett vpc-par till ett annat vpc-par och köra en vpc på varje sida, detta kallas back-to-back vPC. Detta kan t.ex. användas mellan aggregation och access layer. Det går också att använda som DCI-lösning om man inte använder någon overlay-teknik eller om man vill ha alla länkar aktiva och avgränsa STP. Man kan stänga av att BPDU:er skickas (portfast) och ha varje DC i egen STP-domän.
Det finns inga speciella kommandon eller hårdvarukrav för detta utan det är en implementationsvariant, man konfar vpc på båda sidor. Dock måste vPC domain ID skilja sig mellan paren.
