Introduction
Ce document décrit les problèmes liés à la non-concordance des états UPF dans RCM.
Conditions préalables
Exigences
Aucune exigence spécifique n'est associée à ce document.
Composants utilisés
Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :
- Gestionnaire de configuration de redondance (RCM)
- Fonction du plan utilisateur (UPF/UP)
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.
Collecte des journaux
MCR
Étape 1. Capturer certaines sorties de commande
Tout d'abord, vous devez identifier ce qui est le problème UP et quel est le modèle de la question. Afin de déterminer les UP qui ont subi un basculement et d'identifier où se trouve le problème actuel, il est essentiel de documenter les raisons des basculements.
rcm show-statistics switchover
rcm show-statistics switchover-verbose
rcm show-statistics configmgr --------------- to check how many UPs are registered for config push
rcm show-statistics controller --------------- to check no of UPs and its states registered with controller
Étape 2. Collecter les journaux du contrôleur et de Configmgr
Une fois que vous avez identifié parmi les UP le problème réside, vous pouvez collecter les journaux du contrôleur et les journaux de configmgr afin d'identifier ce qui a été la cause de la commutation et ce qui a mal tourné pour les UP de rester bloqués dans l'état En attente.
Reportez-vous au lien RCM Log Collection pour la procédure de collecte de journaux.
VERS LE HAUT
Les traps SSD, Syslog et SNMP pour l'horodatage problématique couvrent la période au moins deux heures avant le début du problème.
Dépannage
Scénario de blocage des UP dans l'état En attente
- En général, chaque UP s'enregistre auprès du RCM via le contrôleur
- Le contrôleur est responsable de la maintenance des états UP qu'il reçoit de UP et de celui attribué par RCM et de la compilation de ces états
rcm show-statistics controller
message :
{
"keepalive_version": "f1ab207c5d3120f8a4286b999b9f4cd207034e7c61e204d74e41f48578c476de",
"keepalive_timeout": "20s",
"num_groups": 2,
"groups": [
{
"groupid": 1,
"endpoints_configured": 7,
"standby_configured": 1,
"pause_switchover": false,
"active": 2,
"standby": 0,
"endpoints": [
{
"endpoint": "X.X.X.X", -------- UP IP
"bfd_status": "STATE_UP",
"upf_registered": true,
"upf_connected": true,
"upf_state_received": "UpfMsgState_Active",
"bfd_state": "BFDState_UP",
"upf_state": "UPFState_PendActive",
"route_modifier": 32,
"pool_received": false,
"echo_received": 253,
"management_ip": "X.X.X.X",
"host_id": "SEUD2413",
"ssh_ip": "Y.Y.Y.Y",
"force_nso_registration": false
},
Dans les statistiques du contrôleur, s'il est observé, il y a différents états que le contrôleur maintient et chaque état UP a sa propre signification.
État BFD : indique l'état BFD entre RCM et UP (ne l'appelez pas état UF, il s'agit uniquement de l'état BFD)
État UPF : état actuel de l'UPF dans le RCM
État UPF reçu - État UP envoyé par UP vers RCM
- D'après le flux en général, chaque fois qu'il y a un basculement de Active UP vers Standby UP, le RCM doit subir certaines procédures pour des transferts en douceur mentionnées ici :
1. Vidage Checkpoint Mgr de l'ancien UP et synchronisation du point de contrôle avec le nouveau UP actif
2. Config flush
3. Config push
4. Gestion des états UP
Considérez l'exemple de paire UP comme UP-A (Active UP) et UP-B (Standby-UP) et quand il y a un basculement avant de passer à l'état Actif et Standby, il passe d'abord à l'état En attente.
UP-A (UP actif) --------------------- PendStandby ---------------------- Standby
UP-B (veille UP) ------------------- PendActive ---------------------- Active
Comme on peut le voir avant de passer à l'état Actif/Veille, les transactions procédurales mentionnées se produisent entre le RCM et l'UP afin d'assurer une commutation en douceur.
- Chaque fois qu'il y a un basculement d'Active vers Standby et vice versa, le RCM doit effectuer une poussée de configuration où il pousse la configuration Active UP dans l'UP qui devient Active, et pousse la configuration Standby UP dans l'UP qui devient Standby.
Note :: In Standby UP normally RCM push all the UP config which are currently active so that whenever this UP becomes active it removes all the unwanted config
- Dès que la commutation est initiée, le RCM a une valeur de minuteur de 15 minutes (elle varie en fonction de la valeur configurée) et dans cette valeur de minuteur, il doit effectuer la commutation qui se termine une fois que le push de configuration est terminé.
- Dans le cas contraire, si la configuration n'est pas diffusée dans le délai imparti, le temporisateur expire et le RCM lance le rechargement vers le haut. Cette opération se poursuit jusqu'à la fin de la configuration push.
- Ainsi, lorsque le RCM transmet la configuration à l'état UP, il attend un signal de fin de configuration de l'état UP, indiquant que le RCM comprend que la configuration est terminée et qu'il considère la commutation comme réussie.
Il s'agit du journal qui peut être vu à partir des syslogs et des déroutements SNMP lorsque le push de configuration est terminé.
Syslogs
Nov 13 12:01:09 INVIGJ02GNR1D1UP12CO evlogd: [local-60sec9.041] [cli 30000 debug] [1/0/10935 <cli:1010935> cliparse.c:571] [context: local, contextID: 1] [software internal system syslog] CLI command [user rcmadmin, mode [local]INVIGJ02GNR1D1UP12CO]: rcm-config-push-complete
Nov 13 12:01:09 INVIGJ02GNR1D1UP12CO evlogd: [local-60sec9.041] [cli 30000 debug] [1/0/10935 <cli:1010935> cliparse.c:571] [context: local, contextID: 1] [software internal system syslog] CLI command [user rcmadmin, mode [local]INVIGJ02GNR1D1UP12CO]: rcm-config-push-complete end-of-config
SNMP
Fri Mar 24 09:59:01 2023 Internal trap notification 1425 (RCMTCPConnect) Context Name: rcm
Fri Mar 24 09:59:01 2023 Internal trap notification 1421 (RCMConfigPushCompleteSent) Context Name: rcm
Fri Mar 24 09:59:01 2023 Internal trap notification 1426 (RCMChassisState) RCM Chassis State: (2) Chassis State Standby
Fri Mar 24 09:59:04 2023 Internal trap notification 1276 (BFDSessionUp) vpn n6 OurAddr fc00:10:5:132::10 NeighborAddr fc00:10:5:132::254 Session(6/1090552866), Diagnostic code 0 PhyPortId 0
- Mais dans le cas où il y a un problème en raison duquel la fin de la poussée de configuration prend du temps qui provoque l'expiration de la valeur du minuteur, alors de tels problèmes de UP bloqué dans l'état En attente se produisent.
- Comme le RCM n'a pas obtenu l'état de fin de transmission de la configuration, il considère que le basculement n'est pas terminé et conserve l'état UP en attente.
- Différentes raisons pour les problèmes de diffusion de configuration sont expliquées dans Causes de rechargement UP.
Solution de contournement
1. Vous pouvez temporairement appliquer le signal de configuration push complete de UP vers RCM avec cette commande mentionnée afin de ramener le UP dans l'état Actif/Veille :
rcm-config-push-complete end-of-config
2. Cette solution de contournement mentionnée n'est que temporaire afin d'identifier le problème qui prend du temps pour le push de configuration qui est décrit dans Causes de rechargement UP.
Commentaires