Configuration de l'authentification SSO haute disponibilité sur Catalyst 9800 | Guide de démarrage rapide

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

Dans cet exemple, WLC1 est désigné comme contrôleur principal (c'est-à-dire le châssis 1) tandis que WLC2 est le contrôleur secondaire (c'est-à-dire le châssis 2). Cela signifie que la paire HA composée des 2 contrôleurs utilise la configuration du WLC1 et que celui du WLC2 est perdu après le processus.

Étape 1. (Facultatif) Sauvegardez les fichiers de configuration de démarrage et de configuration en cours des contrôleurs.

Une mauvaise manipulation peut se produire et entraîner une perte de configuration. Pour éviter cela, il est vivement recommandé de sauvegarder la configuration initiale et la configuration en cours à partir des deux contrôleurs utilisés dans la configuration haute disponibilité. Vous pouvez facilement le faire à l'aide de l'interface graphique utilisateur ou de la CLI du 9800.

À partir de la GUI :

Dans l'onglet Administration → Management → Backup & Restore de l'interface graphique utilisateur du 9800 (reportez-vous à la capture d'écran), vous pouvez télécharger la configuration de démarrage et en cours actuellement utilisée par le contrôleur.

Dans cet exemple, le démarrage (côté gauche) et la configuration (côté droit) sont directement téléchargés, via HTTP, sur le périphérique qui héberge le navigateur utilisé pour accéder à l'interface graphique utilisateur du WLC. Le champ Mode de transfert permet de modifier facilement le mode de transfert et la destination du fichier à sauvegarder.

À partir de la CLI :

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

Remplacez le <SERVER-IP> par l'adresse IP du serveur TFTP vers lequel le fichier de configuration initiale/en cours est copié.

Étape 2. (Facultatif) Vérifiez la connectivité réseau.

À partir des interfaces utilisateur graphiques WLC ou des interfaces de ligne de commande, on peut effectuer des tests de connectivité simples, à savoir envoyer une requête ping à la passerelle à partir des deux périphériques et envoyer une requête ping aux périphériques entre eux. Cela garantit que les deux contrôleurs disposent de la connectivité requise pour configurer la haute disponibilité.

À partir de la GUI :

L'outil Ping and Traceroute de l'onglet Troubleshooting de l'interface graphique 9800 peut être utilisé afin de tester la connectivité entre les contrôleurs eux-mêmes et entre chaque WLC et sa passerelle réseau, comme illustré dans ces figures.

À partir de la 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

Étape 3. Configurez la redondance avec le type de couplage RMI + RP.

Une fois la connectivité entre chaque périphérique assurée, la redondance peut être configurée entre les contrôleurs. Cette capture d'écran montre comment la configuration est effectuée à partir de l'onglet Redondance de la page Administration→ Device de l'interface utilisateur graphique du 9800.

Avertissement : pour cet exemple, WLC1 a été désigné comme contrôleur principal, ce qui signifie que c'est celui dont la configuration est répliquée sur l'autre contrôleur. Assurez-vous d'appliquer la priorité/renumérotation de châssis appropriée afin d'utiliser la configuration appropriée avec votre paire haute disponibilité et de ne pas en perdre une partie.

Passons en revue les champs configurés et leur objectif

• Configuration de la redondance : cette option doit être activée afin d'utiliser la redondance entre les WLC.
• Type d'appariement de redondance : étant donné que ce guide couvre l'authentification unique haute disponibilité à l'aide de la configuration RMI, le type d'appariement configuré doit être RMI + RP, à l'aide de l'interface de gestion de redondance et du port de redondance. On peut également choisir de configurer la redondance en utilisant uniquement le port de redondance. Cependant, lorsque RP seulement est choisi, l'accessibilité de la passerelle n'est pas vérifiée, seul l'état du WLC redondant est
• RMI IP for Chassis 1/2 : ces champs attribuent les adresses IP fournies à l'interface de redondance désignée pour les deux instances. Dans cet exemple, les deux adresses IP RMI pour les châssis 1 et 2 ont été configurées comme étant respectivement 10.48.39.131 et 10.48.39.132, comme décrit précédemment et illustré dans le schéma du réseau.
• Interface haute disponibilité : lors de l'utilisation d'appareils virtuels, le mappage entre les cartes d'interface réseau virtuelles (vNIC) de l'hyperviseur et les interfaces réseau de la machine virtuelle peut être configuré de différentes manières. Par conséquent, l'interface utilisée pour la redondance peut être configurée pour les commutateurs Cisco Catalyst 9800-CL. Ici, le GigabitEthernet 3 a été utilisé, comme recommandé par le guide de déploiement du 9800-CL.
  
  

  Remarque : lorsque vous utilisez des appliances C9800 physiques, les interfaces utilisées dans HA et RP sont les interfaces par défaut et ne sont pas configurables. En effet, les WLC 9800 matériels ont une interface de redondance dédiée qui est séparée de leurs interfaces réseau.

• Basculement de la passerelle de gestion : comme détaillé dans le guide de configuration de HA SSO, cette méthode de redondance implémente la vérification de la passerelle par défaut, effectuée en envoyant régulièrement une requête ping ICMP (Internet Control Message Protocol) à la passerelle. Les contrôleurs actif et en veille utilisent l'adresse IP RMI comme adresse IP source pour ces vérifications. Ces messages sont envoyés à un intervalle d'une seconde.

• Intervalle de défaillance de la passerelle : indique la durée pendant laquelle une vérification de la passerelle doit échouer consécutivement avant que la passerelle ne soit déclarée inaccessible. Par défaut, cette valeur est configurée sur 8 secondes. Comme les vérifications de passerelle sont envoyées toutes les secondes, cela représente 8 échecs consécutifs pour atteindre la passerelle.

• Local/Remote IP : il s'agit de l'adresse IP RP configurée pour les châssis 1 et 2. Ces adresses IP sont générées automatiquement sous la forme 169.254.x.x, où x.x est dérivé des deux derniers octets de l’interface de gestion.

• Minuteur de maintien de la connexion : comme indiqué dans le guide de configuration de l'authentification unique haute disponibilité, les châssis actif et de secours s'envoient mutuellement des messages de maintien de la connexion pour s'assurer que les deux sont toujours disponibles. Le compteur de test d'activité correspond au temps séparant l'envoi de 2 messages de test d'activité entre chaque châssis. Par défaut, les messages keep-alive sont envoyés toutes les 100 ms. Il est souvent recommandé d'augmenter cette valeur avec le 9800-CL pour éviter les basculements abusifs à chaque fois que l'infrastructure de VM introduit de petits retards (instantanés, etc.)

• Keep Alive Retries : ce champ configure la valeur keepalive retry de l'homologue avant de prétendre que l'homologue est hors service. Si le minuteur de maintien de la connexion et la valeur par défaut réessayée sont utilisés, un homologue est désactivé si les 5 messages de maintien de la connexion envoyés à un intervalle de 100 ms restent sans réponse (c'est-à-dire si la liaison de redondance est désactivée pendant 500 ms).

• Renumérotation du châssis : numéro de châssis que le matériel doit utiliser (1 ou 2).

  • Sur WLC2 (10.48.39.133), le châssis est renuméroté 2. Par défaut, le numéro de châssis est 1. Les adresses IP des ports RP sont dérivées de RMI. Si le numéro de châssis est le même sur les deux contrôleurs, la dérivation IP du port RP local est la même et la détection échoue. Renumérotez le châssis pour éviter ce scénario dit « actif-actif ».

• Priorité active du châssis : priorité utilisée pour définir la configuration à utiliser par la paire haute disponibilité. L'appliance dont la priorité est la plus élevée est celle qui est répliquée sur l'autre. La configuration du châssis avec la priorité la plus basse est donc perdue.

  • Sur WLC1 (10.48.39.130), la priorité de châssis active a été définie sur 2. Cela permet de s'assurer que ce châssis est choisi comme châssis actif (et donc que sa configuration est utilisée) dans la paire haute disponibilité créée.

Une fois ces configurations effectuées, utilisez le bouton Apply pour appliquer la configuration aux contrôleurs.

À partir de la CLI

Configurez d'abord une adresse IP secondaire dans l'interface virtuelle utilisée pour configurer l'interface RMI sur les deux périphériques.

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

Activez ensuite la redondance sur les deux périphériques

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 

Configurez la priorité du châssis telle que WLC1 devient le contrôleur principal

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

Renuméroter le châssis pour WLC2 qui devient le contrôleur secondaire

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 

Enfin, configurez RMI sur les deux périphériques

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

Remarque : comme pour la configuration de l'interface graphique, sur le Catalyst 9800 virtuel, l'interface utilisée par le contrôleur doit être sélectionnée parmi celles disponibles. Comme recommandé, GigabitEthernet 3 est utilisé ici et configuré grâce à la chassis redundancy ha-interface GigabitEthernet 3 commande. Cette commande ne fait pas partie de la configuration en cours, mais l'interface utilisée par HA peut être vue dans les variables d'environnement ROMMON de l'instance. Vous pouvez les afficher à l'aide de la show romvar commande.

Étape 4. Rechargez les contrôleurs.

Pour que la paire haute disponibilité se forme et que la configuration soit efficace, les deux contrôleurs doivent être rechargés en même temps une fois que la configuration effectuée à l'étape 3 a été enregistrée.

À partir de la GUI :

Vous pouvez utiliser la page Administration Reload des deux interfaces utilisateur graphiques pour redémarrer les contrôleurs, comme illustré dans cette capture d'écran.

À partir de CLI :

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

Remarque : si vous utilisez un serveur AAA, vous devez ajouter l'adresse IP WMI ainsi que l'adresse IP RMI en tant que clients AAA sur votre serveur AAA. Le WLC en veille utilise toujours son IP RMI pour authentifier les sessions SSH. Le WLC actif utilise à la fois RMI et WMI pour atteindre le serveur AAA.

Vérifier

Une fois que les deux contrôleurs de la paire haute disponibilité se découvrent et créent la paire haute disponibilité souhaitée, un contrôleur (le contrôleur principal) peut surveiller les deux châssis à partir de l'interface graphique utilisateur ou de l'interface de ligne de commande.


À partir de la GUI :

Pour surveiller la configuration de la redondance à partir de l'interface graphique utilisateur du 9800, accédez à l'onglet Redondance à partir de la page Surveillance > Général > Système, comme illustré dans cette capture d'écran.

À partir de 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

Dépannage

réflexes guichets uniques

La commande habituelle n'inclut show tech wireless  pas de commandes permettant de comprendre correctement les basculements haute disponibilité d'une paire haute disponibilité ni son état actuel. Collectez cette commande afin d'avoir la plupart des commandes relatives à la haute disponibilité en une seule opération :

WLC#show tech wireless redundancy

Commandes show

Pour connaître l'état des ports de redondance, ces commandes peuvent être utilisées.

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 

Cette commande indique le numéro de châssis et l'état du port de redondance, ce qui est utile dans une première étape de dépannage.

Afin de vérifier les compteurs keepalive sur le port keepalive, on peut utiliser ces commandes.

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 

Autres commandes

Il est possible de prendre une capture de paquet sur le port de redondance du contrôleur avec ces commandes

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.

Les captures effectuées à l'aide de ces commandes sont enregistrées dans le bootflash: du contrôleur, sous le nom haIntCaptureLo.pcap.

Vous pouvez également exécuter un test keepalive sur le port de redondance avec cette commande.

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

En savoir plus

Pour afficher la configuration des variables ROMMON qui nous montre comment la configuration réelle est reflétée sur les variables, vous pouvez utiliser cette commande.

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

Cette commande affiche la priorité du châssis, les détails RMI et RP, le délai d'attente des homologues ainsi que des détails plus utiles. 

Nous pouvons également surveiller les processus qui exécutent HA SSO sur le WLC qui sont deux processus, à savoir stack_mgr et rif_mgr.

Pour ce faire, collectez les traces toujours actives dans un fichier texte à l'aide de la commande, le paramètre de temps ici peut être ajusté pour couvrir la période que nous voulons dépanner. 

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 

Remarque : il est important de noter que le port de service du WLC en veille est désactivé et inaccessible pendant que le contrôleur agit en tant que standby.

Scénarios types

Utilisateur forcé

Si vous regardez l'historique de basculement, vous pouvez voir "user forced", qui apparaît quand un utilisateur a initié un basculement entre les contrôleurs, en utilisant la redundancy force-switchover commande.

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

Unité active supprimée

Si vous regardez l'historique de commutation, vous pouvez voir « unité active retirée » qui indique une perte de communication sur le port de redondance entre les deux contrôleurs.

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

Cela peut se produire si la liaison entre les deux contrôleurs tombe en panne, mais cela peut également se produire si une unité WLC tombe soudainement en panne (panne de courant) ou tombe en panne. Il est intéressant de surveiller les deux WLC pour voir s'ils ont des rapports système qui indiquent des pannes/redémarrages inattendus.

GW perdue active

Si vous regardez l'historique de commutation, vous pouvez voir « Active lost GW » qui indique une perte de communication avec la passerelle sur le port RMI.

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

Cela se produit si la liaison entre le contrôleur actif et sa passerelle tombe en panne.

Autres considérations

SSO HA pour Catalyst 9800-CL

Lorsque vous travaillez dans des environnements virtuels, vous devez accepter que la latence est introduite et que la latence n'est pas tolérée correctement par la haute disponibilité. Ceci est légitime, car HA SSO a tendance à détecter rapidement et efficacement toute défaillance du châssis. Pour ce faire, chaque châssis vérifie l'état de l'autre en utilisant des keepalives sur les liaisons RP et RMI ainsi que des pings vers la passerelle de leurs RMI (et ceci, celui de leur WMI qui doit être le même). Si l'un de ces problèmes n'est pas détecté, la pile réagit en fonction des symptômes, comme indiqué dans la section « Gestion des pannes du système et du réseau » du guide de l'authentification unique haute disponibilité.

Lors de l'utilisation de piles SSO HA virtuelles de Catalyst 9800, il est courant d'observer des commutations en raison d'une absence de keepalive sur la liaison RP. Cela peut être dû à la latence introduite par l'environnement virtualisé.

Pour déterminer si la pile HA SSO souffre de pertes de keepalive RP, vous pouvez utiliser les journaux du gestionnaire de pile/rif.

! 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 

Si les deux châssis fonctionnent, le basculement crée une « double détection active » qui est une conséquence des pertes sur le RP.

Dans ce cas, il peut être utile de modifier les paramètres de test d'activité haute disponibilité pour éviter ces basculements inutiles. Deux paramètres peuvent être configurés,

• Minuteur de maintien de la connexion : durée séparant l'envoi de 2 messages de maintien de la connexion entre chaque châssis.
• Tentatives de maintien de la connexion : nombre de tentatives de maintien de la connexion qui doivent être manquées pour déclarer un homologue inactif.

Par défaut, le minuteur de maintien de la connexion est défini sur 1ms et le système réessaie sur 5. Cela signifie qu'après 5 ms de keepalive manqués sur la liaison RP, une commutation se produit. Ces valeurs peuvent être trop faibles pour les déploiements virtuels. Si vous rencontrez une commutation récurrente en raison de messages de test d'activité RP manqués, essayez d'augmenter ces paramètres pour stabiliser la pile.

À partir de la GUI :

Pour surveiller ou modifier les paramètres de keepalive de HA SSO à partir de l'interface graphique utilisateur du 9800, accédez à l'onglet Redundancy de la page Administration > Device, comme illustré dans cette capture d'écran.

À partir de CLI :

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

En plus de la configuration de ces paramètres, une autre optimisation peut aider avec un tel comportement dans la pile HA SSO. Pour un appareil physique, le matériel permet de connecter un châssis à un autre, généralement à l'aide d'un seul câble. Dans un environnement virtuel, l'interconnexion du port RP pour chaque châssis doit être effectuée par un commutateur virtuel (vSwitch), qui peut à nouveau introduire une latence par rapport aux connexions physiques. L'utilisation d'un commutateur virtuel dédié pour créer la liaison RP est une autre optimisation qui peut empêcher la perte de messages de veille haute disponibilité en raison de la latence. Ceci est également décrit dans le Guide de déploiement du contrôleur sans fil Cisco Catalyst 9800-CL pour le cloud. Par conséquent, le mieux est d'utiliser un commutateur virtuel dédié pour la liaison RP entre les machines virtuelles 9800-CL et de s'assurer qu'aucun autre trafic ne l'interfère.

Catalyst 9800 HA SSO Déploiements ACI internes

Lorsqu'une commutation se produit dans une pile HA SSO, le châssis nouvellement actif utilise le mécanisme ARP gratuit (GARP) pour mettre à jour le mappage MAC vers IP dans le réseau et s'assurer qu'il reçoit le trafic dédié au contrôleur. En particulier, le châssis envoie GARP pour devenir le nouveau « propriétaire » du WMI et s'assurer que le trafic CAPWAP atteint le châssis approprié.

En fait, le châssis qui devient actif n'envoie pas un seul GARP, mais une rafale d'entre eux afin de s'assurer que n'importe quel périphérique du réseau met à jour son mappage IP/MAC. Cette rafale peut submerger la fonction d'apprentissage ARP de l'ACI et, par conséquent, lorsque l'ACI est utilisée, il est recommandé de réduire cette rafale autant que possible à partir de la configuration du Catalyst 9800.

À partir de CLI :

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

Outre la limitation de la rafale GARP initiée par le 9800 lors d'une commutation, il est également recommandé de désactiver la fonctionnalité de commutation rapide sur cette plate-forme. Lorsque la commutation rapide est configurée, le contrôleur actif envoie une notification explicite au contrôleur en veille, indiquant qu'il est en panne. Lors de l'utilisation de ceci, le trafic entrelacé peut exister (AP et clients abandonnés) entre les deux WLC formant la pile HA jusqu'à ce que l'un d'eux tombe en panne. Ainsi, la désactivation de cette fonctionnalité permet de stabiliser votre infrastructure sans fil tout en travaillant avec les déploiements ACI.

À partir de CLI :

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

Attention : Gardez à l'esprit que lorsque la commutation rapide est désactivée, le contrôleur en veille se base uniquement sur les échecs de temporisation keepalive pour détecter quand le contrôleur actif est tombé en panne. Il faut donc les configurer avec le plus grand soin.

Pour plus d'informations sur les considérations relatives aux déploiements SSO HA pour le Catalyst 9800 au sein du réseau ACI, reportez-vous à la section « Information About Deploying ACI Network in Controller » du Guide de configuration du logiciel du contrôleur sans fil de la gamme Cisco Catalyst 9800.

Références

• 17.3 Guide HA SSO
• Guide SSO 17,6 HA