Los paquetes malos formados del Troubleshooting HTTP que consiguen filtraron y cayeron por ECS en Cisco PGW

Introducción

Este documento describe cómo resolver problemas los paquetes malos formados HTTP que consiguen filtrados y caídos por el servicio de carga aumentado (ECS) en el gateway de la red de los datos del paquete de Cisco (PGW).

Prerrequisitos

Requisitos

Cisco recomienda que tenga conocimiento sobre estos temas:

• StarOS
• ECS

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

La información en este documento es similar a la configuración presente en el nodo del cliente, pero solamente la información pertinente se muestra aquí. Para que el propósito demuestre las trazas problemáticas sin exponer la información real, he cambiado o he pulso algunos IP Addresses de la información es decir.

Problema

Había denuncias del proveedor de servicio que algunos de los usuarios en su red no podrían acceder los sitios específicos del juego.

Cuando las trazas de tales usuarios fueron marcadas, fue descubierto que el tráfico problemático fue categorizado bajo definición de la regla (ruledef) que fue definida para filtrar los paquetes del error de HTTP en el PGW.

active-charging service <name>
 ruledef <name>
  http error = TRUE
 #exit
#exit

Troubleshooting

¿Cuál es ruledef?

La detección del tráfico HTTP de los suscriptores es alcanzada por los analizadores del protocolo que están presentes en ECS.

ECS tiene analizadores de protocolo que examinen el uplink y el tráfico del link descendente. El tráfico entrante entra un analizador de protocolo para la inspección de paquetes. Ruteando los ruledefs sea aplicado para determinar que los paquetes a examinar. Este tráfico entonces se envía al motor de carga donde están aplicados los ruledefs de carga para realizar las acciones tales como bloque, reorientarlas, o transmitirlas. Estos analizadores también generan los expedientes del uso para el sistema de facturación.

Ruledefs es expresiones definidas por el usario basadas en los campos del protocolo y los estados del protocolo, que definen qué acciones a tomar en los paquetes cuando los valores de campo especificados hacen juego.

Ruledefs que se utiliza sobre todo en un documento del Troubleshooting es:

Ruteando Ruledefs - Ruteando los ruledefs se utilizan a los paquetes de Routes para contentar los analizadores. Ruteando los ruledefs determine a los cuales el analizador contento para rutear el paquete cuando el protocolo coloca y/o los protocolo-estados en la expresión del ruledef es verdad. Hasta el 256 los ruledefs se pueden configurar para rutear.

Ruledefs de carga - Los ruledefs de carga se utilizan para especificar qué acción basó tomar en el análisis hecho por los analizadores contentos. Las acciones pueden incluir el cambio de dirección, el valor de la carga, y la emisión del registro de facturación.

Configuración de laboratorio

La configuración de muestra para probar este escenario en el PGW:

config
 active-charging service <name>

  ruledef http-error
   http error = TRUE
  #exit

  ruledef ip_any
   ip any-match = TRUE
  #exit

  charging-action block
   content-id 501
   billing-action egcdr
   flow action terminate-flow
  #exit

  charging-action ip-any-ca
   content-id 1
   billing-action egcdr
  #exit

  rulebase rulebase_all
   billing-records egcdr
   action priority 10 ruledef http-error charging-action block desc http-error_ruledef
   action priority 100 ruledef ip_any charging-action ip-any-ca desc ca_ruledef
   flow control-handshaking charge-to-application all-packets
   < some lines removed >
  #exit
 #exit
end

Registros de error

La traza problemática del suscriptor fue utilizada para regenerar la reproducción exacta del tráfico HTTP. Cuando la traza fue ejecutada con la configuración previa, estos ruledefs consiguieron detectados bajo el motor de ECS.

[local]spgw# show active-charging ruledef statistics all charging

Ruledef Name Packets-Down Bytes-Down Packets-Up Bytes-Up Hits Match-Bypassed
------------ ------------ ---------- ---------- -------- ---- --------------
ip_any       170          81917      207        34362    332  304
http-error   3            180        7          412      1    0

Total Ruledef(s) : 2

Esto dice, hay algunos paquetes enviados por UE que no sean paquetes HTTP apropiados y ésos se categorizan bajo ruledef del “HTTP-error” que esté presente en la configuración.

Después de que usted marque abra una sesión el sistema, usted pueda ver que los registros consiguen impresos como mensaje inválido del “paquete HTTP” visto allí. Marque el mensaje en estos registros:

2018-Nov-14+05:46:50.474 [acsmgr 91654 unusual] 
[1/0/17758 <sessmgr:1> http_analyzer.c:3478] [callid 00004e44] 
[Call Trace] [context: sgi, contextID: 4] [software internal system syslog] 
HTTP packet not valid
2018-Nov-14+05:46:50.474 [acsmgr 91025 trace] 
[1/0/17758 <sessmgr:1> acsmgr_rules.c:22912] 
[callid 00004e44] [Call Trace] [context: sgi, contextID: 
4] [software internal user syslog] ruledef: http-error matches for service ecs
2018-Nov-14+05:46:50.474 [acsmgr 91209 debug] 
[1/0/17758 <sessmgr:1> acsmgr_rules.c:22226] 
[callid 00004e44] [Call Trace] [context: sgi, contextID: 4] 
[software internal user syslog] normal charging-action (block) being applied

Del acuerdo a la definición presente en el nodo, el ruledef “HTTP-error” tiene la acción de carga asociada como “bloque” que correspondió con estos registros. Debido a esto, el suscriptor final no podía acceder el sitio web pues los paquetes fueron terminados (terminar-flujo de la acción de flujo) en el motor de ECS PGW.

Solución

Después de que usted convierta el archivo de traza del suscriptor en el archivo del pcap, usted ve que estos mensajes consiguen intercambiados entre el cliente (suscriptor final) y el servidor.

Según el flujo de llamada HTTP, el cliente debe enviar la petición HTTP-GET/POST al servidor y pedir el acceso una vez que el TCP SYN (usted ve que en el paquete no se ha intercambiado ningún 1, 4 y 7).

Sin embargo, en el archivo del pcap, usted no ve ningún tráfico HTTP dentro de él. Así pues, el paquete TCP que lleva el HTTP que señala o el payload causa este problema.

Si usted marca, el tamaño de la ventana TCP que se permite según RFC (rfc-1323) debe ser 65536 bytes (2*16=65536) de largo. 

El encabezado TCP utiliza un campo de bit 16 para señalar el tamaño de la ventana de la recepción al remitente. Por lo tanto, la ventana más grande que puede ser utilizada es los bytes 2**16 = 65K.

Si usted ve el paquete 7 WS, es demasiado grande estar de un paquete del reconocimiento (ACK). Normalmente, con el análisis HTTP encendido, el GGSN intenta analizar los mensajes GET/POST HTTP. Cuando los flujos HTTP no son conforme a RFC, puede ser que dé lugar a los errores sintácticos (y a los errores para clasificar correctamente el flujo HTTP según URL etc.).

Según lo sospechado, después del paquete ACK (el paquete 7), el cliente no envió la petición HTTP-GET/POST al servidor para pedir el acceso. En lugar, “PSH, ACK” se envía de UE. Eso no fue esperada por el motor PGW ECS. UE enviaba el payload de los paquetes TCP del interior HTTP (con el puerto 80 dest), debido a los cuales el gateway terminó que flujo de paquetes mientras que fue filtrado y correspondido con bajo ruledef del “HTTP-error” que tiene acción como “terminar-flujo”. Para el PGW, el mensaje previsto de UE habría sido HTTP-GET/POST que no fue visto. Por lo tanto, consideraba el paquete 10 como paquete mal formado.

Para verificar la duda más lejos, se modifica el archivo de traza del pcap cuando se quita el paquete problemático número 10 que tiene PSH-ACK, y la misma llamada se vuelve a efectuar otra vez, donde el ruledef problemático del “HTTP-error” no golpea otra vez bajo carga activa. Todos los paquetes fueron clasificados bajo ruledef “ip_any”. Eso dice el paquete mal formado era el paquete 10.

Refiera a la salida de muestra:

[local]spgw# show active-charging ruledef statistics all charging

Ruledef Name Packets-Down Bytes-Down Packets-Up Bytes-Up Hits Match-Bypassed
------------ ------------ ---------- ---------- -------- ---- --------------
ip_any       5            260        11         596      7    0
http-error   0            0          0          0        0    0

Total Ruledef(s) : 2

Para resumir esto:

En vez del paquete HTTP con la petición GET/POST, UE envió el paquete TCP PSH-ACK que era considerado como paquete mal formado y caído porque no era previsto. El proveedor de servicio fue informado sobre este comportamiento incorrecto del UEs específico. Cisco PGW trabaja según los estándares 3GPP.