Configuring GGSN GTP Services
Available Languages
Table Of Contents
GGSN Services Configuration Task List
Creating a Virtual Template Interface for GGSN
Configuring the GGSN Compliance Baseline
Configuring Echo Timing on a GGSN
Overview of the Echo Timing on the GGSN
Overview of the Default Echo Timer
Overview of the Dynamic Echo Timer
Echo Timing Configuration Task List
Customizing the Default Echo Timer
Configuring the Dynamic Echo Timer
Verifying the Echo Timing Configuration
Verifying Echo Timing Parameters
Verifying the Dynamic Echo Timer by GTP Path
Customizing the GGSN Configuration
Configuring GTP Signaling Options
Configuring Other GTP Signaling Options
Configuring the Maximum Number of PDP Contexts on the GGSN
Configuring the Maximum Number of PDP Contexts When Using DFP with Load Balancing
Controlling Sessions on the GGSN
Overview of the Session Idle Timer and the Absolute Session Timer on the GGSN
Configuring the Session Idle Timer
Configuring the Absolute Session Timer
Verifying the Timer Configuration
Configuring Flow Control for GTP Error Messages
Using the Service-Mode Function
Configuring Global Maintenance Mode
Configuring APN Maintenance Mode
Configuring Charging Maintenance Mode
Monitoring and Maintaining GTP on the GGSN
Dynamic Echo Timer Configuration Example
Configuring GGSN GTP Services
This chapter describes how to configure a gateway GPRS service node (GGSN) and how to configure GPRS tunneling protocol (GTP) options.
For a complete description of the GGSN commands in this chapter, refer to the Cisco GGSN Release 5.2 Command Reference.
To locate documentation of other commands that appear in this chapter, use the command reference master index or search online. See the "Related Documents" section for a list of the other Cisco IOS software documentation that might be helpful while configuring the GGSN.
This chapter includes the following sections:
•
Configuring the GGSN Compliance Baseline
•
•
•
•
GTP Overview
GTP is the protocol used to tunnel multi-protocol packets through the general packet radio service/Universal Mobile Telecommunication System (GPRS/UMTS) network. It is defined on the Gn interface as the protocol between GSNs in the GPRS/UMTS backbone network.
With GGSN 4.0 in Cisco IOS 12.3(2)XB and later, the Cisco GGSN simultaneously supports both GTP Version 0 (GTP v0) and GTP Version 1 (GTP v1). GPRS R97/R98 uses GTP Version 0, and UMTS R99 uses GTP v1.
The GGSN automatically selects the GTP version to use according to the capabilities of the SGSN.
Configuring GGSN Services
The Cisco GGSN software uses a logical interface called a virtual template interface to configure a router or instance of Cisco IOS software on a Cisco Multi-Processor WAN Application Module (MWAM) as a GGSN. This section describes the primary tasks you need to complete when configuring for GGSN services. The subsequent configuration tasks describe how to establish connectivity from the GGSN to the serving GPRS support node (SGSN) and public data networks (PDNs) once the router or Cisco IOS instance has been configured as a GGSN.
The following requirements must be met when configuring a GGSN:
•
–
–
–
•
–
–
–
GGSN Services Configuration Task List
To configure a router or Cisco IOS software instance for GGSN services, perform the following tasks:
•
•
Enabling GGSN Services
Configure only a single GGSN entity per router or instance of Cisco IOS software, using the service gprs ggsn global configuration command.
To enable GGSN services, use the following command in global configuration mode:
Router(config)# service gprs ggsn
Specifies that the router or Cisco IOS instance functions as a GGSN.
Creating a Loopback Interface
Rather than directly configuring an IP address on the virtual template, we recommend that you create a loopback interface and then associate the loopback interface IP address to the virtual template used for GTP encapsulation using the ip unnumbered loopback interface configuration command.
Note
A loopback interface is a software-only interface that emulates an interface that is always up. It is a virtual interface that is supported on all platforms. The interface number is the number of the loopback interface that you want to create or configure. There is no limit to the number of loopback interfaces that you can create. A GGSN uses loopback interfaces to support the configuration of several different features.
To create a loopback interface, use the following commands in global configuration mode:
Creating a Virtual Template Interface for GGSN
Configure only a single virtual template interface (as virtual template number 1) with GTP encapsulation on a GGSN.
To create a virtual template interface for GGSN, use the following command, beginning in global configuration mode:
Enabling CEF Switching
CEF switching uses a forwarding information base (FIB) table and an adjacency table to accomplish packet switching. The adjacency table is indexed by Layer 3 network addresses and contains the corresponding Layer 2 information to forward a packet.
CEF switching eliminates the use of the route-cache table, and the overhead that is required in aging out its table entries and repopulating the table. The FIB table mirrors the entire contents of the IP routing table, which eliminates the need for a route-cache table.
For more information about switching paths, refer to the Cisco IOS Switching Services Configuration Guide, Release 12.2.
When you enable CEF switching globally on the GGSN, all interfaces on the GGSN are automatically enabled for CEF switching.
Note
Caution
Configuring the GGSN Compliance Baseline
The 3rd Generation Partnership Project (3GPP) compliance baseline for GGSN 5.0 is as follows:
•
•
•
By default, the 3GPP compliance baseline is TSG #18. However, it can be shifted to that of GGSN 4.0 (TSG #16) using the gprs compliance 3gpp ggsn r4.0 global configuration command.
To change the GGSN compliance baseline from TSG#18 to TSG#16, use the following command in global configuration mode:
Router(config)# gprs compliance 3gpp ggsn r4.0
Changes the GGSN compliance baseline from TSG#18 to TSG#16.
To return the compliance baseline to TSG#18, use the no form of this command.
To configure the GGSN to apply specification 29-060 CR 311 to Create PDP Context requests of existing GGSN 4.0 PDPs, use the following command in global configuration mode:
Router(config)# gprs gtp create-request v1 update-existing-pdp
Configures the GGSN to apply specification 29-060 CR 311 to Create PDP Context requests of existing GGSN 4.0 PDPs.
Configuring Echo Timing on a GGSN
GGSN uses echo timing to determine whether an SGSN or external charging gateway is active.
For a GTP path to be active, the SGSN needs to be active. To determine that an SGSN is active, the GGSN and SGSN exchange echo messages. Although the GGSN supports different methods of echo message timing, the basic echo flow begins when the GGSN sends an echo request message to the SGSN. The SGSN sends a corresponding echo response message back to the GGSN.
If the GGSN does not receive a response after a certain number of retries (a configurable value), the GGSN assumes that the SGSN is not active. This indicates a GTP path failure, and the GGSN clears all PDP context requests associated with that path.
This section describes the different methods of echo timing that are supported on the GGSN and how to configure them. It includes the following topics:
•
•
•
•
Overview of the Echo Timing on the GGSN
The GGSN supports two different means of echo timing—the default echo timer and the dynamic echo timer. Only a single timer can be in use at any time on the GGSN. The following sections describe these two timers:
•
•
Note
Overview of the Default Echo Timer
The default echo timer is enabled on the GGSN automatically. However, you can choose to enable the dynamic echo timing method as an alternative.
When you are using the default echo timer on the GGSN, the following commands apply:
•
•
•
Figure 3-1 shows the default echo request sequence when a response is successfully received within the specified path echo interval. If the GGSN receives the echo response within the path echo interval (as specified in the gprs gtp path-echo-interval command; the default is 60 seconds), it sends another echo request message after 60 seconds (or whatever time was configured in the gprs gtp path-echo-interval command). This message flow continues as long as the GGSN receives an echo response message from the SGSN within the specified path echo interval.
Figure 3-1 Default GTP Path Echo Interval Request Sequence in Path Success Mode
Figure 3-2 shows the default echo request sequence when the GGSN fails to receive a response to its echo request within the specified path echo interval. If the GGSN fails to receive an echo response message from the SGSN within the path echo interval, it resends echo request messages until the N3-requests counter is reached (as specified by the gprs gtp n3-requests command; the default is 5). Because the initial request message is included in the N3-requests counter, the total number of retries is N3 - 1. The T3 timer increases by a factor of 2 for each retry (the factor value is not configurable).
Figure 3-2 Default Echo Timing Request Sequence in Path Failure Mode
For example, if N3 is set to the default of 5, and T3 is set to the default of 1 second, the GGSN will resend 4 echo request messages (the initial request + 4 retries= 5). If the GGSN does not receive an echo response from the SGSN during the 60-second path echo interval, then the GGSN immediately sends the first echo request retry message upon expiration of the path echo interval. The T3 time increases for each additional echo request, by a factor of 2 seconds, as long as the GGSN does not receive an echo response. So, the GGSN resends another message in 2 seconds, 4 seconds, and 8 seconds. After the 5th message, the GGSN waits for a final period of 16 seconds for an echo response.
If the GGSN fails to receive an echo response message from the SGSN within the time period of the N3-requests counter, it deletes all of the PDP contexts and clears the GTP path. For this example, the total elapsed time from when the first request message is sent to when PDP contexts are cleared is
60 + 2 + 4 + 8 + 16 = 90 seconds
where 60 is the initial value of the path echo interval, and the remaining 4 time periods are the increments of the T3 timer for the subsequent retries. The path is cleared after another 60-second period, or 150 seconds.
If the GGSN receives an echo response within the N3 x T3 transmission period, it goes back to success mode for its echo request sequences.
Figure 3-3 shows the GGSN receiving an echo response message within N3 x T3 retransmissions of an echo request. In this scenario, the GGSN sent an initial echo request followed by 4 retries for a total of 5 requests, according to the default setting of 5 N3 requests. The GGSN receives the echo response after the 5th and final retry, within the remaining 16 seconds. Now the GGSN is back in success mode, and it waits 60 seconds (the value of the gprs gtp path-echo-interval command) before sending the next echo request message.
Figure 3-3 Default Echo Timing with Echo Response Received Within N3 x T3 Retransmissions
Overview of the Dynamic Echo Timer
Because the GGSN's default echo timer cannot be configured to accommodate network congestion, the GTP path could be cleared prematurely. The dynamic echo timer feature enables the GGSN to better manage the GTP path during periods of network congestion. Use the gprs gtp echo-timer dynamic enable command to enable the GGSN to perform dynamic echo timing.
The dynamic echo timer is different from the default echo timer because it uses a calculated round-trip time (RTT), as well as a configurable factor or multiplier to be applied to the RTT statistic. Different paths can each have a different RTT, so the dynamic echo timer can vary for different paths.
When you are using the dynamic echo timer on the GGSN, the following commands apply:
•
•
•
•
•
Figure 3-4 shows the dynamic echo request sequence when a response is successfully received within the specified path echo interval. Just as in the default echo timing method, if the GGSN receives the echo response within the path echo interval (as specified in the gprs gtp path-echo-interval command; the default is 60 seconds), it sends another echo request message after 60 seconds (or whatever time was configured in the gprs gtp path-echo-interval command). This message flow continues as long as the GGSN receives an echo response message from the SGSN within the specified path echo interval.
Figure 3-4 Dynamic GTP Path Echo Interval Request Sequence in Path Success Mode
The GGSN calculates the RTT statistic for use by the dynamic echo timer. The RTT is the amount of time between sending a particular echo request message and receiving the corresponding echo response message. RTT is calculated for the first echo response received (see Figure 3-5); the GGSN records this statistic. Because the RTT value might be a very small number, there is a minimum time for the dynamic echo timer to use. This value is configured using the gprs gtp echo-timer dynamic minimum command.
Figure 3-5 Dynamic Echo Timing Request Sequence RTT Calculation
Figure 3-6 shows the dynamic echo timing request sequence in path failure mode. If the GGSN fails to receive an echo response message from the SGSN within the path echo interval, it goes into retransmission, or path failure mode. During path failure mode, the GGSN uses a value referred to as the T-dynamic. The T-dynamic is the greater of either the dynamic minimum, or the RTT statistic multiplied by the smooth factor.
Figure 3-6 Dynamic Echo Timing Request Sequence in Path Failure Mode
The T-dynamic essentially replaces the use of the gprs gtp t3-response command, which is used in the default echo timer method on the GGSN. The T-dynamic timer increases by a factor of 2 for each retry (again, this factor is not configurable), until the N3-requests counter is reached (the N3-requests counter includes the initial request message).
For example, if the RTT is 6 seconds, the dynamic minimum is 5 seconds, N3 is set to 5, and the smooth factor is set to 3, then the GGSN will resend up to 4 echo request messages (initial request + 4 retries = 5) in path failure mode. If the GGSN does not receive an echo response from the SGSN during the 60-second path echo interval, then the GGSN immediately sends the first echo request retry message upon expiration of the path echo interval. The RTT x smooth factor equals 18 seconds (6 x 3), which is greater than the dynamic minimum of 5 seconds, so the dynamic minimum value is not used. The T-dynamic value is 18 (RTT x smooth factor), so the GGSN sends another retry echo request message in 36 seconds (18 x 2), 72 seconds (18 x 4), and 144 seconds (18 x 8). After the fifth message, the GGSN waits for a final period of 288 seconds (18 x 16) for an echo response.
If the GGSN fails to receive an echo response message from the SGSN in this time period, it clears the GTP path and deletes all PDP contexts. The total elapsed time, from when the first request message is sent, to when the PDP contexts are cleared, is
60 + 36 + 72 + 144 + 288 = 600 seconds
where 60 is the initial value of the path echo interval, and the remaining 4 time periods are the increments of the T-dynamic for the subsequent retries. The path is cleared after another 60-second period, or 660 seconds.
If the GGSN receives an echo response within the N3 x T-dynamic transmission period, it goes back to success mode for its echo request sequences. In success mode, the GGSN begins echo requests and awaits responses according to the specified path echo interval as shown in Figure 3-4.
Sequence Numbering for Retransmissions
The GGSN does not increment the sequence number of an echo request message during retransmissions. Therefore, during the period when an echo response has not been received by the GGSN, the GGSN continues to use the same sequence number for all echo request retries until the N3 requests limit has been reached, or until a response has been received. When a response is received, the sequence number of the next echo request message is incremented by 1.
If the GGSN has sent an echo request message with a higher sequence number, but still receives echo responses for sequence numbers lower than the current echo request message, the response is ignored.
Echo Timing Configuration Task List
This section describes the tasks required to customize the default echo timing method, or to enable and configure the dynamic echo timing method on the GGSN. By default, the GGSN activates the default echo timing method.
To configure echo timing on the GGSN, perform the following tasks:
•
•
•
Customizing the Default Echo Timer
The default echo timing method is enabled automatically on the GGSN. If you want to use the default echo timer, Cisco recommends that you modify the following commands to optimize your network as necessary.
To customize the default echo timing method on the GGSN, use the following commands beginning in global configuration mode:
Configuring the Dynamic Echo Timer
To activate the dynamic echo timing method on the GGSN, you must enable the dynamic echo timer. After you activate the dynamic echo timer, you can modify the corresponding options to optimize the timing parameters for your network.
To configure the dynamic echo timing method on the GGSN, use the following commands beginning in global configuration mode:
Disabling the Echo Timer
If for some reason you need to disable the GGSN from performing echo processing with an SGSN or external charging gateway, you can specify 0 seconds for the path echo interval.
To disable the echo timer, use the following command in global configuration mode:
Router(config)# gprs gtp path-echo-interval 0
(Optional) Specifies a path interval of 0 seconds, which disables the GGSN from performing echo processing.
Verifying the Echo Timing Configuration
This section describes how to verify the echo timing method on the GGSN. It includes the following topics:
•
•
Verifying Echo Timing Parameters
To verify the parameters in use by the GGSN for echo timing, you can use the show gprs gtp parameters or show running-config privileged EXEC command.
The GGSN automatically sets default values for the parameters applicable to the dynamic echo timer, even when the dynamic echo timer is not enabled. Therefore, the show gprs gtp parameters command does not indicate which echo timing method is currently activated.
Verifying Default Echo Timing Parameters
To verify the parameters in use by the default echo timer, use the show gprs gtp parameters privileged EXEC command, and observe the following parameters shown in bold text below:
GGSN# show gprs gtp parametersGTP path echo interval = 60GTP signal max wait time T3_response = 1GTP max retry N3_request = 5GTP dynamic echo-timer minimum = 5GTP dynamic echo-timer smooth factor = 2GTP buffer size for receiving N3_buffer = 8192GTP max pdp context = 45000Verifying Dynamic Echo Timing Parameters
To verify the parameters in use by the dynamic echo timer, use the show gprs gtp parameters privileged EXEC command, and observe the parameters shown in bold text below:
GGSN# show gprs gtp parametersGTP path echo interval = 60GTP signal max wait time T3_response = 1GTP max retry N3_request = 5GTP dynamic echo-timer minimum = 5GTP dynamic echo-timer smooth factor = 2GTP buffer size for receiving N3_buffer = 8192GTP max pdp context = 45000Verifying the Dynamic Echo Timer by GTP Path
You can use the show running-config privileged EXEC command to verify whether the dynamic echo timer is enabled.
The value of the dynamic echo timer varies for each GTP path on the GGSN. To verify whether the dynamic echo timer is enabled on the GGSN, and to verify the value (in seconds) of the dynamic echo timer (T-dynamic), use the show gprs gtp path privileged EXEC command.
If the dynamic echo timer is not activated, the word "Disabled" appears beside the corresponding path in the dynamic echo timer output field.
Step 1
GGSN# show running-configCurrent configuration : 6769 bytes!version 12.2no service padservice timestamps debug uptimeservice timestamps log uptimeno service password-encryptionservice internalservice gprs ggsn!ip cef!. . .!interface loopback 1ip address 10.41.41.1 255.255.255.0!!interface Virtual-Template1ip unnumber loopback 1encapsulation gtpgprs access-point-list gprs!. . .!gprs access-point-list gprsaccess-point 1access-point-name gprs.cisco.comexit!access-point 2access-point-name gprt.cisco.comaccess-mode non-transparentaaa-group authentication test2aaa-group accounting test2ip-address-pool dhcp-proxy-clientdhcp-server 10.65.0.1dhcp-gateway-address 10.65.0.1exit!!gprs ms-address exclude-range 10.21.1.0 10.21.1.5gprs gtp echo-timer dynamic enablegprs gtp echo-timer dynamic smooth-factor 5gprs gtp echo-timer dynamic minimum 10gprs gtp response-message wait-accounting!. . .!endStep 2
The following example indicates that the dynamic echo timer is enabled on the GGSN and that the T-dynamic values of 5 seconds and 2 seconds are in use for the corresponding paths:
GGSN# show gprs gtp path allTotal number of path : 2Local address Remote address GTP version Dynamic echo timer10.41.41.1(3386) 10.18.18.200(3386) 0 510.10.10.1(2123) 10.10.10.4(2123) 1 2
Customizing the GGSN Configuration
This section describes some of the options that you can configure on the GGSN to further customize the default configuration.
For information about configuring GPRS/UMTS charging options, see the "Customizing the Charging Gateway" section.
This section includes the following topics:
•
•
•
•
Configuring GTP Signaling Options
In addition to the commands used to configure the router or configure an instance of Cisco IOS software for GGSN support, the GGSN feature supports several optional commands that you can use to customize your GTP configuration.
For certain GTP processing options, the default values represent recommended values. Other optional commands also are set to default values, but Cisco recommends modifying these commands to optimize your network as necessary, or according to your hardware. This section describes some of the commands that you should consider using to optimize GTP signaling.
To optimize your GTP signaling configuration, use the following commands, beginning in global configuration mode:
Note
Configuring Other GTP Signaling Options
This section describes some other GTP signaling options that you can modify as needed to support your network needs.
To configure other GTP signaling options, use the following commands, beginning in global configuration mode:
Configuring the Maximum Number of PDP Contexts on the GGSN
The practical upper limit for the maximum number of PDP contexts supported on a GGSN depends on the memory and platform in use and on the GGSN configuration (for example, whether or not a method of PPP has been configured to forward packets beyond the terminal equipment and mobile termination, whether Dynamic Feedback Protocol [DFP] is being used or the memory protection feature is enabled, and the rate of PDP context creation to be supported).
Note
Cisco 7200 Series Router
The following list shows the maximum number of PDP contexts supported on the GGSN according to the memory and Cisco 7206 router series in use when a method of PPP has not been configured:
•
•
Catalyst 6500 Series Switch / Cisco 7600 Series Router
The Cisco MWAM can support up to 60,000 IP PDP contexts per GGSN instance, for a maximum of 300,000 IP PDP contexts per MWAM on which five GGSNs are configured.
Note
To configure the maximum number of PDP contexts on the GGSN, use the following command, beginning in global configuration mode:
Router(config)# gprs maximum-pdp-context-allowed pdp-contexts
Specifies the maximum number of PDP contexts (mobile sessions) that can be activated on the GGSN.
Configuring the Maximum Number of PDP Contexts When Using DFP with Load Balancing
If you use DFP with GPRS/UMTS load balancing, you must also specify a maximum number of PDP contexts for each GGSN. Do not accept the default value of 10000 PDP contexts; a value of 45000 is recommended. Significantly lower values can affect performance in a GPRS/UMTS load-balancing environment.
Note
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121limit/121e/121e9/index.htm
To configure the maximum number of PDP contexts on the GGSN for DFP, use the following command, beginning in global configuration mode:
Router(config)# gprs maximum-pdp-context-allowed 45000
Specifies 45000 as the maximum number of PDP contexts (mobile sessions) that can be activated on the GGSN.
Controlling Sessions on the GGSN
GPRS/UMTS provides always-on services for mobile users. Sessions can be established with the GGSN that provide network connectivity, even though no activity may be occurring over that session. After a PDP context is established on the GGSN, whether there is activity over the session or not, resources are being used by the GGSN. Therefore, you might want to control the amount of time that a session can remain established on the GGSN before the PDP context (or contexts) is cleared. The GGSN can support only a certain number of PDP contexts. The number of PDP contexts supported depends upon the configuration and memory resources of the platform.
This section describes how you can configure the session idle time and absolute session time on the GGSN to control when the GGSN deletes a session. The section includes the following topics:
•
•
•
•
•
Overview of the Session Idle Timer and the Absolute Session Timer on the GGSN
The GGSN allows you to control the clearing of PDP contexts by configuring durations for a session idle timer (RADIUS attribute 28) and an absolute session timer (RADIUS attribute 27). The session idle timer and absolute session timer specify the amount of time that the GGSN waits before purging a mobile session.
The duration specified for the session idle time is the same for all of the PDP contexts belonging to a session (a GTPv1 mobile session can have multiple PDP contexts), but an individual timer is started for each PDP context of that session. Therefore, the session idle timer is per-PDP, but the timer duration is per-session. The absolute session timer is session-based and controls the absolute duration of a session (active or inactive). When the absolute session timer is exceeded, the GGSN deletes all PDP contexts of the session (those with the same IMSI or MS address).
Note
When configured, a session idle timer is started on every PDP context. An absolute session timer is started on the session.
You can configure the timers globally on the GGSN for sessions occurring on all access points, and you can configure timers for a particular access point. In addition to the session idle timer and the absolute session timer that you can configure on the GGSN, RADIUS servers can also specify session timeout attributes.
The following list gives the order in which the GGSN implements the timers:
1.
2.
3.
In summary, the timeout values from the RADIUS server take precedence over the timer configurations on the GGSN, and the timers for a particular access point takes precedence over the globally configured timers.
The values for the gtp pdp-context timeout session and gtp pdp-context timeout idle commands override the values for the gprs gtp pdp-context timeout session or gprs gtp pdp-context timeout idle commands.
Note
Configuring the Session Idle Timer
GGSN supports the RADIUS Idle-Timeout (Attribute 28) field. The GGSN stores the attribute 28 value if it is present in the access request packets sent by the AAA server. When a PDP context is idle for an amount of time that exceeds the duration specified with this command, the GGSN terminates the context.
The duration specified for the timer applies to all PDP contexts of a session, however, a timer is started for each PDP context.
The session idle timer can be configured globally and at the APN. The values configured at the APN level override those configured globally.
Note
Configuring the Session Idle Timer Globally on the GGSN
To configure the amount of time that the GGSN allows a PDP context to remain idle on any access point before purging the context, use the following command, beginning in global configuration mode:
Note
Configuring the Session Idle Timer for an Access Point on the GGSN
To configure the amount of time that the GGSN allows a PDP context to remain idle for a particular access point before purging the context, use the following command, beginning in access-point configuration mode:
Note
Disabling the Session Idle Timer on the GGSN
By default, for all access points, the GGSN purges the idle PDP contexts of a session after 72 hours. If you want to allow PDP contexts to remain idle for an indefinite period of time, you can disable the timer for a particular user by configuring 0 as the session idle time duration in the user profile on the RADIUS server. If the user is not authenticated by RADIUS, the session idle timer cannot be disabled.
Configuring the Absolute Session Timer
GGSN supports the RADIUS Session-Timeout (Attribute 27) field. When you enable the absolute session timer, the GGSN stores the attribute 27 value if it is present in the access request packets sent by the AAA server. When the duration of a session exceeds the value specified with this command, the GGSN terminates all PDP contexts belonging to the session (those with the same IMSI or MS address).
The absolute session timer can be configured globally and at the APN. The values configured at the APN level override those configured globally.
By default, the absolute session timer is disabled.
Note
Configuring the Absolute Session Timer Globally on the GGSN
To configure the amount of time that the GGSN allows a session to exist for any access point before ending the session and purging all PDP contexts belonging to the session, use the following command, beginning in global configuration mode:
Configuring the Absolute Session Timer for an Access Point on the GGSN
To configure the amount of time that the GGSN allows a session to exist on a particular access point before ending the session and purging all PDP contexts belonging to the session, use the following command, beginning in access-point configuration mode:
Disabling the Absolute Session Timer on the GGSN
By default, the absolute session timer is disabled on the GGSN. To return to the default configuration after enabling the absolute session timer, use the no form of the global or access-point configuration commands (no gprs gtp pdp-context timeout session or no gtp pdp-context timeout session).
Verifying the Timer Configuration
To display timer information for a particular PDP context, you can use the show gprs gtp pdp-context command, using the tid or imsi keywords. The following example shows sample output for the show gprs gtp pdp-context tid command for a PDP context with an session idle timer set at the value of 200 hours (720000 seconds) and an absolute session timer set at 24 hours (86400 seconds). The timer values are displayed in the session timeout and idle timeout fields shown in bold:
router#show gprs gtp pdp-context tid 1111111111111111TID MS Addr Source SGSN Addr APN1111111111111111 10.1.1.1 Radius 10.8.8.1 dns.comcurrent time :Mar 18 2002 11:24:36user_name (IMSI):1111111111111111 MS address:10.1.1.1MS International PSTN/ISDN Number (MSISDN):ABCsgsn_addr_signal:10.8.8.1 sgsn_addr_data:10.8.0.1control teid local: 0x63493E0Ccontrol teid remove: 0x00000121data teid local: 0x63483E10data teid remote: 0x00000121primary pdp: Y nsapi: 0signal_sequence: 0 seq_tpdu_up: 0seq_tpdu_down: 0upstream_signal_flow: 1 upstream_data_flow: 2downstream_signal_flow:14 downstream_data_flow:12RAupdate_flow: 0pdp_create_time: Mar 18 2002 09:58:39last_access_time: Mar 18 2002 09:58:39mnrgflag: 0 tos mask map:00session timeout: 86400idle timeout: 720000gprs qos_req:091101 canonical Qos class(req.):01gprs qos_neg:25131F canonical Qos class(neg.):01effective bandwidth:0.0rcv_pkt_count: 0 rcv_byte_count: 0send_pkt_count: 0 send_byte_count: 0cef_up_pkt: 0 cef_up_byte: 0cef_down_pkt: 0 cef_down_byte: 0cef_drop: 0 out-sequence pkt: 0Src addr violation: 2 paks, 1024 bytesDest addr violation: 2 paks, 1024 bytesRedirected mobile-to-mobile traffic: 2 paks, 1024 bytescharging_id: 29160231visitor: No roamer: Nocharging characteristics: 0charging characteristics received: 0pdp reference count:2primary dns: 2.2.2.2secondary dns: 4.4.4.4primary nbns: 3.3.3.3secondary nbns: 5.5.5.5ntwk_init_pdp: 0Framed_route 5.5.5.0 mask 255.255.255.0** Network Init Information **MNRG Flag: 0 PDU Discard Flag: 0SGSN Addr: 172.16.44.1 NIP State: NIP_STATE_WAIT_PDP_ACTIVATIONBuf.Bytes: 500Configuring Flow Control for GTP Error Messages
GTP error indication messages are sent by the GGSN to the SGSN when the SGSN sends data for PDP context the GGSN cannot locate. The error indication message informs the SGSN that the PDP context cannot be located so that the SGSN can clean up the PDP context on its end.
By default, the GGSN disables flow control for GTP error messages.
You can enable flow control for transmission of GTP error messages by using the gprs gtp error-indication-throttle global configuration command. This command sets the initial value of a counter which is decremented each time an error indication message is sent. When the counter reaches zero, the GGSN stops transmitting error indication messages. The GGSN resets this counter to the configured throttle value after one second.
To configure flow control for GTP error messages, use the following command, beginning in global configuration mode:
Using the Service-Mode Function
The GGSN service-mode function enables you to make configuration changes and test calls without affecting all active sessions on a GGSN. You can configure the service-mode state globally, for an access-point, and for the GGSN charging function. There are two service-mode states: operational and maintenance. The default is operational mode.
Configuring Global Maintenance Mode
When a GGSN is placed in global maintenance mode, it rejects all new Create PDP Context requests. Therefore, no new PDP contexts are activated for an entire GGSN while it is in global maintenance mode.
The following sections provide examples of how to use global maintenance mode:
Adding a New GGSN
1.
Router(config)# service ggsnRouter(config)# gprs service-mode maintenance2.
3.
Router(config)# gprs service-mode operationalModifying a GGSN
1.
Router(config)# gprs service-mode maintenanceWait for existing PDPs for all APNs to be released normally (average session time is approximately 1 hour) and for buffered CDRs to be sent to the charging gateway. If it is not possible for CDRs to be sent to the CG because there is not an active charging gateway, manually clear the CDRs by placing the charging function in maintenance mode using the gprs charging service-mode command and issuing the clear gprs charging cdr all no-transfer command. For more information on placing the charging function in maintenance mode, see the "Configuring Charging Maintenance Mode" section.
2.
3.
Router(config)# gprs service-mode operationalDeactivating a GGSN
1.
Router(config)# gprs service-mode maintenanceWait for existing PDPs for all APNs to be released normally (average session time is approximately 1 hour) and for buffered CDRs to be sent to the charging gateway. If it is not possible for CDRs to be sent to the CG because there is not an active charging gateway, manually clear the CDRs by placing the charging function in maintenance mode using the gprs charging service-mode command and issuing the clear gprs charging cdr all no-transfer command. For more information on placing the charging function in maintenance mode, see the "Configuring Charging Maintenance Mode" section.
2.
Router(config)# no service gprs ggsnTo configure the global service-mode state of the GGSN, use the following global configuration command:
Router(config)# gprs service-mode [operational | maintenance]
Configures the global service-mode state. The default is operational.
Note
Configuring APN Maintenance Mode
Configure the APN service-mode state to add a new APN or modify an existing APN without affecting sessions for other APNs in the GGSN.
When an APN is in maintenance mode, it does not accept Create PDP Context requests. Once active PDP contexts are released (or manually cleared using the clear gprs gtp pdp-context access-point command), all APN-related parameters can be configured or modified and the APN set to operational mode.
Additionally, once you have added and configured an APN, you can verify the configuration using the gprs service-mode test imsi global configuration command to set up a test user (one per GGSN) and performing a PDP context creation.
Note
To delete an APN, change the APN service-mode state to maintenance, wait for all existing PDPs to be released, and then remove the APN using the no access-point-name command.
To configure the service-mode state of an APN, use the following access-point configuration command:
Router(config)# service-mode [operational | maintenance]
Configures service-mode state of an APN.
The following sections provide examples of how to use APN maintenance mode:
Adding a new APN
1.
Router(config-access-point)# access-point-name apn-numRouter(config-access-point)# service-mode maintenance2.
3.
Router(config)# gprs service-mode test imsi imsi-value4.
Router(config-access-point)# service-mode operationalModifying an APN
1.
Router(config-access-point)# service-mode maintenanceWait for PDP contexts to be released or manually clear using the gprs pdp-contexts access-point command.
2.
3.
Router(config)# gprs service-mode test imsi imsi-value4.
Router(config-access-point)# service-mode operationalDeleting an APN:
1.
Router(config-access-point)# service-mode maintenanceWait for PDP contexts to be released or manually clear them using the gprs pdp-contexts access-point command.
2.
Router(config-access-point)# no access-point-name apn-numConfiguring Charging Maintenance Mode
The charging function of a GGSN primarily consists of collecting CDRs and transmitting CDRs to charging gateways. The service mode state of the GGSN charging function does not impact the collection of CDRs. However, when the charging function is placed in maintenance service-mode state, CDRs are not transmitted to the charging gateway (CG).
When the charging function is in maintenance mode, you can add, delete, or modify CGs (for example, change the IP address of the CGs, their priority, and number). If a new primary charging gateway is configured while the charging function is in maintenance mode, when the charging function of the GGSN is placed back in operational mode, all accumulated CDRs are sent to the new CG.
When in maintenance mode, all collected CDRs, and those in the pending queue, are stored on the GGSN. If desired, these stored CDRs can be cleared using the clear gprs charging cdr all no-transfer command. When cleared, they will not be transmitted to the CG when the charging function is returned to operational mode.
The following charging function configuration commands require the charging function to be in maintenance mode:
•
•
•
•
•
•
•
•
By default the charging function is in operational mode. To configure the service-mode state of the charging function, use the following global configuration command:
Router(config)# gprs charging service-mode [operational | maintenance]
Configures the service-mode state of a GGSN's charging function.
The following section provide example of how to use charging maintenance mode:
Modifying a Charging Gateway
1.
Router(config)# gprs charging service-mode maintenanceCDRs are collected but not transmitted. All collected and buffered CDRs are stored until the charging function is returned to operational mode. At that time, they are sent to the CG.
2.
3.
Router(config)# clear gprs charging cdr all no-transfer4.
Router(config)# gprs charging service-mode operationalTo manually clear all CDRs stored on the GGSN, including those in the pending queue, use the following global configuration command:
Router(config)# clear gprs charging cdr all no-transfer
Clears stored CDRs, including those in the pending queue, when a the charging function is in maintenance mode.
Note
Note
Monitoring and Maintaining GTP on the GGSN
This section provides a summary list of the show commands that you can use to monitor GTP on the GGSN.
The following privileged EXEC commands are used to monitor and maintain GTP on the GGSN:
Configuration Examples
This section includes the following examples:
•
GGSN Configuration Example
The following example shows part of a sample GGSN configuration with some of the commands that you use to configure basic GGSN GTP services:
GGSN# show running-configCurrent configuration : 3521 bytes!version 12.2no service single-slot-reload-enableservice timestamps debug uptimeservice timestamps log uptimeno service password-encryption!! Enables GGSN services!service gprs ggsn!ip cef!! Configures a loopback interface!interface loopback 1ip address 10.40.40.3 255.255.255.0!! Defines the virtual-template interface! with GTP encapsulation!interface Virtual-Template1ip unnumber loopback 1encapsulation gtpgprs access-point-list gprs!. . .!gprs access-point-list gprs!access-point 1access-point-name gprs.cisco.comexit!access-point 2access-point-name gprt.cisco.comexit!access-point 3access-point-name gpru.cisco.comaccess-mode non-transparentaaa-group authentication fooexit!! Configures GTP parameters!gprs maximum-pdp-context-allowed 90000gprs gtp path-echo-interval 0gprs default charging-gateway 10.15.15.1!! Enables the memory protection feature to become active if the memory threshold falls ! below 50 MB!gprs memory threshold 512!. . .. . .!endDynamic Echo Timer Configuration Example
The following example shows part of a sample GGSN configuration for the dynamic echo timer. In this example, the dynamic echo timer is enabled, the smooth factor is changed from the default value of 2 to the value 5, and the dynamic minimum value is changed from the default value of 5 seconds to the value 10 seconds:
GGSN# show running-configCurrent configuration : 6769 bytes!version 12.2no service padservice timestamps debug uptimeservice timestamps log uptimeno service password-encryptionservice internalservice gprs ggsn!ip cef!. . .!interface loopback 1ip address 10.41.41.1 255.255.255.0!interface Virtual-Template1ip unnumber loopback 1encapsulation gtpgprs access-point-list gprs!. . .!gprs access-point-list gprsaccess-point 1access-point-name gprs.cisco.comexit!access-point 2access-point-name gprt.cisco.comaccess-mode non-transparentaaa-group authentication test2aaa-group accounting test2ip-address-pool dhcp-proxy-clientdhcp-server 10.65.0.1dhcp-gateway-address 10.65.0.1exit!! Enables the dynamic echo timer!gprs gtp echo-timer dynamic enable!! Configures a smooth factor of 5!gprs gtp echo-timer dynamic smooth-factor 5!! Configures the dynamic minimum as 10 seconds!gprs gtp echo-timer dynamic minimum 10gprs gtp response-message wait-accounting!end
Feedback