Einleitung
In diesem Dokument werden die Probleme im Zusammenhang mit der Ungleichheit der UPF-Zustände im RCM beschrieben.
Voraussetzungen
Anforderungen
Es gibt keine spezifischen Anforderungen für dieses Dokument.
Verwendete Komponenten
Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:
- Redundanz-Konfigurationsmanager (RCM)
- Benutzerebenenfunktion (UPF/UP)
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.
Protokollauflistung
RCM
Schritt 1: Erfassen einiger Befehlsausgaben
Erstens müssen Sie feststellen, welches die problematische UP ist und welches Muster das Problem darstellt. Um festzustellen, bei welchen UPs ein Switchover aufgetreten ist, und um zu ermitteln, wo sich das aktuelle Problem befindet, müssen die Gründe für den Switchover dokumentiert werden.
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
Schritt 2: Erfassen von Controller- und Konfigurationsmgr-Protokollen
Wenn Sie festgestellt haben, unter welchen UPs das Problem liegt, können Sie Controller-Protokolle und Konfigurationsmgr-Protokolle sammeln, um die Ursache für den Switchover und die Ursache für den fehlerhaften Zustand der UPs im Status "Ausstehend" zu ermitteln.
Informationen zum Protokollsammelverfahren finden Sie unter dem Link RCM Log Collection (Protokollsammlung).
UP
SSD-, Syslogs- und SNMP-Traps für den problematischen Zeitstempel decken den Zeitrahmen mindestens zwei Stunden vor Beginn des Problems ab.
Fehlerbehebung
Szenario für UPs, die im Status "Ausstehend" feststecken
- Im Allgemeinen registriert sich jeder UP über den Controller selbst beim RCM
- Der Controller ist für die Aufrechterhaltung der UP-Zustände, die er vom UP empfängt, und den vom RCM zugewiesenen, sowie für deren Kompilierung verantwortlich.
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
},
In der Controller-Statistik gibt es, wenn beobachtet, verschiedene Zustände, die der Controller aufrechterhält, und jeder UP-Zustand hat seine eigene Bedeutung.
BFD-Status - gibt den BFD-Status zwischen RCM und UP an (nicht als UF-Status, sondern nur BFD-Status)
UPF-Status - Der aktuelle Status des UPF im RCM
UPF-Status empfangen - UP-Status von UP an RCM gesendet
- Generell muss der RCM bei einem Switchover von Active UP zu Standby UP bestimmten Prozeduren für einen reibungslosen Handover unterzogen werden, die hier erwähnt sind:
1. CheckpointMgr-Leerung aus dem alten UP und Checkpoint-Synchronisierung mit dem neuen aktiven UP
2. Konfig. leeren
3. Push der Konfiguration
4. Verwalten von UP-Zuständen
Betrachten Sie das Beispiel eines UP-Paars als UP-A (Active UP) und UP-B (Standby-UP). Wenn ein Switchover stattfindet, bevor der Status in den Status "Active" und "Standby" wechselt, wechselt er zuerst in den Status "Pending" (Ausstehend).
UP-A (Aktiv UP) --------------------- PendStandby ---------------------- Standby
UP-B (Standby-UP) ------------------- PendActive ---------------------- Active
Wie bereits zu erkennen ist, werden die genannten Prozedurtransaktionen zwischen RCM und UP durchgeführt, um einen reibungslosen Switchover zu ermöglichen.
- Wenn ein Switchover von Aktiv zu Standby und umgekehrt stattfindet, muss der RCM eine Konfigurationsübergabe durchführen, bei der die Aktiv-UP-Konfiguration in den UPs übertragen wird, die dann zu Aktiv wird, und die Standby-UP-Konfiguration in den UPs übertragen wird, die in den Standby-Modus übergehen.
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
- Sobald der Switchover initiiert wird, hat der RCM einen Timer-Wert von 15 Minuten (er variiert je nach konfiguriertem Wert). Innerhalb dieses Timer-Werts muss er den Switchover abschließen, der abgeschlossen wird, sobald die Konfiguration abgeschlossen ist.
- Falls der Konfigurationsabruf nicht innerhalb der Zeitspanne abgeschlossen ist, die der Timer abläuft, und der RCM das erneute Laden auf den UP initiiert, kann dies aus irgendeinem Grund geschehen. Dieser Vorgang wird fortgesetzt, bis das Push der Konfiguration abgeschlossen ist.
- Wenn der RCM die Konfiguration auf "UP" (aktiv) setzt, erwartet er daher von "UP" (aktiv) ein vollständiges Konfigurationssignal, anhand dessen der RCM erkennt, dass der Konfigurations-Push abgeschlossen ist, und ihn als erfolgreichen Switchover ansieht.
Dies ist das Protokoll, das von den Syslogs und den SNMP-Traps angezeigt wird, wenn die Konfiguration abgeschlossen ist.
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
- Falls jedoch ein Problem vorliegt, aufgrund dessen die Beendigung des Konfigurationsabrufs Zeit in Anspruch nimmt, wodurch der Timer-Wert abläuft, treten solche Probleme mit UP auf, die im Status "Ausstehend" festgehalten werden.
- Da der RCM den Push-Abschlussstatus für die Konfiguration nicht erhalten hat, wird der Switchover als nicht abgeschlossen angesehen und der Status "UP" (Aktiviert) wird beibehalten.
- Verschiedene Gründe für Probleme mit der Konfigurationsübergabe werden unter Ursachen von UP-Neuladen erläutert.
Problemumgehung
1. Vorübergehend können Sie mit diesem Befehl das "config push complete"-Signal von UP auf RCM erzwingen, um UP im Aktiv/Standby-Status wiederherzustellen:
rcm-config-push-complete end-of-config
2. Diese Problemumgehung ist nur vorübergehend, um das Problem zu identifizieren, das Zeit für das Push der Konfiguration benötigt, das unter Ursachen von UP-Neuladen beschrieben wird.
Feedback