Dépanner les problèmes de délai d'attente DNS dans MME

Introduction

Ce document décrit les problèmes liés au délai d'attente DNS (Domain Name System) pour les requêtes vers DNS dans MME (Mobile Management Entity) pour la sélection de Serving GateWay (SGW) et PGW (Packet Data Network Gateway).

Conditions préalables

Conditions requises

 Cisco vous recommande de prendre connaissance des rubriques suivantes :

• StarOS
• Fonctionnalité MME liée au DNS

Composants utilisés

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

• DNS
• MME

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

DNS

Le DNS transforme les noms de domaine en adresses IP, que les navigateurs utilisent pour charger les pages ABCD. Chaque périphérique connecté aux réseaux a sa propre adresse IP, qui est utilisée par d'autres périphériques pour localiser le périphérique.

Du point de vue de la mobilité, DNS est le serveur externe utilisé pour le nom de point d'accès (APN) et la résolution d'URL en fonction de sa connectivité avec les noeuds du réseau.

1. Connectivité MME à DNS : utilisée pour la résolution APN pour la sélection SPGW

2. Connectivité SPGW à DNS : Utilisé pour la résolution d'URL pour atteindre le fournisseur d'accès Internet (FAI)

Types d'enregistrements utilisés dans DNS.

1. Enregistrement A/AAA : Utilisé pour définir l'adresse d'hôte IPv4 et IPv6 mappée au nom complet de l'hôte où un enregistrement utilisé pour IPv4 et AAA (Authentication, Authorization and Accounting) utilisé pour IPv6.

2. Enregistrement NAPTR : utilisé comme service de recherche qui pointe vers un enregistrement de service (SRV) et des enregistrements A/AAA pour le processus de sélection SPGW pour l'APN 4G et la résolution TAC.

3. Enregistrement SRV: Utilisé comme recherche pour mapper entre un pointeur d'autorité de nom (NAPTR) et un enregistrement A/AAA.

Exemple : Observez comment le mappage A/SRV/NAPTR est effectué.

Fonctionnalité MME liée au DNS

• La fonction de base de MME liée au DNS est destinée à la sélection SGW et PGW basée sur les requêtes DNS.
• Cisco MME dispose de son propre cache DNS qui permet d'éviter les requêtes fréquentes vers des serveurs externes et stocke chaque requête exécutée dans le cache DNS MME afin de réduire la nécessité d'envoyer la requête à un serveur DNS externe.
• Lorsque l'UE s'enregistre sur un réseau EPS (Evolved Packet System), les SGW et PGW appropriés doivent lui être attribués. Le MME effectue la sélection GW en fonction du DNS.
• La requête NAPTR est utilisée pour effectuer la résolution d'adresse GW.
• En fonction de la requête DNS, MME détermine l'interface entre S-GW et P-GW.

Procédure de sélection SPGW 

• MME effectue une requête DNS initiale pour obtenir une liste des identités et des priorités GW
• Sélection S-GW effectuée en fonction de l'identificateur de zone de suivi (TAI)
• Sélection P-GW basée sur APN
• MME sélectionne le GW en fonction des informations de priorité ou de la configuration MME
• Ensuite, une deuxième requête DNS est effectuée pour obtenir les adresses IP de la GW souhaitée.

Ainsi, selon la procédure, MME fait toujours 2 requêtes DNS pour obtenir l'adresse IP GW qui est expliqué.

Requête 1 : Pour la première requête effectuée via APN ou TAI, vous obtenez un profil SRV mappé avec lui ou directement un résultat d'enregistrement A mappé en réponse.

Requête 2 : De plus, il fait une requête au profil SRV et l'envoie comme chaîne de remplacement pour obtenir l'IP GW.

Exemple :

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

Problème

1. Lorsque vous effectuez une requête NAPTR à partir de MME pour APN abcd.apn.epc.mncXXX.mccYY.3gppnetwork.org et que vous obtenez un délai DNS à MME.

Note: String +nc-nr est la nouvelle chaîne ajoutée au service 5G et ajoutée à chaque enregistrement de ressource NAPTR (RR) pour identifier l'interface de service.

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

Note: +nc-nr est la nouvelle chaîne basée sur le service 5G. MME doit donc prendre en charge ce service pour fonctionner car lorsque MME fait une requête DNS et obtient une réponse pour vérifier que ce service particulier est activé ou non dans MME.

[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. Dans les traces PCAP, il a été trouvé que le serveur DNS reçoit la requête et en réponse envoie 30 à 35 remplacements par chaque APN en raison de laquelle la taille de paquet devient 4186 octets et MME initie la connexion TCP.

3. Vous pouvez voir que DNS a reçu la requête et envoyer la réponse, mais sans aucun contenu avec un seul indicateur comme « Message est tronqué ». Ceci est observé uniquement dans le cas où le message de réponse est tronqué et où le reste des réponses 4G fonctionne correctement lorsque le message n'est pas tronqué.

La raison du message tronqué est qu'un certain nombre de remplacements mappés sur l'APN sont supérieurs à 30 et qu'il augmente la taille du message et envoie l'indicateur de message tronqué en réponse. La taille totale du message de réponse est de 4 181 octets en tant que charge utile TCP (reportez-vous à l'image).

Une fois que cette réponse est reçue au MME, MME initie la connexion TCP avec DNS.

 De MME à DNS

• Trame 31 - MME envoie une requête au DNS
• Trame 32 - DNS envoie une réponse avec l’indicateur défini lorsque “ message est tronqué ”
• Trame 33/34/35 : connexion TCP établie entre MME et DNS et échange de leurs propres fonctionnalités

Dans l'instantané donné, vous pouvez voir que la taille maximale de segment (MSS) envoyée à partir de MME est 9060.

Lorsque MME fait une requête pour laquelle DNS envoie une réponse avec « Message is truncated » et qu'il n'a pas d'autres informations après lesquelles en fonction de la réponse DNS MME initie la connexion TCP.

De DNS à MME

• MME envoie une requête après une connexion TCP
•  DNS le reconnaît.
•  DNS envoie une réponse avec l'indicateur défini comme “ Message n'est pas tronqué ” car MSS partagé avec DNS est défini à 9060 octets et envoie la réponse entière en une seule opération.
•  MME répond avec un ACK sans contenu
•  DNS envoie l’ACK au contenu du message 38 où la charge utile est de 4 181 octets
• MME envoie TCP pour réinitialiser et fermer les connexions dès qu'il reçoit le dernier fragment.

Lorsque MME reçoit l'intégralité de la charge utile en 2 à 3 segments ou lors d'une tentative de DNS, MME envoie un message de réinitialisation TCP.

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

Scénario de test

1. Capturez tous les journaux/traces de débogage requis avec un test dédié et activez les journaux en même temps lorsque l'abonné navigue avec APN problématique 

2. S'assurer que chaque fois qu'un scénario de test est exécuté, l'abonné doit effectuer une nouvelle connexion pour vider l'abonné.

3. Pour les besoins des tests, affectez un testeur et ce testeur doivent effectuer un test dédié avec son IMSI et avoir besoin d'accéder à ce APN problématique : 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)

Dépannage

1. Vérifiez les sorties de toutes les commandes mentionnées pour vérifier s'il y a une perte de paquet interne au système.

2. Vérifiez les statistiques pour confirmer que la fréquence des délais d’attente DNS augmente dans le noeud.

[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

Après avoir exécuté ces commandes pour capturer les statistiques pour plusieurs itérations et observer que les délais d'attente des requêtes sont augmentés progressivement mais qu'il n'y a pas eu de pertes de paquets entre Demux et les sessions, ce qui ne pose aucun problème avec le système interne

Pour vérifier tout problème de connectivité externe ou de configuration dans DNS, vous exécutez directement la requête pour les valeurs de remplacement manuellement à partir de MME au lieu d'APN comme indiqué dans l'image, où il est résolu correctement sans délai et conclut qu'il n'y a pas de problème avec la connectivité externe et la configuration également.

[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

Le problème se situe entre DNS et SGSN-MME, où vous pouvez voir les réponses d'envoi DNS avec des valeurs de remplacement comme topon et MME doit interroger à nouveau pour les entrées topon, mais qui ne se sont pas produites autrement si nous faisons manuellement la résolution de requête est réussie

Selon les résultats et les traces de la commande, il était clair que lorsque vous interrogez APN, vous obtenez des réponses avec 30 remplacements via la connexion TCP en fragments et tandis que MME reconnaît ces fragments, il envoie réinitialiser au DNS.

Puisque MME envoie TCP pour réinitialiser, nous pouvons voir dans MME où la requête DNS affiche une erreur en tant que délai d'attente de requête et jusqu'à ce moment-là, nous ne voyons pas ces 30 valeurs de remplacement dans les sorties de commande MME puisque les fragments n'ont pas été reconnus complètement et avant la fin de ce processus, MME envoie TCP pour réinitialiser.

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

À partir des journaux, il indique qu'après le premier délai d'attente, MME envoie l'erreur 115 pour les nouvelles tentatives, car la première connexion TCP n'est toujours pas fermée au niveau du socket.  Le délai d'attente de la première connexion TCP s'est écoulé et la connexion précédente n'a pas été fermée.

Une nouvelle connexion est initiée, qui se trouve sur le même socket où la connexion précédente a été établie et n'a pas été effacée. Vous voyez l'erreur 115 (opérations en cours) même si la nouvelle connexion a été formée mais que le socket n'a pas fermé la connexion précédente après le premier délai d'attente.

Solution

Redémarrez le vpnmgr du contexte DNS. Un correctif logiciel n'a pas encore été fourni.