Dépannage du protocole UPF de secours qui n'obtient pas le message de configuration NSO

Options de téléchargement

PDF (249.4 KB)
Consulter à l'aide d'Adobe Reader sur un grand nombre d'appareils
ePub (85.7 KB)
Consulter à l’aide de différentes applications sur iPhone, iPad, Android ou Windows Phone
Mobi (Kindle) (72.3 KB)
Consulter sur un appareil Kindle ou à l’aide d’une application Kindle sur plusieurs appareils

Mis à jour:12 février 2024

ID du document:221677

Langage exempt de préjugés

Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.

À propos de cette traduction

Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.

Table des matières

Introduction

Problème

Solution

Introduction

Ce document décrit UPF basé sur RCM incapable d'obtenir la configuration push(host/ecs/apn) en raison d'un problème dans le côté NSO

Problème

Une fois que RCM (Redundancy Configuration Manager) a initié le redémarrage d'UPF (User Plane Function), une fois que RCM reçoit configpushcomplete d'UPF, RCM envoie un message de notification à NSO (Network Services Orchestrator), pour passer à l'étape suivante : envoyer les fichiers de configuration host, ecs et apn dans cet ordre.

Mais dans NSO, le problème est identifié lorsque l'horodatage de la notification envoyée par le RCM est analysé.

# NSO ne procède pas à la configuration push vers UPF lorsque l'horodatage de la notification est au format (champ d'observation en microsecondes NON présent)

netconf-notifications received-notifications notification 2024-01-25T04:59:30+00:00 0

//Sample notification - does not work on NSO

netconf-notifications received-notifications notification 2024-01-25T04:59:30+00:00 0

user          <NSO username>

subscription  alert-notification

stream        alert-notification

received-time 2024-01-25T04:59:30.042866+00:00

data smi-alert-notification starts-at ""

data smi-alert-notification ends-at ""

data smi-alert-notification alert-status Config-Push

NAME           VALUE          

-------------------------------

DeviceID                      

Event          Config-Push    

GroupID        2              

ManagementIP   <IPv4 address>  

NameSpace      <rcm-namespace>   

RCMVIP         <IPv4 address> 

RecoveryState                 

SSHIP          <IPv4 address>  

UPFState       STANDBY

# NSO continue pour configpush lorsque l'horodatage de la notification est au format (le champ Observer microseconde est présent)

netconf-notifications received-notifications 2024-01-25T04:43:30.045+00:00 0

//Sample notification - working on NSO

netconf-notifications received-notifications notification 2024-01-25T04:43:30.045+00:00 0

user          <NSO username>

subscription  alert-notification

stream        alert-notification

received-time 2024-01-25T04:43:30.087872+00:00

data smi-alert-notification starts-at ""

data smi-alert-notification ends-at ""

data smi-alert-notification alert-status Config-Push

NAME           VALUE          

-------------------------------

DeviceID                      

Event          Config-Push    

GroupID        2              

ManagementIP  <IPv4 address>  

NameSpace      <rcm-namespace>   

RCMVIP        <IPv4 address>

RecoveryState                 

SSHIP          <IPv4 address>  

UPFState       STANDBY

Remarque : les messages de notification NSO peuvent être demandés à partir de l'environnement de production à partir des journaux NSO.

Solution

Actuellement, le RCM dispose d'un délai d'attente de 100 minutes après lequel il redémarre l'UPF bloqué, en attendant le push de configuration de NSO.

Correction côté NSO via l'ID de bogue Cisco CSCwi70899