Contenu

Introduction

Conditions préalables

Conditions requises

Composants utilisés

Informations générales

Qu'est-ce que SMI ?

Qu'est-ce que le CEE ?

Qu'est-ce que les machines virtuelles de protocole ?

Problème

Dépannage

Solution de contournement

Vérification

Introduction

Ce document décrit comment mettre en oeuvre une solution de contournement pour les problèmes de synchronisation temporelle NTP (Network Time Protocol) dans les machines virtuelles de protocole SMI (Subscriber Microservices Infrastructure) 5G.

Conditions préalables

Conditions requises

Cisco vous recommande de connaître ces sujets :

- SMI Cisco

- Architecture CNDP (Cloud Native Deployment Platform) 5G

- Cloud - Red Hat OpenStack Platform 13 (version Queens)

- Dockers et Kubernetes

Composants utilisés

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

- SMI 2020.01.1-21

- Kubernetes v1.16.2

- Directeur Red Hat OpenStack Platform 13

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.

Informations générales

Qu'est-ce que SMI ?

Cisco SMI est une pile multicouche de technologies et de normes cloud qui permet d'utiliser des applications de microservices à partir des unités commerciales de Cisco Mobility, Cable, and Broadband Network Gateway (BNG). Ces applications ont des fonctions de gestion des abonnés similaires et des exigences similaires en matière de data store.

Attributs :

- La pile cloud de couche (technologies et normes) fournit des déploiements de haut en bas et s'adapte à l'infrastructure cloud actuelle.

- Toutes les applications partagent l'environnement CEE (Common Execution Environment) pour les fonctions non applicatives (stockage de données, déploiement, configuration, télémétrie, alarme), qui fournit une interaction et une expérience cohérentes pour tous les points de contact et d'intégration des clients.

- Les applications et le CEE sont déployés dans des conteneurs de microservices et sont connectés à un maillage de service intelligent.

- Une API exposée pour le déploiement, la configuration et la gestion permet l'automatisation.

Qu'est-ce que le CEE ?

- CEE est une solution logicielle développée pour surveiller les applications mobiles et câblées déployées sur le SMI. Le CEE capture les informations (mesures clés) des applications de manière centralisée pour permettre aux ingénieurs de déboguer et de dépanner.

- Le CEE est l'ensemble commun d'outils installés pour toutes les applications. Il est équipé d'un Ops Center dédié, qui fournit l'interface de ligne de commande (CLI) et les API pour gérer les outils de surveillance. Un seul CEE est disponible pour chaque grappe.

Qu'est-ce que les machines virtuelles de protocole ?

Les machines virtuelles de protocole hébergent les microservices d'application SMF (Session Management Function) responsables de la traduction de protocole. Deux machines virtuelles de protocole sont déployées par instance de SMF. Une machine virtuelle de protocole possède des pods tels que GTPc, LI (Lawful Intercept), Radius, Rest, etc.

Problème

À partir d'un noeud (machine virtuelle de protocole) qui présente le problème, vous pouvez voir que le réseau tente d'utiliser deux interfaces différentes pour router la connectivité au serveur NTP. Cependant, un seul des réseaux peut atteindre l’adresse IP.

Lorsque vous exécutez une requête ping sans l’interface pendant un certain temps, vous pouvez voir qu’elle entraîne la perte de paquets.

Exemple d'alerte de CEE :

[pod-name-cnat/global] cee# show alerts active summary

NAME UID SEVERITY STARTS AT SOURCE SUMMARY

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

VoNR_Ded_Bearer_Creat be183f61dd65 major 01-18T16:32:17 System Success percentage of VoNR - PCF Initiated Dedicated Bearer Creation procedure in NR turns less than t...

clock-is-not-in-synch 38a35e9a8bd8 major 01-18T13:11:15 pod-name-cnat-cnat-co Clock not in synch detected on hostname pod-name-cnat-cnat-core-protocol-data1 . Ensure NTP is configu...

clock-is-not-in-synch 4a7e138b8bae major 01-18T13:07:35 pod-name-cnat-cnat-co Clock not in synch detected on hostname pod-name-cnat-cnat-core-protocol-ims2 . Ensure NTP is configur...

clock-is-not-in-synch 5b3e128f0101 major 01-18T12:05:55 pod-name-cnat-cnat-co Clock not in synch detected on hostname pod-name-cnat-cnat-core-protocol-data2 . Ensure NTP is configu...

container-memory-usag f588aa627792 critical 12-28T15:47:30 path-provisioner-v6zx Pod cee-global/path-provisioner-v6zxj/k8s_path-provisioner_path-provisioner-v6zxj_cee-global_f1a1e8fa-...

container-memory-usag 55b2ea84466f critical 12-27T22:27:10 path-provisioner-v6zx Pod cee-global/path-provisioner-v6zxj/ uses high memory 82.69%.

N11_SM_Timeout_SR f6fb82cac197 major 10-31T15:51:16 System This alert is fired when the increase in timeout for N11 messages toward AMF crosses threshold

Radius_Server_RTT 94ac2cff43a3 warning 10-28T05:08:56 System RTT for Radius Server: 216.x.x.x, Port: 1813 in namespace: smf-mvno is more than 5 ms.

Radius_Server_RTT d02b60b3a3a4 warning 10-28T05:05:56 System RTT for Radius Server: 52.x.x.x, Port: 1813 in namespace: smf-mvno is more than 5 ms.

Radius_Server_RTT 9afcee101013 warning 10-28T05:05:36 System RTT for Radius Server: 52.x.x.x, Port: 1813 in namespace: smf-mvno is more than 5 ms.

N11_SM_Timeout_SR 206c4bbccf21 major 10-20T13:26:16 System This alert is fired when the increase in timeout for N11 messages toward AMF crosses threshold

N4_Total_Outbound_Int 4e0f3c1d6300 major 10-20T09:01:23 System This alert is fired when the percentage of N4 outbound responses sent is lesser than threshold %.

N4_Total_Outbound_Int 3e2fed624704 major 10-20T08:21:23 System This alert is fired when the percentage of N4 outbound responses sent is lesser than threshold %.

watchdog 97a7976a4103 minor 05-05T09:10:58 System This is an alert meant to ensure that the entire alerting pipeline is functional. This alert is always...

Dépannage

1. Connectez-vous aux machines virtuelles affectées et exécutez cette commande : ip route | grep -i default

Dans cet exemple, vous pouvez voir deux routes par défaut, ce qui est incorrect. (Il ne doit y avoir qu'une seule route par défaut.)

ubuntu@pod-name-cnat-cnat-core-protocol-ims2:~$ ip route | grep -i default

default via 172.16.x.x dev ens4 proto dhcp src 172.16.x.x metric 100

default via 172.16.x.x dev ens3 proto dhcp src 172.16.x.x metric 100

2. Vérifiez l'état du service chronyd (NTP). Même si le service est actif, les erreurs « Impossible de synchroniser » s'affichent.

Exemple de sortie :

root@pod-name-cnat-cnat-core-protocol-data1:/home/ubuntu# systemctl status chronyd.service

chrony.service - chrony, an NTP client/serverLoaded: loaded (/lib/systemd/system/chrony.service; enabled; vendor preset: enabled)

Active: active (running) since Fri 2021-01-08 07:19:19 UTC; 11 months 24 days ago

Docs: man:chronyd(8)

man:chronyc(1)

man:chrony.conf(5)

Main PID: 4300 (chronyd)

Tasks: 1 (limit: 4915)

CGroup: /system.slice/chrony.service

└─4300 /usr/sbin/chronyd

Dec 30 17:06:28 pod-name-cnat-cnat-core-protocol-data1 chronyd[4300]: Selected source 5.196.x.x

Dec 31 06:37:11 pod-name-cnat-cnat-core-protocol-data1 chronyd[4300]: Can't synchronise: no selectable sources

Dec 31 17:15:31 pod-name-cnat-cnat-core-protocol-data1 chronyd[4300]: Selected source 5.196.x.x

Jan 01 06:29:43 pod-name-cnat-cnat-core-protocol-data1 chronyd[4300]: Can't synchronise: no selectable sources

Jan 01 16:50:02 pod-name-cnat-cnat-core-protocol-data1 chronyd[4300]: Selected source 5.196.x.x

Jan 01 19:25:05 pod-name-cnat-cnat-core-protocol-data1 chronyd[4300]: Can't synchronise: no selectable sources

3. Vérifiez l'état du service de configuration réseau. (Il est inactif.)

ubuntu@pod-name-cnat-cnat-core-protocol-data1:~$ systemctl status network-config

network-config.service - Job that configures for routes

Loaded: loaded (/etc/systemd/system/network-config.service; enabled; vendor preset: enabled)

Active: inactive (dead) since Fri 2021-01-08 09:29:05 UTC; 1 years 0 months ago

Process: 1185 ExecStart=/etc/cisco/network-config.sh start (code=killed, signal=TERM)

Main PID: 1185 (code=killed, signal=TERM)

Solution de contournement

Note: Cette procédure n'entraîne aucune interruption dans l'application.

1. Modifier le script de service network-config (/etc/systemd/system/network-config.service) dans le noeud affecté pour ajouter ces lignes :

root@pod-name-cnat-cnat-core-protocol-data1:/home/ubuntu# vim /etc/systemd/system/network-config.service

Restart=always

RestartSec=10s

StartLimitIntervalSec=300s

StartLimitBurst=30

2. Démarrez le service network-config :

root@pod-name-cnat-cnat-core-protocol-data1:/home/ubuntu# systemctl start network-config

3. Rechargez la configuration avec systemctl :

root@pod-name-cnat-cnat-core-protocol-data1:/home/ubuntu# systemctl daemon-reload

4. Redémarrez le service de synchronisation :

root@pod-name-cnat-cnat-core-protocol-data1:/home/ubuntu# systemctl restart chronyd.service

Vérification

Une fois les étapes de contournement terminées, exécutez cette commande pour vérifier que les problèmes sont résolus :

for server in $(awk '/protocol/{print $1}' /etc/hosts); do ssh $server "hostname && timedatectl status && chronyc sources -vn" ; done

Note: La valeur 'yes' de l'horloge système indique que les problèmes sont corrigés.

Exemple de sortie :

ubuntu@pod-name-cnat-cnat-core-master1:~$ for server in $(awk '/protocol/{print $1}' /etc/hosts); do ssh $server "hostname && timedatectl status && chronyc sources -vn" ; done

pod-name-cnat-cnat-core-protocol-data1

Local time: Tue 2021-09-07 10:22:16 UTC

Universal time: Tue 2021-09-07 10:22:16 UTC

RTC time: Tue 2021-09-07 10:22:17

Time zone: Etc/UTC (UTC, +0000)

System clock synchronized: yes

systemd-timesyncd.service active: no

RTC in local TZ: no

210 Number of sources = 1

MS Name/IP address         Stratum Poll Reach LastRx Last sample

===============================================================================

^* svtsnq01.mgmt                 1   6   170   282  -1100us[-1858us] +/-   47ms

pod-name-cnat-cnat-core-protocol-data2

Local time: Tue 2021-09-07 10:22:16 UTC

Universal time: Tue 2021-09-07 10:22:16 UTC

RTC time: Tue 2021-09-07 10:22:17

Time zone: Etc/UTC (UTC, +0000)

System clock synchronized: yes

systemd-timesyncd.service active: no

RTC in local TZ: no

210 Number of sources = 1

MS Name/IP address         Stratum Poll Reach LastRx Last sample

===============================================================================

^* svtsnq01.mgmt                 1   6    74   206   -218us[-1550us] +/-   46ms

pod-name-cnat-cnat-core-protocol-ims1

Local time: Tue 2021-09-07 10:22:17 UTC

Universal time: Tue 2021-09-07 10:22:17 UTC

RTC time: Tue 2021-09-07 10:22:18

Time zone: Etc/UTC (UTC, +0000)

System clock synchronized: yes

systemd-timesyncd.service active: no

RTC in local TZ: no

210 Number of sources = 1

MS Name/IP address         Stratum Poll Reach LastRx Last sample

===============================================================================

^* svtsnq01.mgmt                 1   6    77    24   +796us[+1044us] +/-   47ms

pod-name-cnat-cnat-core-protocol-ims2

Local time: Tue 2021-09-07 10:22:17 UTC

Universal time: Tue 2021-09-07 10:22:17 UTC

RTC time: Tue 2021-09-07 10:22:18

Time zone: Etc/UTC (UTC, +0000)

System clock synchronized: yes

systemd-timesyncd.service active: no

RTC in local TZ: no

210 Number of sources = 1

MS Name/IP address         Stratum Poll Reach LastRx Last sample

===============================================================================

^* svtsnq01.mgmt                 1   6    17    98  +2176us[+2275us] +/-   47ms