Fehlerbehebung bei X3MDConnDown- und X3MDConnUp-Trap im PGW

Einleitung

In diesem Dokument wird der Prozess zur Ursachenidentifizierung für die Traps X3MDConnDown und X3MDConnUp im Cisco Packet Data Network Gateway (PGW) nach dem Upgrade von 21.18.17 auf 21.25.8 in großer Zahl beschrieben.

Voraussetzungen

Anforderungen

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

• StarOS/PGW
• Kenntnisse der X1-, X2- und X3-Schnittstellen und -Funktionen
• Kenntnis der TCP-Einrichtung für X3

Verwendete Komponenten

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

• PGW Aggregation Services Router (ASR) 5500
• Versionen 21.18.17.79434 und 21.25.884257

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

Die Lawful Interception-Lösung verfügt über drei separate Schnittstellen zwischen Netzwerkelement und Vermittlungsserver, um Informationen zu Bereitstellung, Anrufdaten (Signal) und Anrufinhalten (Medien) bereitzustellen. Diese Schnittstellen werden nach dem Aufbau der Verbindung zwischen der XCIPIO Vermittlungsserver Delivery Function (DF) und dem Netzwerkelement Access Function (AF) erstellt. Die Schnittstelle vom Vermittlungsserver zur gesetzlichen Abhörstelle ist standardisiert. Die Schnittstellen zwischen AF und DF sind wie folgt definiert:

• X1- oder INI-1-Schnittstelle für Bereitstellungsziele
• X2- oder INI-2-Schnittstelle zur Bereitstellung von Signalisierungsinformationen für das Ziel
• X3- oder INI-3-Schnittstelle zur Bereitstellung von Medien- oder Anrufinhalten für das Ziel

Dabei ist die X-Schnittstelle durch den 3GPP-Standard definiert, während INI durch den ETSi-Standard definiert ist.

Problem

Nach dem Knoten-Upgrade von 21.18.17 auf 21.25.8 wurde ein Alarm für X3MDConnDown und X3MDConnUp in Bulk (etwa 3000 in einer Stunde) gestartet.

Trap-Format:

Mon Jul 04 00:44:15 2022 Internal trap notification 1422 (X3MDConnDown) TCP connection is down. Context Id:8, Local IP/port:10.10.10.1/41833 and Peer IP/port: x.x.x.x/7027 with cause: LI X3 CALEA Connection Down

Mon Jul 04 00:45:29 2022 Internal trap notification 1423 (X3MDConnUp) TCP connection is up. Context Id:8, Local IP/port:10.10.10.1/56805 and Peer IP/port: x.x.x.x/7027 with cause: LI X3 CALEA Connection UP

Trap-Details in HRS:

Das Problem ist in diesem Bild rot hervorgehoben:

Schritte zur Fehlerbehebung:

1. Überprüfen Sie die Dienste zum LI-Server, Sie werden keine Auswirkungen finden.
2. LI-Dateien können auf den LI-Server übertragen werden.
3. Ping und Traceroute wurden für den LI-Server einwandfrei befunden.
4. Es wurden keine Latenz und kein Paketverlust beobachtet.
5. Wenn Sie versuchen, den TCP-Dump in Richtung des LI-Servers zu erfassen, werden unidirektionale Pakete in TCPdump für den problematischen Knoten erfasst.

Vergleichen Sie es mit dem Arbeitsknoten, und Sie sehen dasselbe Verhalten.

1. Wenn Sie einen anderen Port am LI-Server anlegen, stellen Sie fest, dass das Problem weiterhin besteht.
2. Wenn Sie einen weiteren LI-Test-Server und -Port erstellen, beobachten Sie denselben Alarm am Gateway GPRS Support Node (GGSN).
3. Wenn Sie die zusätzlichen Traces erfassen, z. B. die NPU-PAN-Ablaufverfolgung, show-Befehle und Debug-Protokolle, sehen Sie, dass FIN ACK vom LI-Server direkt nach der SYN vom PGW stammt, und dies führt zu Traps  X3MDConnDown undX3MDConnUp.
4. Laut Engineering-Team erkennt die Version 21.25.8 die FIN ACK und löst den Alarm aus X3MDConnDown und dann X3MDConnUp. Diese Funktionalität wird in früheren Versionen als 21.18.17.
5. Ein Workaround-Heartbeat-Timer (1 m) wurde auf dem GGSN- und LI-Server aktiviert. posten, X3MDConnDown und X3MDConnUp Alarm hat die Kontrolle. Es wird von etwa 3000 auf 100 für 1 Tag reduziert.
6. Der Knoten wird 2 Wochen lang überwacht, und die X3MDConnDown und X3MDConnUp-Alarme gesteuert.

Verwendete Befehle

1. Von diesen Befehlen werden LI-Dateien korrekt auf den LI-Server übertragen. Es besteht kein Problem mit der TCP-Verbindung zum LI-Server.

show lawful-intercept full imsi <>

Beispiele:

[lictx]GGSN# show lawful-intercept full msisdn XXXXXXXXX

Monday April 25 14:15:11 IST 2022

Username : -

ip-address : XXXXXXXX

msid/imsi : XXXXXXXXXXX

msisdn : XXXXXXXX

imei/mei : XXXXXXX

session : Session Present

service-type : pgw

pdhir : Disabled

li-context : lictx

intercept-id : 58707

intercept-key: -

Content-delivery: tcp-format

TCP connection info

State : ACTIVE

Dest. address: XX.XX.XX.XX Dest. Port: XXXX————>>

Num. Intercepted pkt for Active call: XXXX ——————>>

Event-delivery: tcp-format——>>

TCP connection info —————>>

State : ACTIVE————>>

Dest. address: XX.XX.XX.XX Dest. Port: XXXX————>>

Num. Intercepted pkt for Active call: 13 —————>>>

Provisioning method: Camp-on trigger

LI-index : 649

Für diese Befehle ist LI-Administratorzugriff erforderlich, um vollständige Ausgaben anzuzeigen:

show lawful-intercept statistics

show lawful-intercept buffering-stats sessmgr all

show lawful-intercept statistics

show connection-proxy sockets all

show lawful-intercept error-stats

2. Sammeln Sie die folgenden Debug-Level-Protokolle:

logging filter active facility dhost level debug

logging filter active facility li level debug

logging filter active facility connproxy level debug

logging filter active facility ipsec level debug

logging filter active facility ipsecdemux level debug

logging active pdu-verbosity 5

Logging active

No logging active

Hier können Sie sehen, dass sich die Port-Informationen ändern, wenn sie nicht stabil sind.

show dhost socket  (in li context)

3. Wechseln Sie in den Ausgeblendeten Modus, und gehen Sie zur VPP-Aufgabe (Vector Packet Processing), um zu überprüfen, ob Pakete für die FIN-Bestätigung (ACK) eingehen.

[lictx]GGSN# debug shell

enter vppct (from deb shell, use cmd "vppctl")
vpp#show hsi sessions

Beispiele:

[local]g002-laas-ssi-24# deb sh

Friday May 13 06:03:24 UTC 2022

Last login: Fri May 13 04:32:03 +0000 2022 on pts/2 from 10.78.41.163.

g002-laas-ssi-24:ssi# vppctl

vpp# sho hsi sessions

[s1] dep 1 thread 10 fib-index 6 dst-src [3.2.1.1:9002]-[3.1.1.1:42906]

[s2] dep 1 thread 9 fib-index 6 dst-src [3.2.1.1:9003]-[3.1.1.1:60058]

[s3] dep 1 thread 8 fib-index 6 dst-src [3.2.1.1:9004]-[3.1.1.1:51097]

[s4] dep 1 thread 6 fib-index 6 dst-src [3.2.1.1:9005]-[3.1.1.1:45619]

4. Ausgabe-Logs im LI-Kontext anzeigen kann unter Testbefehl aktiviert werden, nachdem Sie Debug-Logs aktiviert haben.

show clock
show dhost sockets
show connection-proxy sockets all
show clock

5. Sammeln Sie die Supportdetails anzeigen.

6. Sammeln Sie die NPU-PAN-Spur, um zu erkennen, dass das Paketerfolgreiche TCP-Verbindung mit dem LI-Server.

So deaktivieren Sie:

#configure

#no npumgr pan-trace

#npumgr pan-trace monitor none

#end

#show npumgr pan-trace configuration

#configure

#npumgr pan-trace acc monitor ipv4 id 1 protocol tcp sa X.X.X.X mask 255.255.255.255 da X.X.X.X mask 255.255.255.255

#npumgr pan-trace acc monitor ipv4 id 2 protocol tcp sa X.X.X.X mask 255.255.255.255 da X.X.X.X mask 255.255.255.255

#npumgr pan-trace limit 4096

#npumgr pan-trace

#end

(check if disabled/enabled, it should be enabled)

#show npumgr pan-trace configuration 

Mit diesem Befehl kann die NPU-Pan-Verfolgung gestoppt werden. Er muss daher für die nächste Sammlung neu konfiguriert werden.

#show npumgr pan-trace summary

(We can capture packets based on npu number which can be done during testing if possible)
#show npumgr pan-trace detail all

Beispiel für NPU-Trace:

3538  6/0/2 Non 6/15 fab    70 Jun 02 16:47:10.05443343 144 Eth() Vlan(2014) IPv4(sa=XX.XX.XX.147, da=XX.XX.XX.201) TCP(sp=7027, dp=46229, ACK FIN) [ vrf=8 strip=40 flow ] >> MEH(sbia=050717de, dbia=0603800e, flowid=62755625, In) IPv4(sa=XX.XX.XX.147, da=XX.XX.XX.201) TCP(sp=7027, dp=46229, ACK FIN)
Packet details :

Packet 3538:

                              SA              [4B] = XX.XX.XX.147[0x0aa40693]

                              DA              [4B] = XX.XX.XX.201[0x0aa91ec9]

                              source port     [2B] = 0x1b73 (7027),   dest port       [2B] = 0xb495 (46229)

                              seqnum          [4B] = 0xc9923207 (3381801479)

                              acknum          [4B] = 0xbbd482ef (3151266543)

                              flags           [6b] = 0x11 ACK FIN

Lösung

Aktivieren Sie mit dem folgenden Befehl das Timeout für Heartbeat-Nachrichten auf 1 Minute auf dem PGW und auf XX.XX.XX.147 (LI-Server):

lawful-intercept tcp application-heartbeat-messages timeout minutes 1

Angenommen, FIN ACK kommt direkt nach der SYN vom LI-Server. In diesem Fall geht das PGW nicht davon aus, dass eine X3-Schnittstelle ausgefallen ist, da der Heartbeat im PGW 1 Minute aktiviert und auch auf dem LI-Server aktiviert ist. Dies ist ein Hinweis darauf, dass die X3-Verbindung aktiv ist, da der Heartbeat vorhanden ist. Daher werden die Alarme für X3MDConnDown und X3MDConnUp reduziert.

SSD-Trap-Analyse vor und nach der Bereitstellung:

Trends bei SNMP-Traps Workaround:

Mon Jul 04 00:44:15 2022 Internal trap notification 1422 (X3MDConnDown) TCP connection is down. Context Id:8, Local IP/port:10.10.10.1/41833 and Peer IP/port: 10.10.10.6/7027with cause: LI X3 CALEA Connection Down


  Mon Jul 04 11:13:20 2022 Internal trap notification 1422 (X3MDConnDown) TCP connection is down. Context Id:8, Local IP/port:10.10.10.1/47122 and Peer IP/port: 10.10.10.6/7027with cause: LI X3 CALEA Connection Down

==========


  Tue Jul 05 09:45:11 2022 Internal trap notification 1422 (X3MDConnDown) TCP connection is down. Context Id:8, Local IP/port:10.10.10.1/34489 and Peer IP/port: 10.10.10.6/7027 with cause: LI X3 CALEA Connection Down


  Tue Jul 05 09:45:56 2022 Internal trap notification 1423 (X3MDConnUp) TCP connection is up. Context Id:8, Local IP/port:10.10.10.1/51768 and Peer IP/port: 10.10.10.6/7027 with cause: LI X3 CALEA Connection UP


  Tue Jul 05 09:57:57 2022 Internal trap notification 1423 (X3MDConnUp) TCP connection is up. Context Id:8, Local IP/port:10.10.10.1/34927 and Peer IP/port: 10.10.10.6/7027 with cause: LI X3 CALEA Connection UP


  Tue Jul 05 17:10:30 2022 Internal trap notification 1423 (X3MDConnUp) TCP connection is up. Context Id:8, Local IP/port:10.10.10.1/59164 and Peer IP/port: 10.10.10.6/7027 with cause: LI X3 CALEA Connection UP


  Tue Jul 05 17:11:00 2022 Internal trap notification 1423 (X3MDConnUp) TCP connection is up. Context Id:8, Local IP/port:10.10.10.1/52191 and Peer IP/port: 10.10.10.6/7027 with cause: LI X3 CALEA Connection UP


  Tue Jul 05 17:11:07 2022 Internal trap notification 1423 (X3MDConnUp) TCP connection is up. Context Id:8, Local IP/port:10.10.10.1/46619 and Peer IP/port: 10.10.10.6/7027 with cause: LI X3 CALEA Connection UP


  Tue Jul 05 17:14:23 2022 Internal trap notification 1423 (X3MDConnUp) TCP connection is up. Context Id:8, Local IP/port:10.10.10.1/59383 and Peer IP/port: 10.10.10.6/7027 with cause: LI X3 CALEA Connection UP


  Tue Jul 05 17:17:31 2022 Internal trap notification 1423 (X3MDConnUp) TCP connection is up. Context Id:8, Local IP/port:10.10.10.1/59104 and Peer IP/port: 10.10.10.6/7027 with cause: LI X3 CALEA Connection UP

Hier ist der Status der Traps, die zuletzt beobachtet wurden, und beachten Sie, dass keine neuen Traps generiert werden.

[local]GGSN# show snmp trap statistics verbose | grep X3MDConn

Thursday July 21 12:36:38 IST 2022

X3MDConnDown                        12018928     0 9689294  2022:07:05:11:36:23

X3MDConnUp                          12030872     0 9691992  2022:07:05:17:17:31

[local]GGSN# show snmp trap history verbose | grep x.x.x.x 

Thursday July 21 12:36:57 IST 2022