Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Descripción general de GGSN

El nodo de soporte GPRS (GGSN) de puerta de enlace convierte el tráfico de datos entrante procedente de los usuarios móviles a través del nodo de soporte GPRS (SGSN) de puerta de enlace de servicio y lo reenvía a la red correspondiente y viceversa. El GGSN y el SGSN juntos forman los nodos de soporte gpRS (GSN).

Descripción de la redirección de GGSN

Junos OS admite tráfico de protocolo de tunelización GPRS (GTP) y redirección del nodo de soporte GPRS (GGSN) de puerta de enlace. Una GGSN (X) puede enviar respuestas create-pdp-context en las que puede especificar diferentes direcciones IP GGSN (GGSN Y y GGSN Z) para mensajes GTP-C y GTP-U subsiguientes. En consecuencia, el SGSN envía el protocolo de tunelización GGSN subsiguiente, el protocolo de control (GTP-C) y el protocolo de tunelización GGSN, el plano de usuario (GTP-U) a las GGSN Y y Z, en lugar de X.

Descripción general de escenarios de agrupación de GGSN

El protocolo de tunelización (GTP) del Servicio general de radio de paquetes (GPRS) admite diferentes direcciones IP de nodo de soporte GPRS (GGSN) de puerta de enlace durante un procedimiento de creación de túnel. Hay dos escenarios de agrupación de GGSN que admiten itinerancia del nodo de soporte GPRS (SGSN).

Descripción de la agrupación de GGSN para el escenario 1

En la figura 1, se envía una solicitud contextual de protocolo de datos de paquete (PDP) desde SGSN A a GGSN B durante un procedimiento de creación de túnel GTP. Después de enviar el mensaje de solicitud de contexto PDP, GGSN D registra la información de la solicitud y utiliza una dirección IP de destino diferente a la dirección IP de destino del paquete de solicitud para enviar el mensaje de respuesta a SGSN A.

En este caso, dos mensajes de paquete GTP se envían a la unidad de procesamiento de servicios 1 (SPU1) y la SPU2 por el punto central, y los mensajes se procesan por SPU1 y SPU2 de forma individual. La sesión se crea en SPU1 y SPU 2 para cada paquete GTP. La SPU1 registra la información del paquete de solicitud y la SPU2 registra la información del paquete de respuesta.

El mensaje de respuesta PDP enviado desde GGSN D a SGSN A se pierde debido a la falta de información de solicitud. Por lo tanto, no se establece el túnel GTP.

Figura 1: Situación 1 GGSN Pooling Scenario 1 de agrupación de GGSN
Nota:

SPU2 no puede recuperar información de solicitud de SPU1.

Instalar información de solicitud en SPU remota

En este caso, se perdió el paquete de respuesta PDP debido a la falta de información de solicitud y no se estableció el túnel GTP. Esto se puede resolver instalando la información de solicitud en la SPU correcta.

En la figura 2, al crear un túnel, la dirección IP GGSN del paquete de respuesta cambia, activando una nueva sesión, y el punto central distribuye el mensaje a otra SPU.

El paquete de respuesta siempre envía a la dirección de origen del paquete de solicitud a la SPU. Esto ayuda a instalar la información de solicitud en la SPU remota para el siguiente paquete de respuesta.

Instale la información de solicitud en la función SPU, HASH (req-src-ip) predecible mientras procesa el paquete de solicitud. Después de que el número de SPU esperado (Hash (10.1.1.1.1) = SPU2) se calcula por la dirección IP de origen del mensaje de solicitud PDP, la información de la solicitud se instala en la SPU2 remota mediante la interfaz de paso de mensajes de Juniper (JMPI).

Figura 2: Funcionalidad: Escenario 1 Functionality : GGSN Pooling Scenario 1 de agrupación de GGSN

Ahora la información de solicitud está instalada en SPU1 local y SPU2 remota, por lo que se permite el mensaje de respuesta PDP.

Soluciones alternativas para el escenario 1

En el escenario 1, el mensaje de solicitud de contexto PDP enviado desde SGSN A alcanzó la aplicación junos-gprs-gtp predeterminada de Junos OS y la inspección gtp se habilitó para el mensaje de solicitud de contexto PDP. Sin embargo, el mensaje de respuesta de contexto PDP enviado desde GGSN D no puede llegar a la aplicación junos-gprs-gtppredeterminada de Junos OS. Por lo tanto, el módulo GTP no inspeccionará el paquete.

Como solución alternativa, debe habilitar la inspección de GTP para el mensaje de respuesta contextual PDP configurando las aplicaciones y la política personalizada. Consulte Configurar una aplicación o política personalizada de GGSN.

Descripción de la agrupación de GGSN para el escenario 2

En la figura 3, se envía una solicitud contextual de protocolo de datos de paquete (PDP) desde SGSN A a GGSN B durante un procedimiento de creación de túnel GTP. Después de recibir el mensaje de solicitud de contexto PDP, GGSN B envía el mensaje de respuesta contextual PDP a SGSN A. Después de recibir el mensaje de respuesta de contexto PDP, se crea el túnel GTP-C entre SGSN C y GGSN D. Luego, SGSN C envía un mensaje de actualización de solicitud de contexto PDP a GGSN D mediante diferentes direcciones IP de origen y destino desde el encabezado IP del paquete de solicitud.

En el escenario 2, el SGSN A crea la primera solicitud de contexto GTP y la envía a la SPU por el punto central. La sesión se crea para el paquete de solicitud en SPU1. El paquete de respuesta enviado desde GGSN B a SGSN A llega correctamente a la sesión.

El paquete de solicitud enviado desde SGSN A indica que GTP-C se establece en ip de control 10.1.1.2 y el GTP-U se establece en ip de datos 10.1.1.3. Asimismo, el mensaje de respuesta enviado desde GGSN indica que GTP-C se establece en el control IP 10.2.2.3 y GTP-U se establece en los datos IP 10.2.2.4.

Los túneles GTP-C y GTP-U se crean en SPU1 local después de establecer todos los puntos de conexión. Sin embargo, el túnel no está establecido en la SPU 2, por lo que el mensaje de solicitud de actualización de PDP recibido de SPU2 se pierde.

Figura 3: Situación 2 de agrupación de GGSN Pooling Scenario 2 GGSN

Instalar información de túnel en SPU remota

En el escenario 2, el paquete de solicitud de actualización se pierde debido a la falta de información de túnel. Esto se puede resolver instalando la información del túnel en la SPU correcta después de procesar los paquetes de solicitud y respuesta. La SPU que recibe el paquete de respuesta instala la información del túnel en la SPU local o remota.

En la figura 4, después de establecer el túnel, los mensajes de control se envían al punto de conexión del túnel de control. La dirección IP de destino de todos los mensajes de control debe ser la dirección IP del punto de conexión GGSN del túnel de control. Esto ayuda a calcular el número de SPU remoto de antemano para el mensaje de control posterior.

Instale la información del túnel en la SPU predecible. Después de calcular el número de SPU mediante la IP del punto de conexión GGSN del túnel de control, la información del túnel se instala en la SPU remota mediante JMPI.

Figura 4: Funcionalidad: Escenario 2 Functionality : GGSN Pooling Scenario 2 de agrupación de GGSN

Ahora la información del túnel está instalada en la SPU2 remota, por lo que se permite el mensaje de respuesta de actualización de PDP.

Ejemplo: Configurar una aplicación y una política personalizadas de GGSN

En este ejemplo, se muestra cómo configurar una aplicación y una política personalizada de nodo de soporte GPRS (GGSN) de puerta de enlace para admitir el escenario 1 de agrupación de GGSN.

Requisitos

En este ejemplo, se utilizan los siguientes componentes de hardware y software:

  • Dispositivo SRX5400

  • Una PC

  • Junos OS versión 12.1X44-D10

Configuración

Configuración de una política personalizada de GGSN

Visión general

En este ejemplo, se muestra cómo configurar las políticas de seguridad para el tráfico gtp que hará que el tráfico funcione en caso de que se produzca agrupación de GTP. En este mismo ejemplo, también se hará que el tráfico GTP fluya correctamente cuando la función Distribución GTP esté habilitada, con o sin inspección de GTP. Lo que hacemos aquí es configurar las políticas de seguridad en ambas direcciones, reflejadas. En ambas direcciones usamos los mismos objetos de dirección y las mismas aplicaciones. Además de la aplicación regular de GTP junos-gprs-gtp, creamos una aplicación GTP inversa personalizada, denominada reverse-junos-gprs-gtp. Esta aplicación GTP inversa hará que los paquetes GTP coincidan con la política de seguridad, incluso cuando solo su puerto UDP de origen es un puerto GTP conocido. De esta manera, todo el tráfico GTP será emparejado por las políticas y se manejará correctamente como tráfico GTP.

Configuración rápida de CLI

Para configurar rápidamente este ejemplo, copie los siguientes comandos, péguelos en un archivo de texto, elimine los saltos de línea, cambie los detalles necesarios para que coincidan con su configuración de red, copie y pegue los comandos en la CLI en el nivel de jerarquía y, luego, ingrese commit desde el [edit] modo de configuración.

En caso de que se use la función distribución GTP sin la inspección de GTP, no cree el perfil GTP y no aplique el gtp-profile de application-services a las políticas de seguridad.

Procedimiento paso a paso

Para configurar una política personalizada de GGSN:

  1. Configure la dirección de origen.

  2. Configure la dirección de destino.

  3. Configure las aplicaciones de políticas.

  4. Configure el tipo de actividad y especifique el nombre del perfil GTP.

    En caso de que se utilice la función de distribución gtp sin inspección gtp:

  5. Configure lo mismo de nuevo, con la confianza y el no confianza de las zonas de seguridad revertidas.

Resultados

Desde el modo de configuración, ingrese el comando para confirmar la show security policies configuración. Si el resultado no muestra la configuración deseada, repita las instrucciones de configuración en este ejemplo para corregirla.

Antes de que podamos confirmar la configuración, debemos configurar la aplicación GTP inversa.

Configuración de la aplicación GTP inversa

Cuando se utiliza la función de distribución GTP , las sesiones de flujo se establecerán como unidireccionales. Esta acción para establecerlos como unidireccionales lo realiza el GTP ALG (incluso cuando no se utiliza la inspección GTP). Por esta razón, es necesario que el GTP ALG se aplique a todo el tráfico GTP.

La aplicación predefinida junos-gprs-gtp está configurada con el ALG GTP. Sin embargo, en algunos casos, es posible que el tráfico GTP no coincida con esta aplicación, que será el caso del tráfico de devolución cuando se utilizó un puerto de origen diferente al de los puertos UDP gtp estándar. En ese caso, el ala de sesión inversa puede tener un puerto de destino aleatorio y el puerto GTP estándar como puerto de origen. Para asegurarse de que el GTP ALG se aplica a este tráfico GTP inverso en este caso, es necesario agregar la siguiente aplicación GTP 'inversa' a todas las políticas de seguridad de GTP.

Configuración rápida de CLI

Para configurar rápidamente este ejemplo, copie los siguientes comandos, péguelos en un archivo de texto, elimine los saltos de línea, cambie los detalles necesarios para que coincidan con su configuración de red, copie y pegue los comandos en la CLI en el nivel de jerarquía y, luego, ingrese commit desde el [edit] modo de configuración.

Verificación

Confirme que la configuración funciona correctamente.

Verificar la configuración

Propósito

Compruebe que la configuración de la política personalizada de GGSN sea correcta.

Acción

Confirme la configuración y salga. Desde el modo operativo, ingrese el show security policies comando.

Salida de muestra
nombre de comando

Este resultado muestra un resumen de la configuración de políticas.