Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

GGSN Overview

The gateway GPRS support node (GGSN) converts the incoming data traffic coming from the mobile users through the Service gateway GPRS support node (SGSN) and forwards it to the relevant network, and vice versa. The GGSN and the SGSN together form the GPRS support nodes (GSN).

Understanding GGSN Redirection

Junos OS supports GPRS tunneling protocol (GTP) traffic and gateway GPRS support node (GGSN) redirection. A GGSN (X) can send create-pdp-context responses in which it can specify different GGSN IP addresses (GGSN Y and GGSN Z) for subsequent GTP-C and GTP-U messages. Consequently, the SGSN sends the subsequent GGSN tunneling protocol, control (GTP-C) and GGSN tunneling protocol, user plane (GTP-U) messages to GGSNs Y and Z, instead of X.

GGSN Pooling Scenarios Overview

The General Packet Radio Service (GPRS) tunneling protocol (GTP) supports different Gateway GPRS Support Node (GGSN) IP addresses during a tunnel creation procedure. There are two GGSN pooling scenarios that support Serving GPRS Support Node (SGSN) roaming.

Understanding GGSN Pooling for Scenario 1

In Figure 1, a packet data protocol (PDP) context request is sent from SGSN A to GGSN B during a GTP tunnel creation procedure. After sending the PDP context request message, GGSN D records the request information and it uses a different destination IP address from the request packet’s destination IP address to send the response message to SGSN A.

In this scenario, two GTP packet messages are sent to Services Processing Unit 1 (SPU1) and SPU2 by the central point, and the messages are processed by SPU1 and SPU2 individually. The session is created on SPU1 and SPU 2 for each GTP packet. SPU1 records the request packet information and SPU2 records the response packet information.

The PDP response message sent from GGSN D to SGSN A is dropped because of a lack of request information. Thus the GTP tunnel is not established.

Figure 1: GGSN Pooling Scenario 1GGSN Pooling Scenario 1
Note:

SPU2 cannot retrieve request information from SPU1.

Install Request Information to Remote SPU

In this scenario, the PDP response packet was dropped because of a lack of request information, and the GTP tunnel was not established. This can be resolved by installing the request information on the correct SPU.

In Figure 2, when creating a tunnel, the response packet's GGSN IP address changes, triggering a new session, and the central point distributes the message to another SPU.

The response packet always sends to the request packet's source address to the SPU. This helps to install the request information to the remote SPU for the next response packet.

Install the request information into the predictable SPU, HASH (req-src-ip) function while processing the request packet. After the expected SPU number (Hash (10.1.1.1) = SPU2) is calculated by the source IP address of the PDP request message, the request information is installed in the remote SPU2 through the Juniper Message Passing Interface (JMPI).

Figure 2: Functionality : GGSN Pooling Scenario 1Functionality : GGSN Pooling Scenario 1

Now the request information is installed on local SPU1 and remote SPU2, so the PDP response message is allowed.

Workarounds for Scenario 1

In scenario 1, the PDP context request message sent from SGSN A reached the Junos OS default application junos-gprs-gtp and the GTP inspection was enabled for PDP context request message. However, the PDP context response message sent from GGSN D cannot reach the Junos OS default application junos-gprs-gtp. Thus the packet will not be inspected by the GTP module.

As a workaround, you need to enable GTP inspection for the PDP context response message by configuring the custom policy and applications. Refer to Configuring a GGSN Custom Policy/Application.

Understanding GGSN Pooling for Scenario 2

In Figure 3, a packet data protocol (PDP) context request is sent from SGSN A to GGSN B during a GTP tunnel creation procedure. After receiving the PDP context request message, GGSN B sends the PDP context response message to SGSN A. After receiving the PDP context response message, the GTP-C tunnel is created between SGSN C and GGSN D. Then SGSN C sends an update PDP context request message to GGSN D using different source and destination IP addresses from the request packet's IP header.

In scenario 2, the SGSN A creates the first GTP context request and sends it to the SPU by the central point. The session is created for the request packet on SPU1. The response packet sent from GGSN B to SGSN A reaches the session correctly.

The request packet sent from SGSN A indicates that GTP-C is established on control IP 10.1.1.2 and the GTP-U is established on data IP 10.1.1.3. Likewise, the response message sent from GGSN indicates that GTP-C is established on control IP 10.2.2.3 and GTP-U is established on data IP 10.2.2.4.

The GTP-C and GTP-U tunnels are created on local SPU1 after all the endpoints are established. However, the tunnel is not established on SPU 2, so the PDP update request message received from SPU2 is dropped.

Figure 3: GGSN Pooling Scenario 2GGSN Pooling Scenario 2

Install Tunnel Information to Remote SPU

In scenario 2, the update request packet is dropped because of a lack of tunnel information. This can be resolved by installing the tunnel information to the correct SPU after the request and response packets are processed. The SPU that receives the response packet installs the tunnel information on the local or remote SPU.

In Figure 4, after the tunnel is established, the control messages are sent to the control tunnel endpoint. The destination IP address of all the control messages should be the control tunnel's GGSN endpoint IP address. This helps to calculate the remote SPU number in advance for the subsequent control message.

Install the tunnel information into the predictable SPU. After the SPU number is calculated by the control tunnel GGSN endpoint IP, the tunnel information is installed in the remote SPU through JMPI.

Figure 4: Functionality : GGSN Pooling Scenario 2Functionality : GGSN Pooling Scenario 2

Now the tunnel information is installed on remote SPU2, so the PDP update response message is allowed.

Example: Configuring a GGSN Custom Policy and Application

This example shows how to configure a Gateway GPRS Support Node (GGSN) custom policy and application to support GGSN pooling scenario 1.

Requirements

This example uses the following hardware and software components:

  • SRX5400 device

  • A PC

  • Junos OS Release 12.1X44-D10

Configuration

Configuring a GGSN Custom Policy

Overview

This example shows how to configure Security policies for GTP traffic which will make traffic work in case GTP Pooling occurs. This same example will also make GTP traffic flow correctly when the GTP Distribution feature is enabled, with or without GTP inspection. What we do here is configure the security policies in both directions, mirrored. In both directions we use the same address objects and the same applications. Besides the regular GTP application junos-gprs-gtp, we create a custom reverse GTP application, named reverse-junos-gprs-gtp. This reverse GTP application will make GTP packets match the security policy, even when only their source UDP port is a well-known GTP port. This way, all GTP traffic will be matched by the policies and handled correctly as GTP traffic.

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

In case when the GTP Distribution feature is used without GTP inspection, do not create the GTP profile and do not apply the application-services gtp-profile to the security policies.

Step-by-Step Procedure

To configure a GGSN custom policy:

  1. Configure the source address.

  2. Configure the destination address.

  3. Configure the policy applications.

  4. Configure the activity type and specify the GTP profile name.

    In case when the GTP Distribution feature is used without GTP inspection:

  5. Configure the same again, with the security zones trust and untrust reversed.

Results

From configuration mode, confirm your configuration by entering the show security policies command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

Before we can commit the configuration, we need to configure the reverse GTP application.

Configuring Reverse GTP Application

When using the GTP Distribution feature, the flow sessions will be set as uni-directional. This action to set them as uni-directional is performed by the GTP ALG (even when not using GTP Inspection). For this reason it is needed that the GTP ALG gets applied to all GTP traffic.

The predefined application junos-gprs-gtp is configured with the GTP ALG. However in some cases GTP traffic may not match this application, which will be the case for the return traffic when a different source port was used than the standard GTP UDP ports. In that case the reverse session wing can have a random destination port and the standard GTP port as source port. In order to make sure that the GTP ALG is applied to this reverse GTP traffic in this case, it is needed to add the following 'reverse' GTP application to all the GTP security policies.

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Verification

Confirm that the configuration is working properly.

Verifying the Configuration

Purpose

Verify that the GGSN custom policy configuration is correct.

Action

Commit the configuration and exit. From operational mode, enter the show security policies command.

Sample Output
command-name

This output shows a summary of policy configuration.