Konfigurieren von HA SSO auf Catalyst 9800 - Kurzreferenz
Inhalt
Einleitung
In diesem Dokument wird beschrieben, wie Sie auf einem Catalyst 9800 WLC ein Stateful Switchover (SSO) mit hoher Verfügbarkeit auf RP+RMI-Basis konfigurieren.
Voraussetzungen
Anforderungen
Cisco empfiehlt, dass Sie über folgende Kenntnisse verfügen:
- Catalyst Wireless 9800-Konfigurationsmodell
- Hochverfügbarkeitskonzepte, wie sie im Leitfaden für Hochverfügbarkeits-SSO (High Availability, Hochverfügbarkeit) behandelt werden.
Verwendete Komponenten
Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:
- Catalyst 9800-CL (Version 17.12.3)
Während die HA SSO-Konfiguration nur drei davon erfordern kann, wurden hier vier IP-Adressen aus demselben Netzwerk wie die Wireless Management Interface (WMI) verwendet, um den Zugriff auf die Controller-GUI zu vereinfachen.
Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.
Hintergrundinformationen
Dank der hochverfügbaren SSO-Funktion des Wireless Controllers kann der Access Point einen CAPWAP-Tunnel mit dem aktiven Wireless Controller und dem aktiven Wireless Controller herstellen und eine Spiegelkopie der AP- und Client-Datenbank mit dem Standby Wireless Controller gemeinsam nutzen. Bei einem Switchover (d. h. wenn der aktive Controller ausfällt und der Standby-Access Point die Hand übernimmt), werden verbundene APs nicht in den Erkennungsstatus versetzt, und die Verbindung der Clients wird nicht getrennt. Es wird jeweils nur ein CAPWAP-Tunnel zwischen den APs und dem Wireless-Controller im aktiven Zustand verwaltet.
Die beiden Einheiten bilden eine Peer-Verbindung über einen dedizierten RP-Port (oder eine virtuelle Schnittstelle für VMs), und beide Controller verwenden dieselbe IP-Adresse auf der Management-Schnittstelle. Die RP-Schnittstelle dient zum Synchronisieren umfangreicher und inkrementeller Konfigurationen zur Laufzeit und zum Sicherstellen des Betriebsstatus beider Controller des HA-Paars. Darüber hinaus verfügen Standby- und Active-Controller bei Verwendung von RMI + RP über eine Redundanz-Management-Schnittstelle (RMI), der IP-Adressen zugewiesen werden, um die Gateway-Erreichbarkeit zu gewährleisten. Der CAPWAP-Status der Access Points, die sich im Ausführungszustand befinden, wird ebenfalls vom aktiven Wireless Controller zum Hot-Standby Wireless Controller synchronisiert. Auf diese Weise können die Access Points bei einem Ausfall des aktiven Wireless Controllers vollständig umgeschaltet werden. Wenn der aktive Wireless-Controller ausfällt, werden die APs nicht erkannt, und der Standby-Wireless-Controller übernimmt die Rolle des aktiven Wireless-Controllers für den Netzwerkbetrieb.
Konfigurieren
Netzwerkdiagramm
Anmerkung: In Orange ist die temporäre IP-Adresse hervorgehoben, die der virtuellen Schnittstelle GigabitEthernet 2 des 9800-CL-Controllers mit der Bezeichnung WLC2 zugewiesen ist. Diese IP-Adresse wird vorübergehend als WMI für WLC2 definiert und ermöglicht den Zugriff auf die GUI dieser Instanz, um die HA SSO-Konfiguration zu vereinfachen. Nach der Konfiguration von HA SSO wird diese Adresse freigegeben, da für ein HA SSO-Controller-Paar nur ein WMI verwendet wird.
Konfigurationen
In diesem Beispiel wird ein Stateful Switchover (SSO) mit hoher Verfügbarkeit (High Availability, Hochverfügbarkeit) zwischen zwei 9800-CL-Instanzen konfiguriert, auf denen dieselbe Cisco IOS-Softwareversion ausgeführt wird. Diese wurden mit separaten WMIs konfiguriert und verfügen über eine GUI, auf die zugegriffen werden kann:
- Die erste IP-Adresse lautet 10.48.39.130 und wird als WLC1 bezeichnet.
- Die zweite IP-Adresse lautet 10.48.39.133 und wird als WLC2 bezeichnet.
Neben diesen IP-Adressen wurden zwei weitere Adressen im gleichen Subnetz (und VLAN) verwendet, nämlich 10.48.39.131 und 10.48.39.132. Dies sind die RMI-IP-Adressen für Chassis 1 (WLC1) bzw. Chassis 2 (WLC2).
Anmerkung: Sobald HA zwischen den beiden Controllern konfiguriert ist, wird 10.48.39.133 freigegeben und 10.48.39.130 wird zum einzigen WMI meiner Konfiguration. Daher werden nach der Konfiguration nur drei IP-Adressen verwendet, die der WMI und die der RMIs.
Die Schnittstellenkonfiguration für beide Geräte muss ähnlich wie in diesem Beispiel sein, bevor die HA-Konfiguration überhaupt initiiert wird.
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 Vlan39WLC2#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 Vlan39In 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 > Verwaltung > Sicherung und Wiederherstellung) der Benutzeroberfläche von 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. Mit dem Feld Übertragungsmodus können Sie den Übertragungsmodus und das Ziel der zu sichernden Datei einfach anpassen.
Über die CLI:
WLCx#copy running-config tftp:///run-backup_x.cfg
Address or name of remote host []?
Destination filename [run-backup_x.cfg]?
!!
19826 bytes copied in 1.585 secs (12509 bytes/sec)
WLCx#copy startup-config tftp:///start-backup_x.cfg
Address or name of remote host []?
Destination filename [start-backup_x.cfg]?
!!
20482 bytes copied in 0.084 secs (243833 bytes/sec) Ersetzen Sie die
Schritt 2: (Optional) Stellen Sie die Netzwerkverbindung sicher.
Von beiden WLC-GUIs oder CLIs können Sie einfache Verbindungstests durchführen, indem Sie das Gateway von beiden Geräten aus pingen und die Geräte untereinander pingen. 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 and Traceroute" auf der Registerkarte "Troubleshooting" (Fehlerbehebung) der Benutzeroberfläche des Cisco 9800 kann die Verbindung zwischen den Controllern selbst sowie zwischen jedem WLC und seinem Netzwerk-Gateway getestet werden, wie in diesen Abbildungen gezeigt.
Ü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 msSchritt 3: Konfigurieren der Redundanz mithilfe des RMI- und RP-Paarungstyps
Bei gesicherter Verbindung zwischen den einzelnen Geräten kann zwischen den Controllern Redundanz konfiguriert werden. Dieser Screenshot zeigt, wie die Konfiguration über die Registerkarte Redundanz auf der Seite Administration > Device (Administration > Gerät) der 9800-Benutzeroberfläche vorgenommen wird.
Warnung: Für dieses Beispiel wurde WLC1 als primärer Controller festgelegt, d. h. dieser Controller wird mit seiner Konfiguration auf den anderen Controller repliziert. 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.
Überprüfen Sie die konfigurierten Felder und ihren Zweck:
-
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. Auf diese Weise wird sichergestellt, dass dieses Chassis als aktives Chassis (und damit als dessen Konfiguration) im erstellten HA-Paar ausgewählt 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)# endWLC2#configure terminal
WLC2(config)#interface vlan 39
WLC2(config-if)# ip address 10.48.39.132 255.255.255.0 secondary
WLC2(config-if)# endAktivieren 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
Die Konfiguration der Chassis-Priorität, z. B. 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.131Nummerieren Sie die Chassis für den WLC2 neu, der 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
Konfigurieren Sie RMI schließlich auf beiden Geräten.
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)#endWLC2#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)#endAnmerkung: Wie bei der GUI-Konfiguration muss auf dem virtuellen Catalyst 9800 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 romvarBefehls 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]Anmerkung: 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 wie in diesem Screenshot dargestellt zur Registerkarte Redundanz auf der Seite Monitoring > General > System (Überwachung > Allgemein > System).
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.132WLC#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 = 0x102Fehlerbehebung
Ein Stopp-Shop-Reflex
Die gängigen show tech wireless Befehle enthalten keine Befehle, mit denen die HA-Failovers eines HA-Paares oder dessen aktueller Status richtig verstanden werden können. Erfassen Sie diesen Befehl, um die meisten Befehle in Bezug auf die hohe Verfügbarkeit in einem Arbeitsgang zu erhalten:
WLC#show tech wireless redundancyshow-Befehle
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
Es ist möglich, eine Paketerfassung auf dem Redundanz-Port des Controllers mit den folgenden Befehlen 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 Verzeichnis bootflash: des Controllers unter dem Namen haIntCaptureLo.pcap gespeichert.
Mit diesem Befehl können Sie auch einen Keepalive-Test am Redundancy Port durchführen.
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 msMehr 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 = 193112462Dieser Befehl zeigt die Priorität für das Chassis an, sowohl RMI- als auch RP-Details, Peer-Timeout und weitere hilfreiche Details.
Sie 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.
Sammeln Sie dazu die stets verfügbaren Traces zu einer Textdatei mithilfe des Befehls. Der Zeitparameter kann hier so eingestellt werden, dass er den Zeitrahmen abdeckt, für den Sie eine Fehlerbehebung durchführen möchten.
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 Anmerkung: Dabei ist zu beachten, dass der Service-Port des Standby-WLC deaktiviert ist und nicht erreichbar ist, während der Controller im Standby-Modus agiert.
Typische Szenarien
Vom Benutzer erzwungen
Wenn Sie sich den Switchover-Verlauf ansehen, sehen Sie, dass Benutzer gezwungen angezeigt wird, wenn ein Benutzer mit dem Befehl redundancy force-switchover 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 2023Aktive 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 2023Dies 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 2023Dies ist der Fall, wenn die Verbindung zwischen dem aktiven Controller und seinem Gateway ausfällt.
Weitere Überlegungen
Konsolenzugriff für Standby 9800 aktivieren
Melden Sie sich bei der CLI des aktiven WLC an, und führen Sie diesen Befehl aus, um den Konsolenzugriff auf den Standby 9800 zu ermöglichen. Andernfalls ist der Konsolenzugriff auf den Standby-WLC gesperrt:
WLC#conf t
Enter configuration commands, one per line. End with CNTL/Z.
WLC(config)#redundancy
WLC(config-red)#main-cpu
WLC(config-r-mc)#standby console enable
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 System- und Netzwerkfehlermanagement aus dem HA SSO-Leitfaden beschrieben werden.
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-Erkennung, 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-Wiederholungen: Die Anzahl der Keepalive-Ereignisse, die übersehen werden müssen, um einen Peer als inaktiv zu erklären.
Standardmäßig ist der Keep-Alive-Timer auf 1ms festgelegt, und der Vorgang wird auf 5 wiederholt. Dies 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 zur Registerkarte Redundanz auf der Seite Administration > Device (Administration > Gerät), 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 0Neben 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 Keepalive-Timeout-Fehlern basiert, um einen Ausfall des aktiven Controllers zu erkennen. Diese müssen daher mit größter Sorgfalt konfiguriert werden.
Einzelheiten zu Überlegungen zu HA SSO-Bereitstellungen für Catalyst 9800 im ACI-Netzwerk finden Sie im Abschnitt Informationen zur Bereitstellung des ACI-Netzwerks im Controller-Abschnitt des Cisco Catalyst 9800 Wireless Controller Software Configuration Guide.
Referenzen
Revisionsverlauf
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
9.0 |
12-May-2026
|
Feste Header, Grammatik, Groß-/Kleinschreibung, fester Titel |
8.0 |
27-Dec-2024
|
Hinweis zum Zugriff auf die Standby-WLC-Konsole hinzugefügt |
7.0 |
13-Dec-2024
|
Aktualisierter Alternativer Text, Verknüpfungsziele und Formatierung. |
6.0 |
16-Jul-2024
|
aktualisierte Versionen und einen Hinweis zur RMI-Schnittstelle für AAA hinzugefügt |
5.0 |
06-Jun-2024
|
Abschnitt "Weitere Überlegungen" hinzugefügt |
4.0 |
25-Feb-2024
|
Hinweis zum Service-Port hinzugefügt |
3.0 |
19-Feb-2024
|
Kleine Änderung der 9800-CL-Schnittstellenkonfiguration |
2.0 |
26-Jun-2023
|
Feste Gig3-IP-Adressierung |
1.0 |
10-Mar-2023
|
Erstveröffentlichung |
FeedbackCisco kontaktieren
- Eine Supportanfrage öffnen
- (Erfordert einen Cisco Servicevertrag)