Fehlerbehebung bei Problemen mit 5G SMI-Protokollen und VMs mit zeitlicher Synchronisierung

Einleitung

In diesem Dokument wird die Implementierung einer Problemumgehung für NTP-Zeitsynchronisierungsprobleme (Network Time Protocol) in virtuellen Systemen mit SMI-Protokoll (5G Subscriber Microservices Infrastructure) (Protokoll-VMs) beschrieben.

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in den folgenden Bereichen verfügen:

• Cisco SMI
• CNDP-Architektur (Cloud Native Deployment Platform) für 5G
• Cloud - Red Hat OpenStack Platform 13 ("Queens"-Version)
• Dockers und Kubernetes

Verwendete Komponenten

Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:

• SMI 2020.01.1-21
• Kubernetes v1.16.2
• Red Hat OpenStack Platform 13 Director

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.

Hintergrundinformationen

Was ist SMI?

Cisco SMI besteht aus mehreren Cloud-Technologien und -Standards, die auf Mikroservices basierende Anwendungen aus den Geschäftsbereichen Cisco Mobility, Cable und Broadband Network Gateway (BNG) ermöglichen. Diese Anwendungen verfügen über ähnliche Funktionen zur Abonnentenverwaltung und ähnliche Datenspeicheranforderungen.

Attribute:

• Der Layer Cloud Stack (Technologien und Standards) ermöglicht Top-to-Bottom-Bereitstellungen und unterstützt die aktuelle Cloud-Infrastruktur.
• Alle Anwendungen nutzen die Common Execution Environment (CEE) für Funktionen, die keine Anwendungen sind (Datenspeicherung, Bereitstellung, Konfiguration, Telemetrie, Alarmierung) und bieten somit eine konsistente Interaktion und Benutzererfahrung für alle Berührungspunkte und Integrationspunkte mit Kunden.
• Anwendungen und CEE werden in Microservice-Containern bereitgestellt und mit einem Intelligent Service Mesh verbunden.
• Automatisierung wird durch eine offene API für Bereitstellung, Konfiguration und Management ermöglicht.

Was ist CEE?

• Die CEE ist eine Softwarelösung, die entwickelt wurde, um mobile und Kabelanwendungen zu überwachen, die auf dem SMI bereitgestellt werden. Das CEE erfasst Informationen (Schlüsselmetriken) aus den Anwendungen auf zentralisierte Weise, sodass Techniker Fehler debuggen und beheben können.
• Die CEE ist die gemeinsame Reihe von Werkzeugen, die für alle Anwendungen installiert werden. Es verfügt über ein dediziertes Betriebszentrum, das die Befehlszeilenschnittstelle (Command Line Interface, CLI) und APIs zur Verwaltung der Überwachungstools bereitstellt. Pro Cluster ist nur ein CEE verfügbar.

Was sind Protokoll-VMs?

Protokoll-VMs hosten die Session Management Function (SMF)-Anwendungs-Microservices, die für die Protokollübersetzung verantwortlich sind. Pro SMF-Instanz werden zwei Protokoll-VMs bereitgestellt. Ein Protokoll-VM verfügt über PODs wie GTPc, Lawful Intercept (LI), Radius, Rest usw.

Problem

Von einem Knoten (Protokoll-VM) aus, der das Problem aufweist, können Sie sehen, dass das Netzwerk versucht, zwei verschiedene Schnittstellen zu verwenden, um die Verbindung zum NTP-Server weiterzuleiten. Allerdings kann nur eines der Netzwerke die IP-Adresse erreichen.

Wenn Sie einen Ping für eine Weile ohne die Schnittstelle ausführen, können Sie sehen, dass dies einen Paketverlust verursacht.

Beispielwarnung von 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...


Fehlerbehebung

1. Melden Sie sich bei den betroffenen VMs an, und führen Sie den folgenden Befehl aus: ip route | grep -i default

   In diesem Beispiel werden zwei Standardrouten angezeigt, die falsch sind. (Es sollte nur eine Standardroute geben.)

   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. Überprüfen Sie den Status des NTP-Dienstes (chronyd). Obwohl der Dienst aktiv ist, werden Fehler "Kann nicht synchronisiert werden" angezeigt.

   Beispiel für das Ergebnis:

   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. Überprüfen Sie den Status des Netzwerkkonfigurationsdiensts. (Sie ist inaktiv.)

   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)

Problemumgehung

Anmerkung: Dieses Verfahren verursacht keine Ausfallzeiten in der Anwendung.

1. Bearbeiten Sie das Skript (/etc/systemd/system/network-config.service) für den Netzwerkkonfigurationsdienst im betroffenen Knoten, um folgende Zeilen hinzuzufügen:

   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. Starten Sie den Netzwerkkonfigurationsdienst:

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

3. Laden Sie die Konfiguration mit systemctl neu:

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

4. Starten Sie den Chronyd-Dienst neu:

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

Verifizierung

Nachdem Sie die Schritte zur Problemumgehung abgeschlossen haben, führen Sie den folgenden Befehl aus, um zu überprüfen, ob die Probleme behoben sind:

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

Anmerkung: Ein 'Systemuhr synchronisiert' Wert von 'ja' zeigt an, dass die Probleme behoben sind.

Beispiel für das Ergebnis:

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