Konfigurieren von Hochverfügbarkeit SSO auf Catalyst 9800 | Kurzanleitung

WLC1#show running-config | s interface
interface GigabitEthernet1
 shutdown
 negotiation auto
 no mop enabled
 no mop sysid
interface GigabitEthernet2
 switchport trunk allowed vlan 39
 switchport mode trunk
 negotiation auto
 no mop enabled
 no mop sysid
interface GigabitEthernet3
 negotiation auto
 no mop enabled
 no mop sysid
interface Vlan1
 no ip address
 shutdown
 no mop enabled
 no mop sysid
interface Vlan39
 ip address 10.48.39.130 255.255.255.0
 no mop enabled
 no mop sysid
wireless management interface Vlan39

WLC2#show running-config | s interface
interface GigabitEthernet1
 shutdown
 negotiation auto
 no mop enabled
 no mop sysid
interface GigabitEthernet2
 switchport trunk allowed vlan 39
 switchport mode trunk
 negotiation auto
 no mop enabled
 no mop sysid
interface GigabitEthernet3
 negotiation auto
 no mop enabled
 no mop sysid
interface Vlan1
 no ip address
 shutdown
 no mop enabled
 no mop sysid
interface Vlan39
 ip address 10.48.39.133 255.255.255.0
 no mop enabled
 no mop sysid
wireless management interface Vlan39

In diesem Beispiel ist WLC1 als primärer Controller (d. h. Chassis 1) festgelegt, während WLC2 als sekundärer Controller (d. h. Chassis 2) festgelegt ist. Das bedeutet, dass das aus den beiden Controllern bestehende HA-Paar die Konfiguration des WLC1 verwendet und dass nach dem Prozess der eine des WLC2 verloren geht.

Schritt 1: Sichern Sie optional die Startkonfigurations- und Ausführungskonfigurationsdateien der Controller.

Falsche Handhabung kann passieren und dazu führen, dass die Konfiguration verloren geht. Um dies zu vermeiden, wird dringend empfohlen, sowohl die Start- als auch die aktuelle Konfiguration von beiden in der HA-Konfiguration verwendeten Controllern zu sichern. Dies ist über die Benutzeroberfläche oder die Kommandozeile des 9800 ganz einfach möglich.

Über die GUI:

Über die Registerkarte Administration → Management → Backup & Restore (Verwaltung und Verwaltung Sicherung und Wiederherstellung) der Benutzeroberfläche des 9800 (siehe Screenshot) können Sie die aktuell vom Controller verwendete Start- und Ausführungskonfiguration herunterladen.

In diesem Beispiel werden sowohl der Startvorgang (linke Seite) als auch die Konfiguration (rechte Seite) direkt über HTTP auf das Gerät heruntergeladen, das den Browser hostet, der für den Zugriff auf die grafische Benutzeroberfläche des WLC verwendet wird. Der Übertragungsmodus und das Ziel der zu sichernden Datei können mit dem Feld Übertragungsmodus leicht angepasst werden.

Über die CLI:

WLCx#copy running-config tftp://<SERVER-IP>/run-backup_x.cfg            
Address or name of remote host [<SERVER-IP>]? 
Destination filename [run-backup_x.cfg]? 
!!
19826 bytes copied in 1.585 secs (12509 bytes/sec)
WLCx#copy startup-config tftp://<SERVER-IP>/start-backup_x.cfg          
Address or name of remote host [<SERVER-IP>]? 
Destination filename [start-backup_x.cfg]? 
!!
20482 bytes copied in 0.084 secs (243833 bytes/sec)

Ersetzen Sie die <SERVER-IP> durch die TFTP-Server-IP-Adresse, in die die Start-/aktuelle Konfigurationsdatei kopiert wird.

Schritt 2: (Optional) Sicherstellen der Netzwerkverbindung

Von beiden WLC-GUIs oder CLIs können einfache Verbindungstests durchgeführt werden, bei denen ein Ping an das Gateway von beiden Geräten und ein Ping an die Geräte untereinander gesendet wird. Dadurch wird sichergestellt, dass beide Controller über die erforderliche Konnektivität für die Konfiguration von HA verfügen.

Über die GUI:

Mit dem Tool Ping und Traceroute auf der Registerkarte Troubleshooting (Fehlerbehebung) der Benutzeroberfläche des Cisco 9800 können die Verbindungen zwischen den Controllern selbst sowie zwischen den einzelnen WLCs und ihren Netzwerk-Gateways getestet werden.

Über die CLI:

WLCx#ping 10.48.39.133 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.48.39.133, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms WLCx#ping 10.48.39.254 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.48.39.254, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

Schritt 3: Konfigurieren der Redundanz mithilfe des RMI + RP-Paarungstyps

Bei gesicherter Verbindung zwischen den einzelnen Geräten kann zwischen den Controllern Redundanz konfiguriert werden. Dieser Screenshot zeigt, wie die Konfiguration auf der Registerkarte Redundanz der Seite Administration→ Device der 9800-Benutzeroberfläche vorgenommen wird.

Warnung: In diesem Beispiel wurde WLC1 als primärer Controller festgelegt, d. h. dieser ist derjenige, dessen Konfiguration auf den anderen Controller repliziert wird. Stellen Sie sicher, dass Sie die richtige Chassis-Priorität/-Umnummerierung anwenden, damit die richtige Konfiguration für das HA-Paar verwendet wird und kein Teil davon verloren geht.

Sehen wir uns nun die konfigurierten Felder und deren Zweck an.

• Redundanzkonfiguration: Diese muss aktiviert sein, um die Redundanz zwischen WLCs zu nutzen.
• Redundanzpaarungstyp: Da in diesem Handbuch HA SSO mit RMI-Konfiguration behandelt wird, muss als Paarungstyp RMI + RP konfiguriert werden. Dabei werden sowohl die Redundanzverwaltungsschnittstelle als auch der Redundanzport verwendet. Sie können die Redundanz auch mithilfe des Redundanz-Ports konfigurieren. Wenn jedoch nur der RP ausgewählt wird, wird die Erreichbarkeit des Gateways nicht geprüft, sondern nur der redundante WLC-Status.
• RMI-IP für Chassis 1/2: Diese Felder weisen der designierten Redundanzschnittstelle für beide Instanzen die bereitgestellten IP-Adressen zu. In diesem Beispiel wurden beide RMI-IPs für Chassis 1 und 2 als 10.48.39.131 bzw. 10.48.39.132 konfiguriert, wie zuvor beschrieben und im Netzwerkdiagramm dargestellt.
• HA-Schnittstelle: Bei Verwendung virtueller Appliances kann die Zuordnung zwischen den virtuellen Netzwerkschnittstellenkarten (vNIC) des Hypervisors und den Netzwerkschnittstellen des virtuellen Systems auf unterschiedliche Weise konfiguriert werden. Die für die Redundanz verwendete Schnittstelle kann daher für Cisco Catalyst 9800-CLs konfiguriert werden. In diesem Fall wurde GigabitEthernet 3 verwendet, wie im Bereitstellungsleitfaden für 9800-CL empfohlen.
  
  

  Hinweis: Bei Verwendung von physischen C9800-Appliances werden in HA und RP standardmäßig Schnittstellen verwendet, die nicht konfigurierbar sind. Die Hardware-9800-WLCs verfügen über eine dedizierte Redundanzschnittstelle, die von den Netzwerkschnittstellen getrennt ist.

• Management-Gateway-Failover: Wie im HA SSO-Konfigurationsleitfaden beschrieben, führt diese Redundanzmethode eine Standard-Gateway-Prüfung durch. Hierzu wird regelmäßig ein ICMP-Ping (Internet Control Message Protocol) an das Gateway gesendet. Sowohl der aktive als auch der Standby-Controller verwenden die RMI-IP als Quell-IP für diese Prüfungen. Diese Nachrichten werden in einem Intervall von 1 Sekunde gesendet.

• Gateway-Fehlerintervall: Dieser Parameter gibt die Zeit an, für die eine Gateway-Prüfung nacheinander fehlschlagen muss, bevor das Gateway als nicht erreichbar deklariert wird. Standardmäßig ist dies auf 8 Sekunden konfiguriert. Da Gateway-Prüfungen jede Sekunde gesendet werden, sind dies 8 aufeinander folgende Fehler beim Erreichen des Gateways.

• Lokale/Remote-IP: Dies ist die RP-IP, die für Chassis 1 und 2 konfiguriert wurde. Diese IP-Adressen werden automatisch als 169.254.x.x generiert, wobei x.x von den letzten beiden Oktetten der Verwaltungsschnittstelle abgeleitet wird.

• Keep Alive Timer: Wie im HA SSO-Konfigurationsleitfaden beschrieben, senden das aktive und das Standby-Chassis Keep-Alive-Nachrichten miteinander, um sicherzustellen, dass beide weiterhin verfügbar sind. Der Keep-Alive-Timer gibt die Zeitspanne zwischen dem Senden von zwei Keepalive-Nachrichten zwischen den einzelnen Chassis an. Standardmäßig werden Keepalive-Nachrichten alle 100 ms gesendet. Es wird oft empfohlen, diesen Wert mit 9800-CL zu erhöhen, um missbräuchliche Switchovers zu vermeiden, wenn die VM-Infrastruktur zu kleinen Verzögerungen (Snapshots usw.) führt.

• Keep Alive Retries (Erneut aktive Verbindungsversuche halten): In diesem Feld wird der Peer-Keepalive-Wiederholungswert konfiguriert, bevor behauptet wird, dass der Peer ausgefallen ist. Wenn sowohl der Keep-Alive-Timer als auch der wiederholte Standardwert verwendet werden, wird ein Peer deaktiviert, wenn die 5 Keep-Alive-Nachrichten, die in einem Zeitintervall von 100 ms gesendet wurden, nicht beantwortet werden (d. h., wenn die Redundanzverbindung für 500 ms deaktiviert ist).

• Chassis-Neunummerierung: die Chassis-Nummer, die die Appliance verwenden muss (1 oder 2).

  • Auf WLC2 (10.48.39.133) wird die Chassis-Nummer in 2 geändert. Standardmäßig lautet die Gehäusenummer 1. Die IP-Adressen der RP-Ports werden von RMI abgeleitet. Wenn die Gehäusenummer auf beiden Controllern identisch ist, wird die lokale RP-Port-IP-Ableitung identisch sein, und die Erkennung schlägt fehl. Nummerieren Sie das Gehäuse neu, um dieses so genannte Aktiv-Aktiv-Szenario zu vermeiden.

• Aktive Chassis-Priorität: die Priorität, mit der definiert wird, welche Konfiguration vom HA-Paar verwendet werden muss. Die Appliance mit der höchsten Priorität ist diejenige, die auf die andere repliziert wird. Die Konfiguration des Chassis mit der niedrigsten Priorität geht somit verloren.

  • Für WLC1 (10.48.39.130) wurde die aktive Chassis-Priorität auf 2 festgelegt. Dadurch soll sichergestellt werden, dass das Chassis als aktives Chassis ausgewählt wird (und daher seine Konfiguration verwendet wird).

Nachdem diese Konfigurationen vorgenommen wurden, können Sie die Konfiguration über die Schaltfläche Apply (Anwenden) auf die Controller anwenden.

Über die Kommandozeile

Konfigurieren Sie zunächst eine sekundäre IP-Adresse in der virtuellen Schnittstelle, die zum Konfigurieren des RMI auf beiden Geräten verwendet wird.

WLC1#configure terminal WLC1(config)#interface vlan 39 WLC1(config-if)# ip address 10.48.39.131 255.255.255.0 secondary WLC1(config-if)# end

WLC2#configure terminal WLC2(config)#interface vlan 39 WLC2(config-if)# ip address 10.48.39.132 255.255.255.0 secondary WLC2(config-if)# end

Aktivieren Sie dann die Redundanz auf beiden Geräten.

WLC1#configure terminal WLC1(config)#redundancy WLC1(config-red)#mode sso WLC1(config-red)#end 

WLC2#configure terminal WLC2(config)#redundancy WLC2(config-red)#mode sso WLC2(config-red)#end 

Konfiguration der Chassis-Priorität wie WLC1 wird zum primären Controller

WLC1#show chassis Chassis/Stack Mac Address : 0001.0202.aabb - Local Mac Address Mac persistency wait time: Indefinite H/W Current Chassis# Role Mac Address Priority Version State IP ------------------------------------------------------------------------------------- *1 Active 0001.0202.aabb 1 V02 Ready 169.254.39.131 WLC1#chassis 1 priority 2 WLC1#show chassis Chassis/Stack Mac Address : 0001.0202.aabb - Local Mac Address Mac persistency wait time: Indefinite H/W Current Chassis# Role Mac Address Priority Version State IP ------------------------------------------------------------------------------------- *1 Active 0001.0202.aabb 2 V02 Ready 169.254.39.131

Nummerierung des Chassis für WLC2, das zum sekundären Controller wird

WLC2#show chassis Chassis/Stack Mac Address : 0001.0202.aabb - Local Mac Address Mac persistency wait time: Indefinite H/W Current Chassis# Role Mac Address Priority Version State IP ------------------------------------------------------------------------------------- *1 Active 0001.0202.aabb 1 V02 Ready 169.254.39.132 WLC2#chassis 1 renumber 2 WLC2#show chassis Chassis/Stack Mac Address : 0001.0202.aabb - Local Mac Address Mac persistency wait time: Indefinite H/W Current Chassis# Role Mac Address Priority Version State IP ------------------------------------------------------------------------------------- *2 Active 0001.0202.aabb 1 V02 Ready 169.254.39.132 

RMI auf beiden Geräten konfigurieren

WLC1#chassis redundancy ha-interface GigabitEthernet 3 WLC1#configure terminal WLC1(config)#redun-management interface Vlan39 chassis 1 address 10.48.39.131 chassis 2 address 10.48.39.132 WLC1(config)#end

WLC2#chassis redundancy ha-interface GigabitEthernet 3 WLC2#configure terminal WLC2(config)#redun-management interface Vlan39 chassis 1 address 10.48.39.131 chassis 2 address 10.48.39.132 WLC2(config)#end

Hinweis: Für die GUI-Konfiguration auf dem virtuellen Catalyst 9800 muss die vom Controller verwendete Schnittstelle zwischen den verfügbaren Schnittstellen ausgewählt werden. Wie empfohlen wird hier GigabitEthernet 3 verwendet und mithilfe des chassis redundancy ha-interface GigabitEthernet 3 Befehls konfiguriert. Dieser Befehl ist nicht Teil der aktuellen Konfiguration. Die von HA verwendete Schnittstelle ist jedoch in den Umgebungsvariablen der Instanz ROMMON zu sehen. Diese werden mithilfe des show romvar Befehls angezeigt.

Schritt 4: Controller neu laden.

Damit sich das HA-Paar bildet und die Konfiguration wirksam ist, müssen beide Controller gleichzeitig neu geladen werden, nachdem die in Schritt 3 vorgenommene Konfiguration gespeichert wurde.

Über GUI:

Sie können die Seite "Administration Reload" (Verwaltung neu laden) beider GUI verwenden, um die Controller neu zu starten, wie in diesem Screenshot dargestellt.

Aus CLI:

WLCx#reload Reload command is being issued on Active unit, this will reload the whole stack Proceed with reload? [confirm]

Hinweis: Wenn Sie einen AAA-Server verwenden, müssen Sie auf Ihrem AAA-Server sowohl die WMI-IP-Adresse als auch die RMI-IP-Adresse als AAA-Clients hinzufügen. Der Standby-WLC verwendet zur Authentifizierung von SSH-Sitzungen immer seine RMI-IP. Der aktive WLC verwendet sowohl RMI als auch WMI, um auf den AAA-Server zuzugreifen.

Überprüfung

Sobald beide Controller des HA-Paars sich gegenseitig erkennen und das gewünschte HA-Paar erstellen, kann ein Controller (der primäre Controller) die beiden Chassis über die GUI oder CLI überwachen.


Über GUI:

Um die Redundanzkonfiguration über die 9800-Benutzeroberfläche zu überwachen, navigieren Sie von der Seite Monitoring > General > System zur Registerkarte Redundancy (Redundanz), wie in diesem Screenshot dargestellt.

Aus CLI:

WLC#show chassis rmi Chassis/Stack Mac Address : 0050.568d.cdf4 - Local Mac Address Mac persistency wait time: Indefinite H/W Current Chassis# Role Mac Address Priority Version State IP RMI-IP -------------------------------------------------------------------------------------------------------- *1 Active 0050.568d.cdf4 2 V02 Ready 169.254.39.131 10.48.39.131 2 Standby 0050.568d.2a93 1 V02 Ready 169.254.39.132 10.48.39.132

WLC#show redundancy Redundant System Information : ------------------------------ Available system uptime = 22 minutes Switchovers system experienced = 0 Standby failures = 0 Last switchover reason = none Hardware Mode = Duplex Configured Redundancy Mode = sso Operating Redundancy Mode = sso Maintenance Mode = Disabled Communications = Up Current Processor Information : ------------------------------- Active Location = slot 1 Current Software state = ACTIVE Uptime in current state = 22 minutes Image Version = Cisco IOS Software [Cupertino], C9800-CL Software (C9800-CL-K9_IOSXE), Version 17.9.2, RELEASE SOFTWARE (fc2) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2022 by Cisco Systems, Inc. Compiled Wed 02-Nov-22 15:12 by mcpre BOOT = bootflash:packages.conf,12; CONFIG_FILE = Configuration register = 0x102 Recovery mode = Not Applicable Fast Switchover = Enabled Initial Garp = Enabled Peer Processor Information : ---------------------------- Standby Location = slot 2 Current Software state = STANDBY HOT Uptime in current state = 20 minutes Image Version = Cisco IOS Software [Cupertino], C9800-CL Software (C9800-CL-K9_IOSXE), Version 17.9.2, RELEASE SOFTWARE (fc2) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2022 by Cisco Systems, Inc. Compiled Wed 02-Nov-22 15:12 by mcpre BOOT = bootflash:packages.conf,12; CONFIG_FILE = Configuration register = 0x102

Fehlerbehebung

Ein Stopp-Shop-Reflex

Die gängigen Befehle enthalten show tech wireless  keine Befehle, die ein korrektes Verständnis der HA-Failovers eines HA-Paares oder seines aktuellen Status ermöglichen. Erfassen Sie diesen Befehl, um die meisten Befehle in Bezug auf die hohe Verfügbarkeit in einem Arbeitsgang zu erhalten:

WLC#show tech wireless redundancy

Befehle anzeigen

Für den Status der Redundanz-Ports können diese Befehle verwendet werden.

WLC#show chassis detail Chassis/Stack Mac Address : 0050.568d.2a93 - Local Mac Address Mac persistency wait time: Indefinite H/W Current Chassis# Role Mac Address Priority Version State IP ------------------------------------------------------------------------------------- 1 Standby aaaa.aaaa.aaaa 2 V02 Ready 169.254.39.131 *2 Active bbbb.bbbb.bbbb 1 V02 Ready 169.254.39.132 Stack Port Status Neighbors Chassis# Port 1 Port 2 Port 1 Port 2 -------------------------------------------------------- 1 OK OK 2 2 2 OK OK 1 1 WLC#show chassis rmi Chassis/Stack Mac Address : 0050.568d.2a93 - Local Mac Address Mac persistency wait time: Indefinite H/W Current Chassis# Role Mac Address Priority Version State IP RMI-IP -------------------------------------------------------------------------------------------------------- 1 Standby aaaa.aaaa.aaaa 2 V02 Ready 169.254.39.131 10.48.39.131 *2 Active bbbb.bbbb.bbbb 1 V02 Ready 169.254.39.132 10.48.39.132 

Dieser Befehl zeigt die Gehäusenummer und den Redundanz-Portstatus an. Dies ist hilfreich bei der Fehlerbehebung im ersten Schritt.

Um die Keepalive-Zähler auf dem Keepalive-Port zu überprüfen, können Sie diese Befehle verwenden.

WLC#show platform software stack-mgr chassis active R0 sdp-counters Stack Discovery Protocol (SDP) Counters --------------------------------------- Message Tx Success Tx Fail Rx Success Rx Fail ------------------------------------------------------------------------------ Discovery 162054 2 28 0 Neighbor 23 3 12 0 Keepalive 189856 1665 187970 0 SEPPUKU 0 0 0 0 Standby Elect Req 2 0 0 0 Standby Elect Ack 0 0 2 0 Standby IOS State 0 0 4 0 Reload Req 0 0 0 0 Reload Ack 0 0 0 0 SESA Mesg 0 0 0 0 RTU Msg 0 0 0 0 Disc Timer Stop 1 0 2 0 --------------------------------------- WLC#show platform software stack-mgr chassis standby R0 sdp-counters Stack Discovery Protocol (SDP) Counters --------------------------------------- Message Tx Success Tx Fail Rx Success Rx Fail ------------------------------------------------------------------------------ Discovery 14 2 19 0 Neighbor 6 2 5 0 Keepalive 175905 0 176196 0 SEPPUKU 0 0 0 0 Standby Elect Req 0 0 1 0 Standby Elect Ack 1 0 0 0 Standby IOS State 2 0 0 0 Reload Req 0 0 0 0 Reload Ack 0 0 0 0 SESA Mesg 0 0 0 0 RTU Msg 0 0 0 0 Disc Timer Stop 1 0 0 0 --------------------------------------- WLC#show platform software stack-mgr chassis standby R0 peer-timeout Peer Chassis Peer-timeout (ms) 50% Mark 75% Mark -------------------------------------------------------------------------- 2 500 0 0 

Andere Befehle

Mit diesen Befehlen ist es möglich, eine Paketerfassung auf dem Redundanz-Port des Controllers durchzuführen.

WLC#test wireless redundancy packetdump start Redundancy Port PacketDump Start Packet capture started on RP port. WLC#test wireless redundancy packetdump stop Redundancy Port PacketDump Stop Packet capture stopped on RP port.

Mit diesen Befehlen erstellte Aufnahmen werden im bootflash: des Controllers unter dem Namen haIntCaptureLo.pcapgespeichert.

Mit diesem Befehl kann auch ein Keepalive-Test am Redundancy Port durchgeführt werden.

WLC#test wireless redundancy rping Redundancy Port ping PING 169.254.39.131 (169.254.39.131) 56(84) bytes of data. 64 bytes from 169.254.39.131: icmp_seq=1 ttl=64 time=0.316 ms 64 bytes from 169.254.39.131: icmp_seq=2 ttl=64 time=0.324 ms 64 bytes from 169.254.39.131: icmp_seq=3 ttl=64 time=0.407 ms --- 169.254.39.131 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2025ms rtt min/avg/max/mdev = 0.316/0.349/0.407/0.041 ms

Mehr Details

Mit diesem Befehl können Sie die Konfiguration der ROMMON-Variablen anzeigen, die anzeigt, wie sich die aktuelle Konfiguration auf die Variablen auswirkt.

WLC#show romvar ROMMON variables: MCP_STARTUP_TRACEFLAGS = 00000000:00000000 SWITCH_NUMBER = 2 CONFIG_FILE = BOOTLDR = STACK_1_1 = 0_0 BOOT = bootflash:packages.conf,12; LICENSE_SUITE = CHASSIS_HA_IFNAME = GigabitEthernet3 CHASSIS_HA_IFMAC = 00:50:56:8D:2A:93 SWITCH_PRIORITY = 1 RMI_INTERFACE_NAME = Vlan39 RMI_CHASSIS_LOCAL_IP = 10.48.39.132 RMI_CHASSIS_REMOTE_IP = 10.48.39.131 CHASSIS_HA_LOCAL_IP = 169.254.39.132 CHASSIS_HA_REMOTE_IP = 169.254.39.131 CHASSIS_HA_LOCAL_MASK = 255.255.255.0 RET_2_RTS = LICENSE_BOOT_LEVEL = ,csr1000v:csr1000v; BSI = 0 RET_2_RCALTS = RANDOM_NUM = 193112462

Dieser Befehl zeigt die Priorität für das Chassis an, sowohl RMI- als auch RP-Details, Peer-Timeout und weitere hilfreiche Details. 

Wir können auch die Prozesse überwachen, die HA SSO auf dem WLC ausführen. Dabei handelt es sich um zwei Prozesse, nämlich stack_mgr und rif_mgr.

Zu diesem Zweck sammeln Sie die immer auf Traces zu einer Textdatei mit dem Befehl, kann der Zeit-Parameter hier angepasst werden, um den Zeitrahmen, den wir zu beheben. 

show logging process stack_mgr start last 30 minutes to-file bootflash:stack_mgr_logs.txt show logging process rif_mgr start last 30 minutes to-file bootflash:rif_mgr_logs.txt 

Hinweis: Es ist wichtig zu beachten, dass der Service-Port des Standby-WLC deaktiviert ist und nicht erreichbar ist, während der Controller als Standby-Gerät agiert.

Typische Szenarien

Vom Benutzer erzwungen

Wenn Sie sich den Switchover-Verlauf ansehen, sehen Sie, dass "user forced" (vom Benutzer erzwungen) angezeigt wird, wenn ein Benutzer mit dem redundancy force-switchover Befehl einen Switchover zwischen den Controllern initiiert hat.

WLC#show redundancy switchover history Index Previous Current Switchover Switchover active active reason time ----- -------- ------- ---------- ---------- 1 1 2 user forced 11:38:23 Central Fri Mar 10 2023

Aktive Einheit entfernt

Wenn Sie sich den Switchover-Verlauf ansehen, sehen Sie, dass die "aktive Einheit entfernt" wurde, was auf einen Kommunikationsverlust am Redundanz-Port zwischen den beiden Controllern hindeutet.

WLC#show redundancy switchover history Index Previous Current Switchover Switchover active active reason time ----- -------- ------- ---------- ---------- 2 2 1 active unit removed 11:55:36 Central Fri Mar 10 2023

Dies kann passieren, wenn die Verbindung zwischen den beiden Controllern ausfällt, es kann aber auch passieren, wenn ein WLC plötzlich ausfällt (Stromausfall) oder abstürzt. Es ist interessant, beide WLCs zu überwachen, um festzustellen, ob sie Systemberichte haben, die auf unerwartete Abstürze/Neustarts hinweisen.

Aktiv Verloren GW

Wenn Sie sich den Switchover-Verlauf ansehen, sehen Sie "Active lost GW", was auf einen Verlust der Kommunikation mit dem Gateway am RMI-Port hinweist.

WLC#show redundancy switchover history Index Previous Current Switchover Switchover active active reason time ----- -------- ------- ---------- ---------- 3 1 2 Active lost GW 12:00:26 Central Fri Mar 10 2023

Dies ist der Fall, wenn die Verbindung zwischen dem aktiven Controller und seinem Gateway ausfällt.

Weitere Überlegungen

HA SSO für Catalyst 9800-CL

Wenn Sie in virtuellen Umgebungen arbeiten, müssen Sie akzeptieren, dass Latenz eingeführt wird, und Latenz ist nicht etwas, das HA richtig toleriert. Dies ist legitim, da Hochverfügbarkeits-SSO dazu neigt, Chassis-Fehler schnell und effizient zu erkennen. Um dies zu erreichen, überprüft jedes Chassis den Status des jeweils anderen mithilfe von Keepalives für RP- und RMI-Verbindungen sowie Pings zum Gateway ihrer RMIs (und zwar zu dem ihres WMI, der identisch sein muss). Wenn eine dieser Optionen nicht erkannt wird, reagiert der Stack abhängig von den Symptomen, die im HA SSO-Leitfaden unter "System and Network Fault Handling" (Behebung von System- und Netzwerkfehlern) beschrieben sind.

Bei der Arbeit mit virtuellen HA SSO-Stacks von Catalyst 9800 ist es üblich, Switchovers zu beobachten, da Keepalive über die RP-Verbindung versäumt hat. Dies kann auf die durch die virtualisierte Umgebung verursachte Latenz zurückzuführen sein.

Um festzustellen, ob der HA SSO-Stack unter RP-Keepalive-Drops leidet, können Sie die Stack-/Rif-Manager-Protokolle verwenden.

! Keepalives are missed 004457: Feb 4 02:15:50.959 Paris: %STACKMGR-6-KA_MISSED: Chassis 1 R0/0: stack_mgr: Keepalive missed for 2 times for Chassis 2 ! Chassis is removed %STACKMGR-6-CHASSIS_REMOVED_KA: Chassis 1 R0/0: stack_mgr: Chassis 2 has been removed from the stack due to keepalive failure. ! RP link is down 004469: Feb 4 02:17:28.707 Paris: %RIF_MGR_FSM-6-RP_LINK_DOWN: Chassis 1 R0/0: rif_mgr: Setting RP link status to DOWN ! Dual active detection 004470: Feb 4 02:17:28.707 Paris: %STACKMGR-1-DUAL_ACTIVE_CFG_MSG: Chassis 1 R0/0: stack_mgr: Dual Active Detection links are not available anymore 

Wenn beide Chassis in Betrieb sind, führt der Switchover zu einer "Dual Active Detection", die eine Folge des Herunterfahrens des RPs ist.

In einer solchen Situation kann das Anpassen der HA-Keepalive-Parameter helfen, um diese unnötigen Switchovers zu vermeiden. Es können zwei Parameter konfiguriert werden:

• Keep Alive Timer: Die Zeitspanne zwischen dem Senden von zwei Keepalive-Nachrichten zwischen den einzelnen Chassis.
• Keep Alive Retries (Erneut aktive Keepalives): Die Anzahl der Keepalives, die übersehen werden müssen, um einen Peer als inaktiv zu erklären.

Standardmäßig ist der Keep-Alive-Timer auf 1ms und der Wiederholungsversuch auf 5 gesetzt. Das bedeutet, dass nach 5ms fehlender Keepalive-Wartezeit auf der RP-Verbindung ein Switchover stattfindet. Diese Werte können für virtuelle Bereitstellungen zu niedrig sein. Wenn Sie regelmäßige Switchover-Vorgänge feststellen, weil RP-Keepalives fehlen, erhöhen Sie diese Parameter, um den Stack zu stabilisieren.

Über GUI:

Um die HA SSO-Keepalive-Parameter der 9800-GUI zu überwachen oder zu ändern, navigieren Sie von der Seite Administration > Device zur Registerkarte Redundancy (Redundanz), wie in diesem Screenshot dargestellt.

Aus CLI:

WLC#chassis redundancy keep-alive retries <5-10> WLC#chassis redundancy keep-alive timer <1-10>

Neben der Konfiguration dieser Parameter kann eine weitere Optimierung bei einem solchen Verhalten im HA SSO-Stack helfen. Bei physischen Appliances ermöglicht die Hardware das Verbinden eines Chassis mit einem anderen, in der Regel über ein einziges Kabel. In einer virtuellen Umgebung muss die Verbindung des RP-Ports für jedes Chassis über einen virtuellen Switch (vSwitch) erfolgen, der im Vergleich zu physischen Verbindungen erneut Latenz erzeugen kann. Die Verwendung eines dedizierten vSwitch zum Erstellen der RP-Verbindung ist eine weitere Optimierung, die verhindern kann, dass HA-Keepalives aufgrund von Latenz verloren gehen. Dies wird auch im Cisco Catalyst 9800-CL Wireless Controller for Cloud Deployment Guide dokumentiert. Daher ist es am besten, einen dedizierten vSwitch für die RP-Verbindung zwischen den virtuellen Systemen der Serie 9800-CL zu verwenden und sicherzustellen, dass dieser durch keinen anderen Datenverkehr beeinträchtigt wird.

Catalyst 9800 HA SSO in ACI-Bereitstellungen

Wenn ein Switchover in einem HA SSO-Stack stattfindet, verwendet das neu aktive Chassis den Gratis-ARP-Mechanismus (GARP), um die MAC-IP-Zuordnung im Netzwerk zu aktualisieren und sicherzustellen, dass der für den Controller reservierte Datenverkehr empfangen wird. Insbesondere sendet das Chassis GARP, um der neue "Eigentümer" des WMI zu werden, und stellt sicher, dass der CAPWAP-Datenverkehr das richtige Chassis erreicht.

Das Chassis, das aktiv wird, sendet eigentlich nicht nur einen einzigen GARP, sondern einen Burst davon, um sicherzustellen, dass jedes Gerät im Netzwerk seine IP-MAC-Zuordnung aktualisiert. Dieser Burst kann die ARP-Learning-Funktion der ACI überlasten. Wenn die ACI verwendet wird, wird daher empfohlen, diesen Burst in der Catalyst 9800-Konfiguration so weit wie möglich zu reduzieren.

Aus CLI:

WLC# configure terminal WLC(config)# redun-management garp-retransmit burst 0 interval 0

Neben der Begrenzung des vom 9800 während eines Switchovers initiierten GARP-Bursts wird auch empfohlen, die Funktion für schnelles Switchover auf dieser Plattform zu deaktivieren. Wenn Fast Switchover konfiguriert ist, sendet der aktive Controller eine explizite Benachrichtigung an den Standby-Controller, die besagt, dass dieser ausfällt. Auf diese Weise kann zwischen den beiden WLCs, die den HA-Stack bilden, Datenverkehr entstehen, der die Datenpakete verschachtelt (APs und Clients werden verworfen), bis einer von ihnen ausfällt. Wenn Sie diese Funktion deaktivieren, stabilisieren Sie Ihre Wireless-Infrastruktur und arbeiten gleichzeitig mit ACI-Bereitstellungen.

Aus CLI:

WLC#configure terminal WLC(config)#no redun-management fast-switchover

Vorsicht: Beachten Sie, dass der Standby-Controller bei deaktiviertem schnellen Switchover nur auf Fehler beim Keepalive-Timeout angewiesen ist, um zu erkennen, wann der aktive Controller ausgefallen ist. Diese müssen daher mit größter Sorgfalt konfiguriert werden.

Einzelheiten zu Überlegungen bezüglich Hochverfügbarkeits-SSO-Bereitstellungen für Catalyst 9800 im ACI-Netzwerk finden Sie im Abschnitt "Informationen zur Bereitstellung des ACI-Netzwerks im Controller" im Software-Konfigurationsleitfaden für Cisco Catalyst Wireless Controller der Serie 9800.

Referenzen

• 17.3 HA SSO-Leitfaden
• 17.6 HA SSO-Leitfaden