Fehlerbehebung bei DNS-Timeout-Problemen in MME

Einleitung

In diesem Dokument werden die Probleme im Zusammenhang mit dem DNS-Timeout (Domain Name System) für die Abfragen von DNS in Mobile Management Entity (MME) für die Auswahl von Serving GateWay (SGW) und Packet Data Network Gateway (PGW) beschrieben.

Voraussetzungen

Anforderungen

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

• StarOS
• MME-Funktionalität für DNS

Verwendete Komponenten

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

• DNS
• MME

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 potenziellen Auswirkungen eines Befehls verstehen.

Hintergrundinformationen

DNS

DNS wandelt Domänennamen in IP-Adressen um, die Browser zum Laden von ABCD-Seiten verwenden. Jedes mit den Netzwerken verbundene Gerät hat eine eigene IP-Adresse, die von anderen Geräten zum Auffinden des Geräts verwendet wird.

Aus der Perspektive der Mobilität betrachtet ist DNS der externe Server, der für den Access Point Name (APN) und die URL-Auflösung verwendet wird, basierend auf seiner Verbindung mit den Knoten im Netzwerk.

1. MME-zu-DNS-Konnektivität: Wird für APN-Auflösung für SPGW-Auswahl verwendet

2. Verbindung zwischen SPGW und DNS: Wird für die URL-Auflösung verwendet, um Internet Service Provider (ISP) zu erreichen.

In DNS verwendete Datensatztypen.

1. A/AAA-Eintrag: Wird zum Definieren der IPv4- und IPv6-Hostadresse verwendet, die dem vollständig qualifizierten Namen des Hosts zugeordnet ist, auf dem A-Datensatz für IPv4 und für IPv6 verwendet wird.

2. NAPTR-Datensatz: Wird als Suchdienst verwendet, der auf einen Servicedatensatz (SRV) und A/AAA-Datensätze für den SPGW-Auswahlprozess für die 4G-APN- und TAC-Auflösung verweist.

3. SRV-Datensatz: Wird als Suche verwendet, um zwischen einem NAPTR-Datensatz (Name Authority Pointer) und einem A/AAA-Datensatz zuzuordnen.

Beispiel: Erfahren Sie, wie der A/SRV/NAPTR zugeordnet wird.

MME-Funktionalität in Bezug auf DNS

• Die grundlegende MME-Funktion für DNS dient der SGW- und PGW-Auswahl auf Basis von DNS-Abfragen.
• Cisco MME verfügt über einen eigenen DNS-Cache, der häufige Abfragen an externe Server vermeidet und alle im MME DNS-Cache ausgeführten Abfragen speichert, um das Senden der Abfrage an einen externen DNS-Server zu reduzieren.
• Wenn sich die UE bei einem EPS-Netzwerk (Evolved Packet System) registriert, müssen ihr die entsprechenden SGWs und PGWs zugewiesen werden. Die MME wählt die GW basierend auf DNS aus.
• Die NAPTR-Abfrage wird verwendet, um die GW-Adressauflösung zu erstellen.
• Basierend auf der DNS-Abfrage bestimmt MME die Schnittstelle zwischen S-GW und P-GW.

Das Verfahren für die SPGW-Auswahl 

• MME führt eine erste DNS-Abfrage durch, um eine Liste mit GW-Identitäten und -Prioritäten abzurufen.
• S-GW-Auswahl basierend auf Tracking Area Identifier (TAI) durchgeführt
• P-GW-Auswahl basierend auf APN erfolgt
• MME wählt das GW anhand von Prioritätsinformationen oder MME-Konfiguration aus.
• Anschließend wird eine zweite DNS-Abfrage durchgeführt, um die IP-Adressen des gewünschten GW abzurufen.

Entsprechend der Vorgehensweise macht MME immer 2 DNS-Abfragen, um GW IP adressiert zu bekommen, was erklärt wird.

Abfrage 1: Bei der ersten Abfrage, die über APN oder TAI durchgeführt wird, wird ein SRV-Profil zugeordnet oder eine Datensatz-Ausgabe als Antwort zugeordnet.

Abfrage 2: Darüber hinaus wird eine Abfrage an das SRV-Profil gesendet und als Ersatzzeichenfolge zum Abrufen der GW-IP gesendet.

Beispiele:

Query Name: abcd.apn.epc.mncXXX.mccYYY.3gppnetwork.org
Query Type: NAPTR      TTL: 515 seconds
Answer:
Order: 100            Preference: 50000
Flags: a             Service: x-3gpp-pgw:x-s5-gtp:x-s8-gtp:x-gn:x-gp
Regular Expression:
Replacement: _nodes._pgw.epc.mncXXX.mccYYY.3gppnetwork.org

Query Name: _nodes._pgw.epc.mncXXX.mccYYY.3gppnetwork.org
Query Type: NAPTR      TTL: 515 seconds
Answer:
Order: 100            Preference: 50000
Flags: a            Service: x-3gpp-pgw:x-s5-gtp:x-s8-gtp:x-gn:x-gp

Regular Expression: topoff.pgw- s5s8.node.epc.mncXXX.mccYYY.3gppnetwork.org

Query Name: topoff.pgw- s5s8.node.epc.mncXXX.mccYYY.3gppnetwork.org
Query Type: A      TTL: 646 seconds
Answer:
IP Address: X.X.X.X

Problem

1. Wenn Sie eine NAPTR-Abfrage von MME für APN abcd.apn.epc.mncXXX.mccYY.3gppnetwork.org durchführen und ein DNS-Timeout bei MME erhalten.

Anmerkung: String +nc-nr ist die neue Zeichenfolge, die dem 5G-Dienst hinzugefügt und für jeden NAPTR-Ressourcendatensatz (RR) hinzugefügt wurde, um die Dienstschnittstelle zu identifizieren.

"x-3gpp-pgw:x-s5-gtp+nc-nr:x-s8-gtp:x-gn:x-gp"

Anmerkung: +nc-nr ist die neue Zeichenfolge, die auf dem 5G-Dienst basiert. MME muss diesen Dienst also unterstützen, damit er funktioniert, da MME eine DNS-Abfrage ausführt und eine Antwort abruft, um zu überprüfen, ob ein bestimmter Dienst in MME aktiviert ist oder nicht.

[gn]SGSN-MME# dns-client query client-name dnsclient query-type NAPTR query-name abcd.apn.epc.mncXXX.mccYYY.3gppnetwork.org
Wednesday October 27 17:06:20 ICT 2021
Query Name: abcd.apn.epc.mncXXX.mccYYY.3gppnetwork.org
Query Type: NAPTR      TTL: 0 seconds
Answer: -Negative Reply-
Failure Reason: DNS query timed out

2. In PCAP-Traces wurde festgestellt, dass der DNS-Server die Abfrage empfängt und als Antwort 30 bis 35 Ersetzungen pro APN sendet, da die Paketgröße 4186 Byte beträgt und MME eine TCP-Verbindung initiiert.

3. Sie können sehen, dass DNS-empfangene Abfrage-Anfrage und senden Sie die Antwort, aber ohne Inhalt mit nur einem Flag als "Nachricht ist abgeschnitten". Dies wird nur beobachtet, wenn die Antwortnachricht abgeschnitten wird und die übrigen 4G-Antworten einwandfrei funktionieren, wenn die Nachricht nicht abgeschnitten wird.

Der Grund für die abgeschnittene Nachricht liegt darin, dass eine Reihe von dem APN zugeordneten Ersetzungen über 30 liegen und die Nachrichtengröße erhöht und das als Antwort abgeschnittene Nachrichtenflag gesendet wird. Die Gesamtgröße der Antwortnachricht beträgt 4181 Byte als TCP-Nutzlast (siehe Bild).

Sobald MME diese Antwort erhält, initiiert MME die TCP-Verbindung mit DNS.

 Von MME zu DNS

• Frame 31 - MME sendet eine Abfrage an DNS
• Frame 32 - DNS sendet eine Antwort, wenn das Flag als "Message is truncated" (Nachricht ist abgeschnitten) gesetzt ist.
• Frame 33/34/35 - Es wurde eine TCP-Verbindung zwischen MME und DNS hergestellt, die den Austausch eigener Funktionen ermöglicht.

Im gegebenen Snapshot sehen Sie die maximale Segmentgröße (MSS), die von MME gesendet wird, ist 9060.

Wenn MME eine Abfrage ausführt, für die DNS eine Antwort mit "Nachricht ist abgeschnitten" sendet und keine weiteren Informationen enthält, nach denen die MME basierend auf der DNS-Antwort eine TCP-Verbindung initiiert.

Von DNS zu MME

• MME sendet eine Abfrage nach der TCP-Verbindung
•  DNS bestätigt dies.
•  DNS sendet eine Antwort mit dem Flag set "Message is not truncated" (Nachricht ist nicht abgeschnitten), da die mit DNS gemeinsam genutzte MSS auf 9060 Byte festgelegt ist und die gesamte Antwort auf einmal sendet.
•  MME reagiert mit einem ACK ohne Inhalt
•  DNS sendet das ACK an den Inhalt in Nachricht 38, wobei die Nutzlast 4181 Byte beträgt.
• MME sendet TCP, um die Verbindungen zurückzusetzen und zu schließen, sobald sie das letzte Fragment empfangen.

Wenn MME die gesamte Payload in 2 bis 3 Segmenten oder in einem Versuch von DNS empfängt, sendet MME eine TCP-Reset-Nachricht.

DNS commands to troubleshoot

show dns-client statistics
show dns-client statistics client <DNS Client Name>
show dns-client cache client <client name> [query-name <query-name>[query-type <NAPTR | AAAA | A>] | [query-type <NAPTR | AAAA | A>]]
dns-client query client-name <client name> query-type <NAPTR | AAAA> [query-name <query name>].show port datalink counters

Commands to check if there were any problem internal to the starOS system where request is not able to reach from demux vpnmgr to DNS app in sessmgrs

show port npu counters
show cloud configuration
show iftask stats summary
show npu utilization table
show iftask port-stats card <card>   ---- for all active SF cards
show iftask iomux-stats card <card>  ---- for all active SF cards

MON SUB to be captured with options enabled (verbosity 5,Y,S,34,35,19,A,26)

PCAP traces to be captured

DNS cache flush commands

clear dns-client <client-name> cache

Testszenario

1. Erfassen Sie alle erforderlichen Debug-Protokolle/Ablaufverfolgungen mit dedizierten Tests, und aktivieren Sie die Protokolle gleichzeitig, wenn der Teilnehmer mit problematischem APN durchsucht. 

2. Stellen Sie sicher, dass der Abonnent jedes Mal, wenn ein Testszenario durchgeführt wird, eine neue Verbindung zum Abonnenten herstellen muss.

3. Zu Testzwecken muss ein Tester zugewiesen werden, und der Tester muss einen dedizierten Test mit seinem IMSI durchführen und auf diesen problematischen APN zugreifen: abcd.apn.epc.mncXXX.mccYY.3gppnetwork.org.

  logging filter active facility vpn level debug         ------ debug level logs
  logging filter active facility tcpdemux level debug    ------ debug level logs
  logging monitor msid <MSID number>                     ------ (these logging command to be executed in config mode)

Fehlerbehebung

1. Überprüfen Sie die Ausgaben aller erwähnten Befehle, um sicherzustellen, dass ein Paketverlust im System auftritt.

2. Überprüfen Sie die Statistiken, um die Häufigkeit von DNS-Timeouts im Knoten zu bestätigen.

[gn]SGSN-MME# show dns-client statistics client dnsclient
Friday August 20 13:31:48 ICT 2021
DNS Usage Statistics:
---------------------
Query Type             Attempts       Successes        Failures
A                    2430996860      2410410937        20546467
SRV                  1325520986      1325516557            4429
AAAA                 3939810089               0      3939810089
NAPTR                 480586697       432853033        47732791
PTR                           0               0               0
Total                3881947336      4168780527      4008093776

…
Total Resolver Queries: 4480708
Successful Queries:     670040
Query Timeouts:         409717  
Domain Not Found:       2455918
Connection Refused:     0
Other Failures:         580612

Nachdem Sie diese Befehle ausgeführt haben, um die Statistiken für mehrere Iterationen zu erfassen und zu beobachten, dass Abfragetimeouts schrittweise erhöht werden, aber es keine Paketverluste zwischen Demux und Sessmgrs gab, sodass kein Problem mit dem internen System auftritt

Um Probleme mit externen Verbindungen oder Konfigurationsproblemen im DNS zu prüfen, führen Sie die Abfrage für die Austauschwerte direkt von MME statt APN aus, wie im Bild gezeigt. Dort wird sie ohne Verzögerung ordnungsgemäß behoben und kommt zu dem Schluss, dass auch bei externen Verbindungen und Konfigurationen keine Probleme auftreten.

[gn]SGSN-MME# dns-client query client-name dnsclient query-name TOPON.test.NODE.EPC.MNCXXX.MCCYYY.3GPPNETWORK.ORG
Monday August 02 18:51:29 ICT 2021
Query Name: TOPON.test.NODE.EPC.MNCXXX.MCCYYY.3GPPNETWORK.ORG
Query Type: A          TTL: 1038 seconds
Answer:
IP Address: X.X.X.X ------ resolve properly and gave IP

Das Problem besteht zwischen DNS und SGSN-MME, wo Sie DNS-Sendeantworten mit Ersatzwerten als Topon sehen können, und MME muss erneut nach Topon-Einträgen suchen, was aber sonst nicht passiert ist, wenn wir manuell die Auflösung der Abfrage erfolgreich durchführen

Laut Befehlsausgaben und Ablaufverfolgungen war klar, dass Sie bei der Abfrage von APN Antworten mit 30 Ersetzungen über TCP-Verbindung in Fragmenten erhalten, und während MME diese Fragmente bestätigt, sendet es Zurücksetzen an DNS.

Da MME TCP zum Zurücksetzen sendet, können wir in MME beobachten, dass die DNS-Abfrage einen Fehler als Abfragezeitüberschreitung anzeigt. Bis zu diesem Zeitpunkt werden diese 30 Ersetzungswerte in den MME-Befehlsausgaben nicht angezeigt, da Fragmente nicht vollständig bestätigt wurden, und vor Abschluss dieses Prozesses sendet MME TCP zum Zurücksetzen.

Debug logs analysis

For abcd.apn.epc.mncXXX.mccYYY.3gppnetwork.org

2021-Oct-27+17:06:20.910 [vpn 5456 info] [9/0/11730 <vpnmgr:6> vpnmgr_func.c:8011] [software internal system syslog] query:14585, UDP, Sent time 1635329180, Timeout set 1635329183  ---- timer is set here
2021-Oct-27+17:06:20.910 [vpn 5919 info] [9/0/11730 <vpnmgr:6> dns_resolver.c:323] [software internal system syslog] Sent out a DNS Query abcd.apn.epc.mncXXX.mccYYY.3gppnetwork.org to DNS Server   --------- DNS query is send for the first time
2021-Oct-27+17:06:20.911 [vpn 5456 info] [9/0/11730 <vpnmgr:6> vpnmgr_func.c:8011] [software internal system syslog] TCP Connection Init, While Sending Query
2021-Oct-27+17:06:20.911 [vpn 5456 info] [9/0/11730 <vpnmgr:6> vpnmgr_func.c:8011] [software internal system syslog] TCP Connection Open with DHost
2021-Oct-27+17:06:20.911 [vpn 5456 info] [9/0/11730 <vpnmgr:6> vpnmgr_func.c:8011] [software internal system syslog] query:14585, TCP, Sent time 1635329180, Timeout set 1635329183 ------------ DNS query is send for the second time
2021-Oct-27+17:06:20.911 [vpn 5456 info] [9/0/11730 <vpnmgr:6> vpnmgr_func.c:8011] [software internal system syslog] TCP Connection Successful - DHost-Id = 6766924, Sock_fd = 21
2021-Oct-27+17:06:21.008 [vpn 5456 info] [9/0/11730 <vpnmgr:6> vpnmgr_func.c:8011] [software internal system syslog] TCP READ, Kernel Closed, EOF - DHost-Id = 6766924, Sock_fd = 21, errno = 115, req_read_len = 0
2021-Oct-27+17:06:21.008 [vpn 5456 info] [9/0/11730 <vpnmgr:6> vpnmgr_func.c:8011] [software internal system syslog] TCP Connection close - DHost-Id = 6766924, Sock_fd = 21
2021-Oct-27+17:06:23.019 [vpn 5456 info] [9/0/11730 <vpnmgr:6> vpnmgr_func.c:8011] [software internal system syslog] query:14585, TCP, Timeout detected: 1635329183 ---------------- Timeout detected here
2021-Oct-27+17:06:23.019 [vpn 5456 info] [9/0/11730 <vpnmgr:6> vpnmgr_func.c:8011] [software internal system syslog] TCP Connection Init, While Sending Query --------------------- Query is send again
2021-Oct-27+17:06:23.019 [vpn 5456 info] [9/0/11730 <vpnmgr:6> vpnmgr_func.c:8011] [software internal system syslog] TCP Connection Open with DHost
2021-Oct-27+17:06:23.019 [vpn 5456 info] [9/0/11730 <vpnmgr:6> vpnmgr_func.c:8011] [software internal system syslog] query:14585, TCP, Sent time 1635329183, Timeout set 1635329186 ------- Again send the query with new timer value set
2021-Oct-27+17:06:23.019 [vpn 5456 info] [9/0/11730 <vpnmgr:6> vpnmgr_func.c:8011] [software internal system syslog] TCP Connection Successful - DHost-Id = 6504921, Sock_fd = 23
2021-Oct-27+17:06:26.036 [vpn 5456 info] [9/0/11730 <vpnmgr:6> vpnmgr_func.c:8011] [software internal system syslog] query:14585, TCP, Timeout detected: 1635329186 ---------------- Timeout detected here
2021-Oct-27+17:06:26.036 [vpn 5456 info] [9/0/11730 <vpnmgr:6> vpnmgr_func.c:8011] [software internal system syslog] query:35196, UDP, Timeout detected: 1635329186 ---------------- Timeout detected here

 Another example abcd.apn.epc.mncXXX.mccYYY.3gppnetwork.org

2021-Oct-27+17:06:27.257 [vpn 5456 info] [9/0/11730 <vpnmgr:6> vpnmgr_func.c:8011] [software internal system syslog] query:19140, UDP, Sent time 1635329187, Timeout set 1635329190 ---- timer is set here
2021-Oct-27+17:06:27.257 [vpn 5919 info] [9/0/11730 <vpnmgr:6> dns_resolver.c:323] [software internal system syslog] Sent out a DNS Query abcd.apn.epc.mncXXX.mccYYY.3gppnetwork.org to DNS Server --------- Query send for the first time
2021-Oct-27+17:06:27.258 [vpn 5456 info] [9/0/11730 <vpnmgr:6> vpnmgr_func.c:8011] [software internal system syslog] TCP Connection Init, While Sending Query
2021-Oct-27+17:06:27.258 [vpn 5456 info] [9/0/11730 <vpnmgr:6> vpnmgr_func.c:8011] [software internal system syslog] TCP Connection Open with DHost
2021-Oct-27+17:06:27.258 [vpn 5456 info] [9/0/11730 <vpnmgr:6> vpnmgr_func.c:8011] [software internal system syslog] query:19140, TCP, Sent time 1635329187, Timeout set 1635329190  -------- Same Query send for the second time
2021-Oct-27+17:06:27.258 [vpn 5456 info] [9/0/11730 <vpnmgr:6> vpnmgr_func.c:8011] [software internal system syslog] TCP Connection Successful - DHost-Id = 7201531, Sock_fd = 22
2021-Oct-27+17:06:27.309 [vpn 5921 debug] [7/0/12843 <sessmgr:79> dns_snaptr.c:1466] [software internal system syslog] VPN DEBUG : snaptr_match_valid_entries Initial ue_usage_type:0 nc_nr:0   ----- snaptr match starts
2021-Oct-27+17:06:27.309 [vpn 5921 debug] [7/0/12843 <sessmgr:79> dns_snaptr.c:237] [software internal system syslog] VPN DEBUG : snaptr_compare_service_protocol_set rr_service_parameter x-3gpp-mme:x-gn, inp_svc_param x-3gpp-sgw:x-s5-gtp ue_usage_type_enabled:0 nc_nr_enabled:0   ------- nc_nr enabled which I mentioned earlier
2021-Oct-27+17:06:27.309 [vpn 5921 debug] [7/0/12843 <sessmgr:79> dns_snaptr.c:237] [software internal system syslog] VPN DEBUG : snaptr_compare_service_protocol_set rr_service_parameter x-3gpp-sgw:x-s5-gtp:x-s8-gtp, inp_svc_param x-3gpp-sgw:x-s5-gtp ue_usage_type_enabled:0 nc_nr_e:nabled0
2021-Oct-27+17:06:27.309 [vpn 5921 debug] [7/0/12843 <sessmgr:79> dns_snaptr.c:279] [software internal system syslog] VPN DEBUG : 0.rr_prot_token x-s5-gtp, input token x-s5-gtp
2021-Oct-27+17:06:27.309 [vpn 5921 debug] [7/0/12843 <sessmgr:79> dns_snaptr.c:323] [software internal system syslog] VPN DEBUG : 4.Success Selected Protocol(Normal):x-s5-gtp  ----------- snaptr protocol matched
2021-Oct-27+17:06:30.057 [vpn 5456 info] [9/0/11730 <vpnmgr:6> vpnmgr_func.c:8011] [software internal system syslog] query:19140, TCP, Timeout detected: 1635329190 -------- TCP timeout happens
2021-Oct-27+17:06:30.057 [vpn 5456 info] [9/0/11730 <vpnmgr:6> vpnmgr_func.c:8011] [software internal system syslog] TCP Connection Init, While Sending Query ----- Again TCP connection initiated
2021-Oct-27+17:06:30.057 [vpn 5456 info] [9/0/11730 <vpnmgr:6> vpnmgr_func.c:8011] [software internal system syslog] TCP Connection Open with DHost
2021-Oct-27+17:06:30.057 [vpn 5456 info] [9/0/11730 <vpnmgr:6> vpnmgr_func.c:8011] [software internal system syslog] query:19140, TCP, Sent time 1635329190, Timeout set 1635329193 ------ New timer value set with send query
2021-Oct-27+17:06:30.057 [vpn 5456 info] [9/0/11730 <vpnmgr:6> vpnmgr_func.c:8011] [software internal system syslog] TCP Connection Successful - DHost-Id = 7136007, Sock_fd = 21
2021-Oct-27+17:06:30.158 [vpn 5456 info] [9/0/11730 <vpnmgr:6> vpnmgr_func.c:8011] [software internal system syslog] TCP READ, Kernel Closed, EOF - DHost-Id = 7136007, Sock_fd = 21, errno = 115, req_read_len = 0 – Error because TCP connection is busy because previous connection is not closed
2021-Oct-27+17:06:30.158 [vpn 5456 info] [9/0/11730 <vpnmgr:6> vpnmgr_func.c:8011] [software internal system syslog] TCP Connection close - DHost-Id = 7136007, Sock_fd = 21 -------- Connection closed
2021-Oct-27+17:06:30.171 [vpn 5921 debug] [14/0/12709 <sessmgr:15> dns_snaptr.c:1466] [software internal system syslog] VPN DEBUG : snaptr_match_valid_entries Initial ue_usage_type:0 nc_nr:0 --- again snaptr match takes place
2021-Oct-27+17:06:30.171 [vpn 5921 debug] [14/0/12709 <sessmgr:15> dns_snaptr.c:237] [software internal system syslog] VPN DEBUG : snaptr_compare_service_protocol_set rr_service_parameter x-3gpp-mme:x-gn, inp_svc_param x-3gpp-sgw:x-s5-gtp ue_usage_type_enabled:0 nc_nr_enabled:0
2021-Oct-27+17:06:30.171 [vpn 5921 debug] [14/0/12709 <sessmgr:15> dns_snaptr.c:237] [software internal system syslog] VPN DEBUG : snaptr_compare_service_protocol_set rr_service_parameter x-3gpp-sgw:x-s5-gtp:x-s8-gtp, inp_svc_param x-3gpp-sgw:x-s5-gtp ue_usage_type_enabled:0 nc_nr_enabled:0
2021-Oct-27+17:06:30.171 [vpn 5921 debug] [14/0/12709 <sessmgr:15> dns_snaptr.c:279] [software internal system syslog] VPN DEBUG : 0.rr_prot_token x-s5-gtp, input token x-s5-gtp
2021-Oct-27+17:06:33.073 [vpn 5456 info] [9/0/11730 <vpnmgr:6> vpnmgr_func.c:8011] [software internal system syslog] query:19140, TCP, Timeout detected: 1635329193 -----TCP timeout detected

Aus Protokollen zeigt es an, dass MME nach dem ersten Timeout für die nächsten Versuche den Fehler 115 sendet, da die erste TCP-Verbindung am Socket noch nicht geschlossen ist.  Das Timeout für die erste TCP-Verbindung ist aufgetreten, und die vorherige Verbindung wurde nicht geschlossen.

Es wird eine neue Verbindung initiiert, die sich auf demselben Socket befindet, auf dem die vorherige Verbindung hergestellt wurde und nicht gelöscht wird. Sie sehen den Fehler 115 (Vorgänge in Verarbeitung), obwohl die neue Verbindung gebildet wurde, aber irgendwie hat der Socket die vorherige Verbindung nach dem ersten Timeout nicht geschlossen.

Lösung

Starten Sie den vpnmgr des DNS-Kontexts neu. Eine Software-Reparatur ist noch nicht verfügbar.