Solucionar problemas de exploración de datos de usuario para URL web específicas

Introducción

Este documento describe los problemas de navegación de datos de usuario en la red 4G para todos los localizadores uniformes de recursos (URL).

Prerequisites

Cisco recomienda que conozca las funcionalidades de estos nodos:

• Gateway de datos de paquetes en servicio (SPGW)
• Separación del plano de usuario y control (CUPS)

Identificación de los síntomas

1. Compruebe qué tipo de datos es el problema: IPv4/IPv6/IPv4v6

2. Compruebe si el problema es con algún nombre de punto de acceso (APN) concreto o con todos los APN, ya que el problema puede estar relacionado con un APN específico.

3. Compruebe si el problema está relacionado con URL web específicas o con varias URL.

4. Compruebe si la URL es una URL de la aplicación de la empresa/del cliente o alguna URL de servicio regular y también compruebe si el problema es con una VPN específica.

5. Compruebe si el problema se produce al acceder a la URL directamente desde el navegador o al acceder a la propia aplicación web.

6. Compruebe si el problema es intermitente por naturaleza, como después de reiniciar el terminal o actualizar las URL web o si el problema es constante y no funciona incluso después de reiniciar el terminal.

7. Comprobar la causa de rechazo observada y para qué grupo de calificación.

Recopilación/prueba de registros

Antes de continuar con la prueba y la recopilación de registros:

Flush the subscriber from the node and also clear browsing history/database from testing user handset so that it can freshly attach

clear subscriber imsi <IMSI number>  ------------------ to be executed in the node to clear the subscriber

1. Comience con la prueba con un tipo de PDP primero como IPv4, donde ve el problema.
2. Habilite estos registros de depuración y registre la sesión de masilla. Asegúrese de que la sesión no debe finalizar (pulse tab/enter every some mins so that the session does not end).
   
   

On SPGW:
logging filter active facility sessmgr level debug
logging filter active facility acsmgr level debug
logging filter active facility npumgr-acl level debug
logging filter active facility firewall level debug
logging filter active facility vpn level debug
logging filter active facility vpnmgr level debug
logging active   ---------------- to enable the logging

after 5 mins 
no logging active ---------------- to disable the logging

On CP:
logging filter active facility sessmgr level debug
logging filter active facility sxdemux level debug
logging filter active facility firewall level debug
logging filter active facility vpn level debug
logging filter active facility vpnmgr level debug
logging active ---------------- to enable the logging

after 5 mins 
no logging active ---------------- to disable the logging

On UP:
logging filter active facility sessmgr level debug
logging filter active facility sxdemux level debug
logging filter active facility npumgr-acl level debug
logging filter active facility firewall level debug
logging filter active facility vpn level debug
logging filter active facility vpnmgr level debug
logging active ---------------- to enable the logging
no logging active ---------------- to disable the logging

Note :: These logging has to be enabled for short time depending on the CPU utilization because it 
increase the utilization so while enabling logging need to keep a watch on CPU

3. Acceda al modo de configuración y, a continuación, active el monitor de registro para el suscriptor.

config
logging monitor msid <imsi>
end

4. Abra otro terminal, registre la sesión de masilla y comience a monitorear al suscriptor con verbosidad 5 y habilite estas opciones:

SPGW:
Press + for times then it collects the logs verbosity 5 logs then select next options
+++++
X, A, Y, 19, 33, 34, 35, 22, 26, 75
Once option 75 is pressed then select 3,4,8 then press esc

CUPS::
on CP:
monitor subscriber imsi <IMSI> +++++        S, X,A,Y,56,26,33,34,19,37,35,88,89
on UP:
monitor subscriber imsi <IMSI> +++++        S,X,A,Y,56,26,33,34,19,37,35,88,89

5. Adjunte el suscriptor y navegue por la URL continuamente durante 3 a 5 minutos y mientras navega ejecute estos comandos varias veces y registre la sesión de masilla para la misma.

ON SPGW/SAEGW:
show subscriber full imsi <>
show active-charging session full imsi <>
show subscriber pgw-only full imsi <>
show subscriber sgw-only full imsi <>
show subscribers data-rate summary imsi <>
show ims-authorization sessions full imsi <>
show subscribers debug-info msid <>

On CP node:
Show subscriber full imsi <imsi>
Show active-charging session full imsi <imsi>
show subscribers pgw-only full imsi <>
show subscribers sgw-only full imsi <>
show session subsystem facility sessmgr instance <> verbose
show logs

On UP node:
show sub user-plane-only full callid  <>
show sub user-plane-only callid <> urr full all
show sub user-plane-only callid <> far full all
show sub user-plane-only callid <> pdr full all
show subscribers user-plane-only callid <> far all
show subscribers user-plane-only callid <> far
show subs data-rate call <callid>
show subscribers user-plane-only flows
show user-plane-service statistics all
show user-plane-service statistic rulebase name <rulebase_name>

6. Después de 5 minutos de navegación, ejecute el  no logging active  en el otro terminal que se abre en el paso 3.

7. Inhabilite el monitor de registro para el suscriptor.

Config
no logging monitor msid <imsi>
end

8. No detenga el mon sub y déjelo funcionar hasta que termine de recolectar rastros de números, pero mantenga un ojo en la CPU.

9. Ejecute este comando para obtener la identificación de llamada del suscriptor y registre la sesión de masilla para esto también.

Show subscriber full imsi <imsi>. -à get the call id
show logs callid <call_id>
show logs

Si el ID de la persona que llama está presente, está claro que se recopilaron los registros de sesión de los suscriptores; si no es así, debe ejecutarlo nuevamente.

Resolución de problemas realizada

1. Haga ping en la dirección IP del servidor de URL web y compruebe si hay caídas de paquetes.

   
ping 
    
    
      ------------ from Gi context 
     
--- ping statistics --- 
     
3 packets transmitted, 0 received, 100% packet loss, time 12160ms. >.>>>> There are packet drops, now we need to check were it is dropping 
     
 
    

2. Realice una  traceroute  desde el contexto de GI y compruebe si hay problemas de disponibilidad.

traceroute 
    
    
      src 
      
      
    

Ex: traceroute 10.52.5.49 src 10.203.144.8

3. Verifique las estadísticas del suscriptor para verificar las caídas de paquetes.

Show subscriber full imsi 
    
    

input pkts: 455 output pkts: 474 
input bytes: 75227 output bytes: 103267 
input bytes dropped: 0 output bytes dropped: 0 
input pkts dropped: 0 output pkts dropped: 0 
input pkts dropped due to lorc : 0 output pkts dropped due to lorc : 0 
input bytes dropped due to lorc : 0 
in packet dropped suspended state: 0 out packet dropped suspended state: 0 
in bytes dropped suspended state: 0 out bytes dropped suspended state: 0 
in packet dropped sgw restoration state: 0 out packet dropped sgw restoration state: 0 
in bytes dropped sgw restoration state: 0 out bytes dropped sgw restoration state: 0 
pk rate from user(bps): 18547 pk rate to user(bps): 25330 
ave rate from user(bps): 6182 ave rate to user(bps): 8443 
sust rate from user(bps): 5687 sust rate to user(bps): 7768 
pk rate from user(pps): 13 pk rate to user(pps): 14 
ave rate from user(pps): 4 ave rate to user(pps): 4 
sust rate from user(pps): 4 sust rate to user(pps): 4 
link online/active percent: 92 
ipv4 bad hdr: 0 ipv4 ttl exceeded: 0 
ipv4 fragments sent: 0 ipv4 could not fragment: 0 
ipv4 input acl drop: 0 ipv4 output acl drop: 0 
ipv4 bad length trim: 0 
ipv6 input acl drop: 0 ipv6 output acl drop: 0 
ipv4 input css down drop: 0 ipv4 output css down drop: 0 
ipv4 input css down drop: 0 ipv4 output css down drop: 0 
ipv4 output xoff pkts drop: 0 ipv4 output xoff bytes drop: 0 
ipv6 output xoff pkts drop: 0 ipv6 output xoff bytes drop: 0 
ipv6 input ehrpd-access drop: 0 ipv6 output ehrpd-access drop: 0 
input pkts dropped (0 mbr): 0 output pkts dropped (0 mbr): 0 
ip source violations: 0 ipv4 output no-flow drop: 0 
ipv6 egress filtered: 0 
ipv4 proxy-dns redirect: 0 ipv4 proxy-dns pass-thru: 0 
ipv4 proxy-dns drop: 0 
ipv4 proxy-dns redirect tcp connection: 0 
ipv6 bad hdr: 0 ipv6 bad length trim: 0 
ip source violations no acct: 0 
ip source violations ignored: 0 
dormancy total: 0 handoff total: 0 
ipv4 icmp packets dropped: 0 
APN AMBR Input Pkts Drop: 0 APN AMBR Output Pkts Drop: 0 
APN AMBR Input Bytes Drop: 0 APN AMBR Output Bytes Drop: 0 
APN AMBR UE Overload Input Pkts Drop: 0 APN AMBR UE Overload Output Pkts Drop: 0 
APN AMBR UE Overload Input Bytes Drop: 0 APN AMBR UE Overload Output Bytes Drop: 0 
Access-flows:0
Num Auxiliary A10s:0    

4. Verifique la salida de carga show active para ver el impacto del tráfico del suscriptor.

Show active-charging session full imsi <imsi num>

PP Dropped Packets: 0
CC Dropped Uplink Packets: 0 CC Dropped Uplink Bytes: 0
CC Dropped Downlink Packets: 0 CC Dropped Downlink Bytes: 0

5. Verifique la salida del comando show active charging para la caída de paquetes de nivel ECS/ACS y verifique si hay alguna caída de paquetes. A continuación, compruebe en la configuración qué acción se ha configurado.

Show active-charging session full imsi 
     
       or show sub user-plane-only full callid  <> 
     
 Ruledef Name        Pkts-Down Bytes-Down Pkts-Up Bytes-Up Hits Match-Bypassed
-------------------- ---------- ---------- ---------- ---------- ---------- --------------
dns_free_covid        4       428      4           340   8    0
icmpv6               0        0       5           1423  5    0
ip-pkts              479      103670  432         74488 764  429      

6. Compruebe si la resolución DNS es correcta o no. Si tiene éxito, no hay problema con DNS.

7. Compruebe que la conexión TCP se ha establecido correctamente entre el equipo del usuario (UE) y el servidor.

8. Si no se observan caídas en ninguno de estos pasos, no hay ningún problema en el nodo.

Descartes de paquetes

1. Verifique las estadísticas de la versión del suscriptor para determinar si está experimentando caídas de paquetes similares a las que se muestran aquí.

 Total Dropped Packets : 132329995
Total Dropped Packet Bytes: 14250717212

Total PP Dropped Packets : 0
Total PP Dropped Packet Bytes: 0

R7Gx Rule-Matching Failure Stats:
Total Dropped Packets : 871921
Total Dropped Packet Bytes : 86859232

P2P random drop stats:
Total Dropped Packets : 0
Total Dropped Packet Bytes : 0

2. Verifique el porcentaje de fallas observadas en la salida show subscriber. Si las caídas de paquetes son inferiores al 1%, lo más probable es que sea una casualidad y no tenga ningún efecto.

input pkts: 455 output pkts: 474 
input bytes: 75227 output bytes: 103267 
input bytes dropped: 0 output bytes dropped: 0 
input pkts dropped: 0 output pkts dropped: 0

3. Si observa caídas de paquetes en el grupo de clasificación RX y caídas de paquetes ITC, lo más probable es que se deba a un problema de ancho de banda y que el paquete del suscriptor haya caducado.

 ITC Packets Drop:                           47235019

4. En el nivel de servicio de cobro mejorado (ECS), debe comprobar/verificar la configuración de ECS de cómo se definen las acciones/bases de reglas de cobro/reglas y si tiene algún factor de bloqueo. Existen diferentes tipos de caídas en el nivel de ECS y se basan en el tipo de caídas que necesita para continuar con el siguiente plan de acción.

5. Tamaño de MTU para el tamaño del paquete que pasa y no se procesa.

6. Los problemas de trayectoria intermedios en los que se descarta el paquete se pueden identificar a partir de los seguimientos de nivel de usuario/volcado de TCP.

El plan de acción de recuperación no es el mismo para este tipo de problema, ya que varía según el patrón del problema.