Konfigurieren von Hochverfügbarkeits-SSO auf Catalyst 9800 | Schnellstartanleitung

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 HA SSO-Leitfaden 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

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

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 (Redundancy Management Interface) für Chassis 1 (WLC1) und Chassis 2 (WLC2).

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 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 > 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   durch die TFTP-Server-IP, in die die Start-/aktuelle Konfigurationsdatei kopiert wird.

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 ms

Schritt 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.

Überprüfen Sie die konfigurierten Felder und ihren Zweck.

• Redundanzkonfiguration: Diese Funktion muss aktiviert sein, damit Redundanz zwischen WLCs genutzt werden kann.

• Redundanzpaarungstyp: Da in diesem Leitfaden HA SSO mit RMI-Konfiguration behandelt wird, muss als Paarungstyp RMI + RP konfiguriert werden. Dabei werden sowohl die Redundanzmanagement-Schnittstelle als auch der Redundanzport verwendet. Sie können die Redundanz auch mithilfe des Redundanz-Ports konfigurieren. Wird jedoch nur der RP gewählt, wird die Erreichbarkeit des Gateways nicht geprüft, sondern nur der redundante WLC-Zustand.

• RMI IP for Chassis 1/2 (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.
  
  

  Anmerkung: 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, implementiert diese Redundanzmethode die Überprüfung des Standard-Gateways, indem regelmäßig ICMP-Pings (Internet Control Message Protocol) an das Gateway gesendet werden. Sowohl der aktive als auch der Standby-Controller verwenden die RMI-IP als Quell-IP für diese Prüfungen. Diese Meldungen werden in Intervallen von 1 Sekunde gesendet.

• Gateway Failure Interval (Gateway-Ausfallintervall): Dieser Wert 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.

• Erhalten-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-Wiederholungen: 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).

• Gehäuse neu nummerieren: die Chassis-Nummer, die die Appliance verwenden muss (1 oder 2).

  • Auf WLC2 (10.48.39.133) wird das Chassis in 2 umnummeriert. Die Chassis-Nummer lautet standardmäßig 1. IP-Adressen von 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. 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)# 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

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.131

Nummerieren 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)#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

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 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.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ängigenshow tech wirelessBefehle 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 redundancy

show-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.

Aufnahmen, die mit diesen Befehlen gemacht werden, werden im bootflash: des Controllers unter dem Namen haIntCaptureLo.pcapgespeichert.

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 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. 

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 

Typische Szenarien

Vom Benutzer erzwungen

Wenn Sie sich den Switchover-Verlauf ansehen, können Sie sehen, dass Benutzer erzwungen wird, wenn ein Benutzer mit demredundancy force-switchoverBefehl 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 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:

1. Keep Alive Timer: Die Zeitspanne zwischen dem Senden von zwei Keepalive-Nachrichten zwischen den einzelnen Chassis.
2. 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 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

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

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