Konfigurieren von Hochverfügbarkeit SSO auf Catalyst 9800 | Kurzanleitung
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 Kenntnisse
- Catalyst Wireless 9800-Konfigurationsmodell
- Hochverfügbarkeitskonzepte, wie sie im HA SSO-Leitfaden behandelt werden.
Verwendete Komponenten
Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:
- C9800-CL v17.9.2
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.
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.
Hintergrundinformationen
Die Hochverfügbarkeits-SSO-Funktion des Wireless Controllers ermöglicht dem Access Point die Einrichtung eines CAPWAP-Tunnels mit dem aktiven Wireless Controller und dem aktiven Wireless Controller, um eine Spiegelkopie des AP und der Client-Datenbank mit dem Standby-Wireless Controller gemeinsam zu 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
Hinweis: In orange ist die temporäre IP-Adresse hervorgehoben, die der virtuellen Schnittstelle GigabitEthernet 2 des 9800-CL-Controllers zugewiesen ist, der als WLC2 bezeichnet wird. Diese IP-Adresse wird vorübergehend als WMI für WLC2 definiert und ermöglicht den Zugriff auf die grafische Benutzeroberfläche 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 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 Benutzeroberfläche, auf die unter
- die IP-Adresse 10.48.39.130 für die erste Adresse, die als WLC1 bezeichnet wird;
- 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 (Redundancy Management Interface) für Chassis 1 (WLC1) und Chassis 2 (WLC2).
Hinweis: Wenn 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 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://
/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
durch die TFTP-Server-IP, 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 msSchritt 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 über die Registerkarte Redundanz auf 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)# 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
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.131Nummerierung 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)#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)#endHinweis: 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]Ü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.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 übliche Version enthält 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 redundancyBefehle 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.Aufnahmen, die mit diesen Befehlen gemacht werden, 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 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.
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 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.
Referenzen
Revisionsverlauf
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
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)