|
|
Table Of Contents
gprs gtp echo-timer dynamic enable
gprs gtp echo-timer dynamic minimum
gprs gtp echo-timer dynamic smooth-factor
gprs gtp error-indication throttle
gprs gtp ip udp ignore checksum
gprs gtp ppp-regeneration vtemplate
gprs gtp response-message pco ipcp nack
gprs gtp response-message wait-accounting
gprs gtp-director retry-timeout
gprs idle-pdp-context purge-timer
gprs maximum-pdp-context-allowed
gprs qos default-response requested
gprs radius attribute chap-challenge
gprs umts-qos map diffserv-phb
gprs umts-qos map traffic-class
gtp response-message wait-accounting
ip mobile foreign-agent skip-aaa-reauthentication
ip mobile registration-lifetime
ip rtp compression-connections
radius attribute suppress imsi
radius attribute suppress sgsn-address
gprs gtp echo-timer dynamic enable
To enable the dynamic echo timer on the GGSN, use the gprs gtp echo-timer dynamic enable global configuration command. To disable the dynamic echo timer, use the no form of this command.
gprs gtp echo-timer dynamic enable
no gprs gtp echo-timer dynamic enable
Syntax Description
This command has no arguments or keywords.
Defaults
Disabled
Command Modes
Global configuration
Command History
Usage Guidelines
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.
The GGSN supports two different methods of echo timing—the default echo timer and the dynamic echo timer.
The GGSN's default echo timer can not be configured to accommodate network congestion and therefore 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.
Default echo timer
The dynamic echo timer is based on the default echo timer in the GGSN. A description of the default echo timer follows as a means of comparison.
The default echo timer configuration uses the following commands:
•
gprs gtp n3-requests—Specifies maximum number of times that the GGSN attempts to send a echo-request message. The default is 5 times.
•
•
If the GGSN receives the echo response within the path echo interval (as specified in the gprs gtp path-echo-interval command; 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.
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; 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 two for each retry (the factor value is not configurable).
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). The T3 time increments for each additional echo request, by a factor of 2 seconds. So, the GGSN resends a message in 2 seconds, 4 seconds, 8 seconds, and 16 seconds. If the GGSN fails to receive an echo response message from the SGSN within the time period of the N3-requests counter, it clears the GTP path and deletes all of the PDP contexts.
For the above example, the total elapsed time from when the first request message is sent, to when the GTP path is 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.
Dynamic echo timer
The dynamic echo timer method is different from the default echo timer method on the GGSN because it uses a calculated round-trip timer (RTT), as well as a configurable factor or multiplier to be applied to the RTT statistic.
The dynamic echo timer configuration uses the following commands:
•
•
•
•
•
The GGSN calculates the RTT statistic for use by the dynamic echo timer feature. 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; 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.
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.
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 two for each retry (again, this factor is not configurable), until the N3-requests counter is reached (N3-requests counter includes the initial request message).
For example, if the RTT is 6 seconds, N3 is set to 5, and the smooth factor is set to 3, the GGSN will resend 4 echo request messages in path failure mode. The T-dynamic value is 18 (RTT x smooth factor), so the GGSN sends a retry echo request message in 36 seconds, 72 seconds, 144 seconds, and 288 seconds. 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 GTP path is 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.
Examples
The following example turns on the dynamic echo timer, sets the minimum value to 5 seconds, and configures a smooth factor of 3:
gprs gtp echo-timer dynamic enablegprs gtp echo-timer dynamic minimum 5gprs gtp echo-timer dynamic smooth-factor 3Related Commands
gprs gtp echo-timer dynamic minimum
To specify the minimum time period used by the dynamic echo timer, use the gprs gtp echo-timer dynamic minimum global configuration command. To return to the default value, use the no form of this command.
gprs gtp echo-timer dynamic minimum number
no gprs gtp echo-timer dynamic minimum number
Syntax Description
number
Minimum time period (between 1 and 60 seconds) of the dynamic echo timer. Value must be an integer. The default value is 5 seconds.
Defaults
5 seconds
Command Modes
Global configuration
Command History
Usage Guidelines
Use this command to specify the minimum time period (in seconds) used by the dynamic echo timer, also referred to as the T-dynamic. If the GGSN's current calculation of the round-trip timer (RTT) statistic, multiplied by the smooth factor, is less than the configured dynamic minimum value, then the GGSN uses the configured minimum as the T-dynamic.
The GGSN calculates the RTT statistic for use by the dynamic echo timer feature. 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; 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.
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.
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 two for each retry (again, this factor is not configurable), until the N3-requests counter is reached (N3-requests counter includes the initial request message).
Note
Examples
The following example turns on the dynamic echo timer, sets the minimum value to 6 seconds, and configures a smooth factor of 2:
gprs gtp echo-timer dynamic enablegprs gtp echo-timer dynamic minimum 6gprs gtp echo-timer dynamic smooth-factor 2Related Commands
gprs gtp echo-timer dynamic smooth-factor
To configure the multiplier that the GGSN uses to calculate the time to wait to send retries of the dynamic echo timer, use the gprs gtp echo-timer dynamic smooth-factor global configuration command. To return to the default value, use the no form of this command.
gprs gtp echo-timer dynamic smooth-factor number
no gprs gtp echo-timer dynamic smooth-factor number
Syntax Description
number
Integer (between 1 and 100) used by the GGSN as a multiplier for the RTT statistic, to calculate the T-dynamic. The default is 2.
Defaults
2
Command Modes
Global configuration
Command History
Usage Guidelines
The dynamic echo timer uses the smooth factor to calculate what is known as the T-dynamic. The T-dynamic is calculated by multiplying the RTT (or the value configured in the gprs gtp echo-timer dynamic minimum, whichever is greater) times the smooth-factor.
Note
Examples
The following example turns on the dynamic echo timer, sets the minimum value to 1 second, and configures a smooth factor of 2:
gprs gtp echo-timer dynamic enablegprs gtp echo-timer dynamic minimum 1gprs gtp echo-timer dynamic smooth-factor 2Related Commands
gprs gtp error-indication throttle
To specify the maximum number of error indication messages that the GGSN sends out in one second, use the gprs gtp error-indication throttle command. To disable the GGSN from sending error indication messages, use the no form of this command.
gprs gtp error-indication throttle window-size size
no gprs gtp error-indication throttle
Syntax Description
size
Integer (between 0 and 256) that specifies the maximum number of error indication messages that the GGSN sends in one second.
Defaults
Disabled
Command Modes
Global configuration
Command History
Usage Guidelines
Use the gprs gtp error-indication throttle command to specify the maximum number of error indication messages that are sent by the GGSN in one second. This provides a way to implement flow control for transmission of GTP error messages. The GGSN maintains a counter that decrements each time that an error indication message is sent. The GGSN resets this counter to the configured throttle value after one second.
If you do not issue the command, error indication throttling is not enabled. To restore the default value (error indication throttling is disabled) use the no form of this command.
Examples
The following example shows a throttle value of 150:
gprs gtp error-indication throttle window-size 150gprs gtp ip udp ignore checksum
To disable verification of the user datagram protocol (UDP) checksum to support CEF switching on the GGSN, use the gprs gtp ip udp ignore checksum global configuration command. To enable UDP checksum verification on the GGSN, use the no form of this command.
gprs gtp ip udp ignore checksum
no gprs gtp ip udp ignore checksum
Syntax Description
This command has no arguments or keywords.
Defaults
UDP checksum verification is enabled on the GGSN.
Command Modes
Global configuration
Command History
Usage Guidelines
UDP checksum verification can prohibit operation of CEF switching processing on the GGSN if the checksum should have a non-zero result. Therefore, if you want to enable CEF switching on the GGSN, you should configure the gprs gtp ip udp ignore checksum command.
If UDP checksum verification remains enabled on the GGSN and a non-zero result occurs, the GTP T-PDUs will be process switched, even if you have configured the GGSN for CEF switching.
The gprs gtp ip udp ignore checksum command does not apply if you are only using process switching on the GGSN.
For more information about switching processes on the router, refer to the Cisco IOS Switching Services Configuration Guide.
Examples
The following example disables UDP checksum verification on the GGSN:
gprs gtp ip udp ignore checksumRelated Commands
gprs gtp map signalling tos
To specify an IP ToS mapping for GPRS tunneling protocol (GTP) signaling packets, use the gprs gtp map signalling tos global configuration command. To return to the default value, use the no form of this command.
gprs gtp map signalling tos tos-value
no gprs gtp map signalling tos tos-value
Syntax Description
Defaults
ToS value 5
Command Modes
Global configuration
Command History
Usage Guidelines
Use the gprs gtp map signalling tos command to specify the IP ToS mapping for GTP signaling packets transmitted by the GGSN. The higher the value, the higher the class of service provided to the packets.
Examples
The following example specifies a IP ToS mapping value of 3:
gprs gtp map signalling tos 3Related Commands
gprs gtp n3-buffer-size
To specify the size of the receive buffer that the GGSN uses to receive GTP signaling messages and packets sent through the tunneling protocol, use the gprs gtp n3-buffer-size global configuration command. To return to the default value, use the no form of this command.
gprs gtp n3-buffer-size bytes
no gprs gtp n3-buffer-size
Syntax Description
bytes
Number of bytes (between 2048 and 65535) that specifies the size of the N3 buffer. The default is 8192 bytes.
Defaults
8192 bytes
Command Modes
Global configuration
Command History
Usage Guidelines
Use the gprs gtp n3-buffer-size command to specify the size of the GTP N3 buffer on the GGSN. The N3 buffer is a receive buffer that the GGSN uses to receive GTP signaling messages and packets sent through the tunneling protocol. The recommended value for the N3 buffer size is 8192 (the default size).
Examples
The following example specifies a buffer size of 2084 bytes:
gprs gtp n3-buffer-size 2048gprs gtp n3-requests
To specify the maximum number of times that the GGSN attempts to send a signaling request to an SGSN, use the gprs gtp n3-requests global configuration command. To return to the default value, use the no form of this command.
gprs gtp n3-requests requests
no gprs gtp n3-requests requests
Syntax Description
requests
A number between 1 and 65535 that specifies the number of times a request is attempted. The default is 5 requests.
Defaults
5 requests
Command Modes
Global configuration
Command History
Usage Guidelines
The value of the gprs gtp n3-requests command is used for all signaling requests on the GGSN.
The GGSN supports two different methods of echo timing—the default echo timer and the dynamic echo timer. The gprs gtp n3-requests command is used by the GGSN to perform either type of echo processing.
Examples
The following example shows the GGSN attempting to send a signaling request 3 times:gprs gtp n3-requests 3Related Commands
gprs gtp path-echo-interval
To specify the number of seconds that the GGSN waits before sending an echo-request message to the SGSN, use the gprs gtp path-echo-interval global configuration command. To return to the default value, use the no form of this command.
gprs gtp path-echo-interval interval
no gprs gtp path-echo-interval interval
Syntax Description
Defaults
60 seconds
Command Modes
Global configuration mode
Command History
Usage Guidelines
The GGSN supports two different methods of echo timing—the default echo timer and the dynamic echo timer. The gprs gtp path-echo-interval command is used on the GGSN to perform either type of echo processing.
Use the gprs gtp path-echo-interval command to specify the interval that the GGSN waits before sending an echo-request message to the SGSN to check for GTP path failure.
Note
Examples
The following example shows the GGSN waiting 90 seconds before sending an echo-request message:
gprs gtp path echo-interval 90Related Commands
gprs gtp ppp vtemplate
To associate the virtual template interface that defines the PPP characteristics with support for the PPP PDP type over GTP on the GGSN, use the gprs gtp ppp vtemplate global configuration command. To remove specification of the PPP virtual template interface for GTP on the GGSN, use the no form of this command.
gprs gtp ppp vtemplate number
no gprs gtp ppp vtemplate number
Syntax Description
Defaults
No default behavior or values.
Command Modes
Global configuration
Command History
Usage Guidelines
Before you configure the gprs gtp ppp vtemplate command, you must configure the virtual template interface with the necessary PPP characteristics. The number that you configure for the virtual template interface that defines the PPP characteristics, must correspond to the number that you specify in the gprs gtp ppp vtemplate command.
Examples
The following example configures two virtual template interfaces on the GGSN, one for GTP encapsulation and one for PPP, and specifies the PPP virtual template interface for GTP on the GGSN.
Note
The first section of commands configures the GPRS virtual template interface for GTP:
interface Virtual-Template 1ip address 10.1.1.1 255.0.0.0no ip directed-broadcastencapsulation gtpno ip route-cachegprs access-point-list gprsThe following example configures a virtual template interface for PPP and associates the virtual template for support of the PPP PDP type over GTP on the GGSN:
interface Virtual-Template 2ip unnumbered FastEthernet 1/0no ip directed-broadcastno peer default ip addressppp authentication chapppp timeout retry 30gprs gtp ppp vtemplate 2Related Commands
interface virtual-template
Creates a virtual template interface that can be configured and applied dynamically in creating virtual access interfaces.
gprs gtp ppp-regeneration vtemplate
To associate the virtual template interface that is configured for PPP encapsulation with support for regenerated PPP sessions on the GGSN, use the gprs gtp ppp-regeneration vtemplate global configuration command. To remove specification of the PPP virtual template interface for regenerated PPP sessions on the GGSN, use the no form of this command.
gprs gtp ppp-regeneration vtemplate number
no gprs gtp ppp-regeneration vtemplate number
Syntax Description
Defaults
No default behavior or values.
Command Modes
Global configuration
Command History
Usage Guidelines
Before you configure the gprs gtp ppp-regeneration vtemplate command, you must configure the virtual template interface for PPP encapsulation using the encapsulation ppp command. In addition, you must also configure the ip address negotiated command and the no peer neighbor-route command at the virtual template interface for PPP encapsulation.
The number that you configure for the virtual template interface to support PPP encapsulation, must correspond to the number that you specify in the gprs gtp ppp-regeneration vtemplate command.
Examples
The following example configures two virtual template interfaces on the GGSN, one for GTP encapsulation for communication between the GGSN and the SGSN, and one for PPP regeneration. The virtual template interface for PPP regeneration supports the creation of PPP sessions from the GGSN over Layer 2 Tunneling Protocol (L2TP) tunnels to an L2TP network server (LNS).
Note
The first section of commands configures the GPRS virtual template interface for GTP:
interface Virtual-Template 1ip address 10.1.1.1 255.0.0.0no ip directed-broadcastencapsulation gtpno ip route-cachegprs access-point-list gprsThe following example configures a virtual template interface for PPP regeneration:
interface Virtual-Template 11ip address negotiatedno peer neighbor-routeencapsulation pppThe following example specifies virtual template interface 11 for PPP regeneration on the GGSN:
gprs gtp ppp-regeneration vtemplate 11Related Commands
interface virtual-template
Creates a virtual template interface that can be configured and applied dynamically in creating virtual access interfaces.
gprs gtp response-message pco ipcp nack
To configure the GGSN to return an IPCP Conf-Nack (Code 03) in the GTP protocol configuration option (PCO) information element (IE) of a create PDP context response when returning IP Control Protocol (IPCP) options for which the granted values (non-zero) differ from those requested (IPCP Conf-Reject [Code 04] for those options for which the returned address values are zero), use the gprs gtp response-message pco ipcp nack global configuration command. To return to the default, use the no form of the command.
gprs gtp response-message pco ipcp nack
no gprs gtp response-message pco ipcp nack
Syntax Description
This command has no arguments or keywords.
Defaults
The GGSN sends an IPCP Conf-Ack (Code 2) in the PCO IE of the create PDP context response for the IPCP options for all the requested IPCP address options supported by the GGSN. The values being returned might be the same as or differ from those requested, or be zero.
For unsupported options, an IPCP Conf-Reject is returned.
Command Modes
Global configuration
Command History
12.3(2)XB1
This command was introduced.
12.3(8)T
This command was incorporated in Cisco IOS Release 12.3(8)T.
Usage Guidelines
Use the gprs gtp response-message pco ipcp nack command to configure the GGSN to return an IPCP Conf-Nack in the PCO IE of a create PDP context response when returning IPCP options for which the granted values differ from those requested.
When the gprs gtp response-message pco ipcp nack command is configured, and the PCO IE of the create PDP context request contains IPCP options, the PCO IE in the create PDP response includes the following, depending on the whether options are supported by (and values are acceptible to) the GGSN:
•
•
•
gprs gtp response-message wait-accounting
To configure the GGSN to wait for a RADIUS accounting response before sending a create PDP context response to the SGSN, for create PDP context requests received across all access points, use the gprs gtp response-message wait-accounting global configuration command. To configure the GGSN to send a create PDP context response to the SGSN after sending a RADIUS start accounting message to the RADIUS server (without waiting for a response from the RADIUS accounting server), use the no form of this command.
gprs gtp response-message wait-accounting
no gprs gtp response-message wait-accounting
Syntax Description
This command has no arguments or keywords.
Defaults
The GGSN sends a create PDP context response to the SGSN after sending a RADIUS start accounting message to the RADIUS accounting server. The GGSN does not wait for a RADIUS accounting response from the RADIUS accounting server.
Command Modes
Global configuration
Command History
Usage Guidelines
Use the gprs gtp response-message wait-accounting command to configure the GGSN to wait for a RADIUS accounting response from the RADIUS accounting server, before sending a create PDP context response to the SGSN, for create PDP context requests received across all access points.
If the GGSN does not receive a response from the RADIUS accounting server when you have configured the gprs gtp response-message wait-accounting command, then the GGSN rejects the PDP context request.
The GGSN supports configuration of RADIUS response message waiting at both the global and access-point configuration levels. You can minimize your configuration by specifying the configuration that you want to support across most APNs, at the global configuration level. Then, at the access-point configuration level, you can selectively modify the behavior that you want to support at a particular APN. Therefore, at the APN configuration level, you can override the global configuration of RADIUS response message waiting.
To configure the GGSN to wait for a RADIUS accounting response as the default behavior for all APNs, use the gprs gtp response-message wait-accounting global configuration command. To disable this behavior for a particular APN, use the no response-message wait-accounting access-point configuration command.
To verify whether RADIUS response message waiting is enabled or disabled at an APN, you can use the show gprs access-point command and observe the value reported in the wait_accounting output field.
Examples
The following example globally configures the GGSN to wait for a RADIUS accounting response from the RADIUS accounting server before sending an activate PDP context response to the SGSN, for PDP context requests received across all access points except access-point 1. RADIUS response message waiting has been overridden at access-point 1 using the no gtp response-message wait-accounting command:
Note
aaa new-model!aaa group server radius fooserver 10.2.3.4server 10.6.7.8!aaa authentication ppp foo group fooaaa authorization network default group radiusaaa accounting exec default start-stop group foo!gprs access-point-list gprsaccess-point 1access-mode non-transparentaccess-point-name www.pdn1.comaaa-group authentication foono gtp response-message wait-accountingexitaccess-point 2access-mode non-transparentaccess-point-name www.pdn2.comaaa-group authentication foo!gprs gtp response-message wait-accounting!radius-server host 10.2.3.4 auth-port 1645 acct-port 1646 non-standardradius-server host 10.6.7.8 auth-port 1645 acct-port 1646 non-standardradius-server key ggsntelRelated Commands
gprs gtp t3-response
To specify the initial time that the GGSN waits before resending a signaling request message when a response to a request has not been received, use the gprs gtp t3-response global configuration command. To return to the default value, use the no form of this command.
gprs gtp t3-response response-interval
no gprs gtp t3-response response-interval
Syntax Description
response-interval
A value between 1 and 65535 that specifies the length of the T3 response interval, in seconds. The default is 1 second.
Defaults
1 second
Command Modes
Global configuration
Command History
Usage Guidelines
The gprs gtp t3-response command is used by the GGSN to process delete PDP context requests and to perform the default method of echo timing.
For delete PDP context requests, the gprs gtp t3-response command is used by the GGSN to specify how long the GGSN waits before sending a retry of the delete PDP context request when a response is not received from the SGSN, until the gprs gtp n3-requests limit is reached.
The GGSN supports two echo timer implementations—the default echo timer and the dynamic echo timer. The gprs gtp t3-response command also is used on the GGSN to perform the default type of echo processing, when the dynamic echo timer is not enabled.
If the GGSN receives the echo response within the path echo interval (as specified in the gprs gtp path-echo-interval command; 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.
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; 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 two for each retry (the factor value is not configurable).
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). The T3 time increments for each additional echo request, by a factor of 2 seconds. So, the GGSN resends a message in 2 seconds, 4 seconds, 8 seconds, and 16 seconds. If the GGSN fails to receive an echo response message from the SGSN within the time period of the N3-requests counter, it clears the GTP path and deletes all of the PDP contexts.
For the above example, the total elapsed time from when the first request message is sent, to when the GTP path is 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.
Examples
The following example shows a T3 interval response interval of 524 seconds:
gprs gtp t3-response 524Related Commands
gprs gtp-director retry-timeout
To specify the amount of time during which GDM forwards all retries of create PDP context requests for a specific TID from an SGSN to the same GGSN, use the gprs gtp-director retry-timeout global configuration command. To return to the default value, use the no form of this command.
gprs gtp-director retry-timeout seconds
no gprs gtp-director retry-timeout seconds
Syntax Description
seconds
Number of seconds (between 1 and 65535) during which GDM forwards retries for a specific TID to the same GGSN. The default is 30 seconds.
Defaults
30 seconds
Command Modes
Global configuration
Command History
Usage Guidelines
Use the gprs gtp-director retry-timeout command only when configuring the GTP Director Module (GDM). Do not configure this command on a GGSN.
Use the gprs gtp-director retry-timeout command to specify how long GDM forwards all retries of create PDP context requests for a specific TID from an SGSN to the same GGSN. The retry-timeout value represents the maximum period of time during which GDM expects the real GGSN to establish or reject the PDP context request.
It is recommended that the retry-timeout value be specified according to the following formula:
,
where
•
•
•
•
Note
Examples
The following example configures GDM to forward all retries of create PDP context requests for a specific TID to the same GGSN for 1 minute:
gprs gtp-director retry-timeout 60Related Commands
gprs idle-pdp-context purge-timer
To specify the time that the GGSN waits before purging idle mobile sessions, use the gprs idle-pdp-context purge-timer global configuration command. To return to the default value, use the no form of this command.
gprs idle-pdp-context purge-timer hours
no gprs idle-pdp-context purge-timer hours
Syntax Description
hours
Value between 0 and 255 that specifies the number of hours that the GGSN waits before purging idle sessions. The value 0 disables the purge timer. The default is 72 hours.
Defaults
72 hours
Command Modes
Global configuration
Command History
Usage Guidelines
To specify the time that the GGSN waits before purging idle mobile sessions, use the gprs idle-pdp-context purge-timer command. To disable this feature, specify a purge-timer value of 0.
You can override the value of the global purge timer using the session idle-time access-point configuration command.
Examples
The following example specifies that the GGSN wait for 60 hours before purging idle sessions:
gprs idle-pdp-context purge-timer 60Related Commands
Specifies the time that the GGSN waits before purging idle mobile sessions for the current access point.
gprs maximum-pdp-context-allowed
To specify the maximum number of PDP contexts (mobile sessions) that can be activated on the GGSN, use the gprs maximum-pdp-context-allowed global configuration command. To return to the default value, use the no form of this command.
gprs maximum-pdp-context-allowed pdp-contexts
no gprs maximum-pdp-context-allowed pdp-contexts
Syntax Description
pdp-contexts
Integer between 1 and 4294967295 that specifies the number of active PDP contexts allowed. The default is 10000 PDP contexts.
Defaults
10000 PDP contexts
Command Modes
Global configuration
Command History
Usage Guidelines
Use the gprs maximum-pdp-context-allowed command to specify the maximum number of PDP contexts allowed on the GGSN. When the maximum allowable number of PDP contexts is reached, the GGSN refuses new PDP contexts (mobile sessions) until sessions are available.
Note
If you use DFP with GPRS load balancing, you must also specify a maximum number of PDP contexts for each GGSN, using the gprs maximum-pdp-context-allowed command. Do not accept the default value of 10000 PDP contexts. A value of 45000 is recommended. Significantly lower values can impact performance in a GPRS load-balancing environment.
Note
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121limit/121e/121e9/index.htmExamples
In the following example 15000 PDP contexts are allowed on the GGSN:
gprs maximum-pdp-context-allowed 15000Related Commands
gprs mcc mnc
To configure the mobile country code and mobile network node that the GGSN uses to determine whether a create PDP context request is from a roamer, use the gprs mcc mnc global configuration command. To return to the default values, use the no form of this command.
gprs mcc mcc-num mnc mnc-num
no gprs mcc mcc-num mnc mnc-num
Syntax Description
Defaults
000—For both the MCC and MNC. A valid code must be a non-zero value.
Command Modes
Global configuration
Command History
Usage Guidelines
Use the gprs mcc mnc command as part of the configuration required on the GGSN to support creation of CDRs for roaming mobile subscribers, or to block roamers from being able to create PDP context requests.
The GGSN uses the values that you configure in this command to compare with the tunnel ID (TID) in a create PDP context request.
The GGSN automatically specifies values of 000 for the MCC and MNC. However, you must configure non-zero values for both the MCC and MNC before you can enable the GGSN to create charging CDRs for roamers.
To properly issue the gprs mcc mnc command, you must specify both the mcc keyword with its argument and the mnc keyword with its argument. You cannot issue the command without specifying both keywords.
It is important that you configure the gprs mcc mnc and gprs charging roamers commands in their proper order. After you configure the MCC and MNC values, use the gprs charging roamers command to enable charging for roamers on the GGSN. You can change the MCC and MNC values by reissuing the gprs mcc mnc command.
To verify your configuration of these codes on the GGSN, use the show gprs charging parameters command.
Note
Examples
The following example replaces the default values of 000 on the GGSN, and specifies an MCC code of 310 for the USA and an MNC code of 15 for the Bell South service provider:
gprs mcc 310 mnc 15Related Commands
Restricts GPRS access based on the mobile user's home PLMN.
Enables charging for roamers on the GGSN.
Displays information about the current GPRS charging configuration.
gprs memory threshold
To prevent the GGSN from draining processory memory during abnormal conditions (such as charging gateways [CGs] being down), use the gprs memory threshold global configuration command. To disable the memory protection feature, issue the no version of the command.
gprs memory threshold threshold
Syntax Description
threshold
Memory threshold, that when fallen below enables the memory protection feature on the GGSN. Valid range is 0 to 1024.
Defaults
The default is 0. The recommended value is 512 (approximately 50 MB).
Command Modes
Global configuration
Command History
12.3(2)XB
This command was introduced.
12.3(8)T
This command was incorporated in Cisco IOS Release 12.3(8)T.
Usage Guidelines
To prevent the processor memory from being completely drained during periods of abnormal conditions (for example, all CGs are down), you must configure the memory protection feature on the GGSN using the gprs memory threshold global configuration command.
When the memory protection feature is configured and the amount of memory remaining on the system reaches the defined threshold, the GGSN performs the following actions in an attempt to keep the processory memory from falling below the threshold:
•
•
•
Byte counts will be maintained and reported after the GGSN recovers. However, because some change conditions are not handled, some counts will not reflect the accurate charging condition, for example, QoS and tariff.
The memory protection feature is required and must be configured according to the router and memory size.
Examples
The following example sets the memory threshold to 50 KB:
gprs memory threshold 512gprs ms-address exclude-range
To specify the IP address range(s) used by the GPRS network, and thereby excluded from the mobile station (MS) IP address range, use the gprs ms-address exclude-range global configuration command. To remove the specified range(s), use the no form of this command.
gprs ms-address exclude-range start-ip end-ip
no gprs ms-address exclude-range start-ip end-ip
Syntax Description
Defaults
No default behavior or values.
Command Modes
Global configuration
Command History
Usage Guidelines
An MS can not have the same IP address as another GPRS network entity. Use the gprs ms-address exclude-range command to reserve certain IP address ranges for use by the GPRS network, and to disallow them from use by an MS.
During a create PDP context request, the GGSN verifies whether the IP address of an MS falls within the specified excluded range. If there is an overlap of the MS IP address with an excluded range, then the PDP context request is rejected. This measure prevents duplicate IP addressing in the network.
You can configure up to 100 IP address ranges. A range can be one or more addresses. However, you can configure only one IP address range per command entry. To exclude a single IP address, you can repeat the IP address in the start-ip and end-ip arguments. IP addresses are 32-bit values.
Examples
Example 1
The following example specifies the IP address ranges used by the GPRS network (which are thereby excluded from the MS IP address range:
gprs ms-address exclude-range 10.0.0.1 10.20.40.50gprs ms-address exclude-range 172.16.150.200 172.30.200.255gprs ms-address exclude-range 192.168.100.100 192.168.200.255Example 2
The following example excludes an MS from using the IP address of 10.10.10.1:
gprs ms-address exclude-range 10.10.10.1 10.10.10.1Related Commands
gprs ni-pdp cache-timeout
To specify the maximum amount of time that the GGSN caches an SGSN address for an MS after an unsuccessful network-initiated PDP context attempt, use the gprs ni-pdp cache-timeout global configuration command. To return to the default value, use the no form of this command.
gprs ni-pdp cache-timeout number
no gprs ni-pdp cache-timeout number
Syntax Description
Defaults
600 seconds (10 minutes)
Command Modes
Global configuration
Command History
Usage Guidelines
The GGSN obtains the SGSN address for an MS from the HLR and caches it for the period of time specified by the gprs ni-pdp cache-timeout command, for unsuccessful network-initiated PDP context attempts with a cause of "MS not reachable" or "MS refuses." The GGSN needs the SGSN address if the MS is not reachable or if the MS refuses the PDP PDU.
Examples
The following example specifies that the GGSN caches the SGSN address for an MS for 300 seconds (5 minutes):
gprs ni-pdp cache-timeout 300Related Commands
gprs ni-pdp discard-period
To specify the amount of time that the GGSN discards subsequent PDP PDUs received on the Gi interface for an MS, after an unsuccessful network-initiated PDP context attempt, use the gprs ni-pdp discard-period global configuration command. To return to the default value, use the no form of this command.
gprs ni-pdp discard-period number
no gprs ni-pdp discard-period number
Syntax Description
Defaults
300 seconds (5 minutes)
Command Modes
Global configuration
Command History
Usage Guidelines
Used the gprs ni-pdp discard-period command to specify how long the GGSN discards subsequent PDUs for a PDP context from an MS, after an unsuccessful network-initiated PDP context attempt.
Examples
The following example specifies that, after an unsuccessful network-initiated PDP delivery attempt, the GGSN discards subsequent PDP PDUs received on the Gi interface for 180 seconds (3 minutes):
gprs ni-pdp discard-period 180Related Commands
gprs ni-pdp ip-imsi single
To specify a static IP address to IMSI mapping for a single MS for network-initiated PDP requests from a particular APN, use the gprs ni-pdp ip-imsi single global configuration command. To remove the static mapping, use the no form of this command.
gprs ni-pdp ip-imsi single apn-index ip-address imsi
no gprs ni-pdp ip-imsi single apn-number ip-address imsi
Syntax Description
Defaults
No default behavior or values.
Command Modes
Global configuration
Command History
Usage Guidelines
The GGSN supports a single IP address and APN combination for the gprs ni-pdp ip-imsi single command. The IMSI must be unique for each IP and APN combination.
You can configure multiple instances of the gprs ni-pdp ip-imsi single command.
In addition to configuring the gprs ni-pdp ip-imsi single command, you must configure the following other commands to support network-initiated PDP requests on the GGSN:
•
•
Note
Examples
The following example configures a static IP address 10.10.10.10 for a network-initiated PDP request from access point 200 for an MS with an IMSI of 18273645546374.
gprs ni-pdp ip-imsi single 200 10.10.10.10 18273645546374gprs default map-converting-gsn 172.16.10.10!gprs access-point-list abcaccess-point 200network-request-activationNote that the gprs default map-converting-gsn global configuration command and the network-request-activation command at access point 200 are also required to implement the network-initiated PDP support at access point 200.
Related Commands
gprs ni-pdp pdp-buffer
To specify the maximum size of the GGSN buffer to be used for each network-initiated PDP request, use the gprs ni-pdp pdp-buffer global configuration command. To return to the default value, use the no form of this command.
gprs ni-pdp pdp-buffer number
no gprs ni-pdp pdp-buffer number
Syntax Description
Defaults
2000 bytes
Command Modes
Global configuration
Command History
Usage Guidelines
The GGSN supports three options that together determine the maximum possible memory that the GGSN allocates to buffer any PDU data before a network-initiated PDP request has completed:
•
•
•
Use the following formula to determine the maximum possible memory that the GGSN allocated for buffering of any PDU data for each network-initiated PDP request. The corresponding value for each command should be substituted into the following equation:
(gprs maximum-pdp-context-allowed x gprs ni-pdp percentage / 100) x gprs ni-pdp pdp-buffer
By default, the GGSN allocates the following amount of memory for network-initiated PDP request data buffering: (10000 x 10/100) x 2000 bytes = 2,000,000 bytes.
Use the gprs maximum-pdp-context-allowed command to configure the total maximum number of active PDP contexts supported by the GGSN—both mobile-initiated and network-initiated PDP requests combined. The maximum number of PDP contexts supported on the GGSN is router dependent. For more information, see the "Restrictions" section in the "Planning to Configure the GGSN" chapter of the Cisco IOS Mobile Wireless Configuration Guide.
The GGSN allocates buffer space as needed and does not preallocate memory. Therefore, it is possible that other functions requiring memory by the GGSN can prevent memory from being available for allocation to the network-initiated PDP requests—even though the buffer has been configured.
In addition, if an entire PDU requiring caching does not fit in the remaining available buffer space, the PDU is discarded.
Examples
The following example configures 3000 bytes as the maximum size of the GGSN buffer to be used for each network-initiated PDP request:
gprs ni-pdp pdp-buffer 3000Related Commands
gprs ni-pdp percentage
To specify the maximum number of PDP contexts on the GGSN that can be network-initiated, as a percentage of the maximum number of PDP contexts allowed on the GGSN, use the gprs ni-pdp percentage global configuration command. To return to the default value, use the no form of this command.
gprs ni-pdp percentage percentage-number
no gprs ni-pdp percentage percentage-number
Syntax Description
percentage-number
Percentage from 0 to 100 of the total number of PDP contexts that can be network-initiated. The default is 10 percent.
Defaults
10 percent
Command Modes
Global configuration
Command History
Usage Guidelines
The GGSN supports three options that together determine the maximum possible memory that the GGSN allocates to buffer any PDU data before a network-initiated PDP request has completed:
•
•
•
Use the following formula to determine the maximum possible memory that the GGSN allocated for buffering of any PDU data for each network-initiated PDP request. The corresponding value for each command should be substituted into the following equation:
(gprs maximum-pdp-context-allowed x gprs ni-pdp percentage / 100) x gprs ni-pdp pdp-buffer
By default, the GGSN allocates the following amount of memory for network-initiated PDP request data buffering: (10000 x 10/100) x 2000 bytes = 2,000,000 bytes.
Use the gprs maximum-pdp-context-allowed command to configure the total maximum number of active PDP contexts supported by the GGSN—both mobile-initiated and network-initiated PDP requests combined. The maximum number of PDP contexts supported on the GGSN is router dependent. For more information, see the Restrictions section of the "Planning to Configure the GGSN" chapter in the Cisco IOS Mobile Wireless Configuration Guide.
The GGSN allocates buffer space as needed and does not preallocate memory. Therefore, it is possible that other functions requiring memory by the GGSN can prevent memory from being available for allocation to the network-initiated PDP requests—even though the buffer has been configured.
Examples
The following example configures 25 percent as the maximum number of network-initiated PDP requests supported by the GGSN:
gprs ni-pdp percentage 25Related Commands
gprs plmn ip address
To specify the IP address range of a PLMN, use the gprs plmn ip address global configuration command.
gprs plmn ip address start_ip end_ip [sgsn]
Syntax Description
Defaults
No default behavior or values.
Command Modes
Global configuration
Command History
Usage Guidelines
Use the gprs plmn ip address global configuration command to specify the IP address range of the PLMN.
When using the gprs plmn ip address command with the GGSN charging for roamers feature (gprs charging roamers command), the charging for roamer feature functions as follows, depending on how the PLMN IP address ranges have been defined using the gprs plmn ip address start_ip end_ip [sgsn] command:
•
•
•
With this configuration, the following scenarios outline how the charging for roamers feature will function:
–
–
Configuration Guidelines
To enable charging for roamers on the GGSN, you should first define a set of IP address ranges for a PLMN using the gprs plmn ip address command.
It is important that you configure the gprs plmn ip address and gprs charging roamers commands in their proper order. After you configure the IP address range for a PLMN, use the gprs charging roamers command to enable charging for roamers on the GGSN. You can change the IP address range by reissuing the gprs plmn ip address command.
To verify your configuration, use the show gprs charging parameters command to see if the charging for roamers command is enabled. To verify your PLMN IP address ranges, use the show gprs plmn ip address command.
Examples
The following example specifies the IP address range of a PLMN:
gprs plmn ip address 10.0.0.1 10.20.40.50Related Commands
gprs charging roamers
Enables charging for roamers on the GGSN.
show gprs plmn ip address
Displays a list of IP address ranges defined for the PLMN.
gprs qos default-response requested
To specify that the GGSN sets its default QoS values in the response message exactly as requested in the create PDP context request message, use the gprs qos default-response requested global configuration command. To return to the default QoS, use the no form of this command.
gprs qos default-response requested
no gprs qos default-response requested
Syntax Description
This command has no arguments or keywords.
Defaults
Disabled. The GGSN sets its QoS default to the best-effort class.
Command Modes
Global configuration
Command History
Usage Guidelines
The gprs qos default-response requested command is only useful when canonical QoS is not configured on the GGSN. Canonical QoS is enabled using the gprs qos map canonical-qos command.
When canonical QoS is not enabled, and the gprs qos default-response requested command has not been configured on the GGSN, the GGSN always sets its QoS values to best-effort in the response message.
Examples
The following example enables the GGSN to set its QoS values in the response message according to the QoS values requested in the create PDP context request message:
gprs qos default-response requestedRelated Commands
Enables mapping of GPRS QoS categories to a canonical QoS method that includes best-effort, normal, and premium QoS classes.
gprs qos map canonical-qos
To enable mapping of GPRS QoS categories to a canonical QoS method that includes best-effort, normal, and premium QoS classes, use the gprs qos map canonical-qos global configuration command. To disable canonical mapping, use the no form of this command.
gprs qos map canonical-qos
no gprs qos map canonical-qos
Syntax Description
This command has no arguments or keywords.
Defaults
Canonical QoS mapping is disabled.
Command Modes
Global configuration
Command History
Usage Guidelines
Use the qprs qos map canonical-qos command to map GPRS QoS into the following canonical categories: best effort, normal, and premium.
Examples
The following example shows canonical QoS mapping enabled:
qos map canonical-qosRelated Commands
gprs qos map delay
To enable mapping of GPRS QoS categories to delay QoS classes, use the gprs qos map delay global configuration command. To disable delay mapping, use the no form of this command.
gprs qos map delay
no gprs qos map delay
Syntax Description
This command has no arguments or keywords.
Defaults
Disabled
Command Modes
Global configuration
Command History
Usage Guidelines
Use the gprs qos map delay command to enable QoS delay mapping on the GGSN. To map the QoS delay classes (class 1, class 2, class 3, and best effort) to IP type of service (ToS) categories, use the gprs delay-qos map tos command.
Examples
The following example enables delay QoS mapping:
gprs qos map delayRelated Commands
gprs qos map umts
To enable UMTS QoS on the GGSN, use the gprs qos map umts global configuration command. To disable this mapping and return to the default QoS mapping, use the no form of this command.
gprs qos map umts
no gprs qos map umts
Syntax Description
This command has no arguments or keywords.
Defaults
UMTS QoS mapping is disabled.
Command Modes
Global configuration
Command History
Usage Guidelines
Use the gprs qos map umts command to enable UMTS QoS mapping.
Examples
The following example enables UMTS traffic QoS mapping:
gprs qos map umtsRelated Commands
gprs radius attribute chap-challenge
To specify that the CHAP challenge always be included in the Challenge Attribute field (and not in the Authenticator field) in an Access-Request to the Remote Access Dial-In User Service (RADIUS) server, use gprs radius attribute chap-challenge global configuration command. To disable, use the no form of this command.
gprs radius attribute chap-challenge
no gprs radius attribute chap-challenge
Syntax Description
This command has no arguments or keywords.
Defaults
If the CHAP challenge length is 16 bytes, it is sent in the Authenticator field of an Access-Request. If it is greater than 16 bytes, it is sent in the Challenge Attribute field.
Command Modes
Global configuration
Command History
Usage Guidelines
Use the gprs radius attribute chap-challenge command when configuring RADIUS security on the GGSN.
When the gprs radius attribute chap-challenge command is configured, the CHAP challenge is always sent in the Challenge Attribute field of an Access-Request to the RADIUS server and not in the Authenticator field. When the command is not configured, the CHAP challenge is sent in the Authenticator field unless the challenge exceeds 16 bytes, in which case, it is sent in the Challenge Attribute field of the Access-Request.
Examples
The following example configures the CHAP challenge to always be sent in an Access Request to the RADIUS server:
gprs radius msisdn first-bytegprs radius msisdn first-byte
To specify that the first byte of the Mobile Stations International PSTN/ISDN (MSISDN) information element (IE) is included in a Remote Access Dial-In User Service (RADIUS) request, use the gprs radius msisdn first-byte global configuration command. To remove the first byte from the MSISDN IE in a RADIUS request, use the no form of this command.
gprs radius msisdn first-byte
no gprs radius msisdn first-byte
Syntax Description
This command has no arguments or keywords.
Defaults
The first byte is not included.
Command Modes
Global configuration
Command History
Usage Guidelines
Use the gprs radius msisdn first-byte command when configuring RADIUS security on the GGSN.
The first octet of an MSISDN IE using E.164 addressing is 91 in hexadecimal, that is 10010001. In this 91 code, the 1 is the extension bit, 001 is the international number, and 0001 indicates E.164 numbering.
Examples
The following example specifies that the first byte of the MSISDN IE is included in a RADIUS request:
gprs radius msisdn first-bytegprs slb cef
To identify the IP address of the GGSN virtual server to CEF, use the gprs slb cef global configuration command. To remove the IP address identification, use the no form of this command.
gprs slb cef virtual-server-address
no gprs slb cef virtual-server-address
Syntax Description
virtual-server-address
IP address of the GGSN virtual server instance used by clients to connect to the server farm. (This virtual IP address is also a loopback address on the GGSN.)
Defaults
No default behavior or values.
Command Modes
Global configuration
Command History
Usage Guidelines
This command is required if the GGSN is using CEF switching. If the GGSN is not using CEF switching, do not use this command.
Note
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121limit/121e/121e9/index.htmExamples
The following example identifies the IP address of the GGSN virtual server, 10.0.0.13, to CEF:
gprs slb cef 10.0.0.13Related Commands
interface loopback
Creates a loopback interface.
ip cef
Enables CEF on the RP card.
virtual (virtual server)
Configures the virtual server attributes.
gprs umts-qos dscp unmodified
To specify that the subscriber datagram be forwarded through the GTP path without modifying its DSCP, use the gprs umts-qos dscp unmodified global configuration command. To remove this specification and enable the DSCP to be re-marked with the DSCP assigned to the traffic class during the PDP context creation, use the no form of this command.
gprs umts-qos dscp unmodified [up | down | all]
no gprs umts-qos dscp unmodified [up | down | all]
Syntax Description
Defaults
The DSCP in the subscriber datagram is re-marked with the DSCP assigned to the traffic class during the PDP context creation.
Command Modes
Global configuration
Command History
Usage Guidelines
Use the gprs umts-qos dscp unmodified command to configure the GGSN to forward subscriber datagram DSCPs through the GTP path without modifying the DSCP.
Examples
The following example sets subscriber datagrams in the uplink GTP path to retain their DSCPs:
gprs umts-qos dscp unmodified upRelated Commands
gprs umts-qos map diffserv-phb
To assign a differentiated services code point (DSCP) to a DiffServ PHB group, use the gprs umts-qos map diffserv-phb global configuration command. To set the specified DSCP to the default DiffServ PHB group, use the no form of this command.
gprs umts-qos map diffserv-phb diffserv-phb-group [dscp1] [dscp2] [dscp3]
no gprs umts-qos map diffserv-phb diffserv-phb-group [dscp1] [dscp2] [dscp3]
Syntax Description
Defaults
The default DSCP value associated with the PHB class is used.
Command Modes
Global configuration
Command History
Usage Guidelines
For the Assured Forwarding (AF) PHB group, you can specify up to three DSCP values for each drop precedence. The signalling, EF, and best-effort classes do not have drop precedence, so only the first DSCP value is used. If you enter a value for the dscp2 or dscp3 arguments for these classes, it is ignored.
Drop precedence indicates the order in which a packet will be dropped when there is congestion on the network.
Table 1 shows the default DSCP values for each PHB group.
Examples
The following example assigns a DSCP value of 31 to the EF class and three DSCP values to AF class2 of 51, 52, and 53:
gprs umts-qos map diffserv-phb ef-class 31gprs umts-qos map diffserv-phb af-class2 51 52 53Related Commands
gprs umts-qos map traffic-class
To specify a QoS mapping from the UMTS traffic classes to a differentiated services (DiffServ) per-hop behavior (PHB) group, use the gprs umts-qos map traffic-class global configuration command. To remove a QoS mapping and set the specified traffic class to the default mapping, use the no form of this command.
gprs umts-qos map traffic-class traffic-class diffserv-phb-group
no gprs umts-qos map traffic-class traffic-class diffserv-phb-group
Syntax Description
Defaults
You must enable UMTS QoS using the gprs qos map umts command before entering this command.
Note
The default mapping values for the UMTS traffic classes are as follows:
•
•
•
•
•
Command Modes
Global configuration
Command History
Usage Guidelines
Use the gprs umts-qos map traffic-class command to specify a mapping between various QoS UMTS traffic categories and the DiffServ PHB groups.
Examples
The following example specifies a QoS mapping from the UMTS traffic class conversational to the DiffServ PHB group af-class1:
gprs umts-qos map traffic-class conversational af1-classRelated Commands
gtp response-message wait-accounting
To configure the GGSN to wait for a RADIUS accounting response before sending a create PDP context response to the SGSN, for create PDP context requests received at a particular APN, use the gtp response-message wait-accounting access-point configuration command. To configure the GGSN to send a create PDP context response to the SGSN after sending a RADIUS start accounting message to the RADIUS server (without waiting for a response from the RADIUS accounting server), use the no form of this command.
gtp response-message wait-accounting
no gtp response-message wait-accounting
Syntax Description
This command has no arguments or keywords.
Defaults
The GGSN sends a create PDP context response to the SGSN after sending a RADIUS start accounting message to the RADIUS accounting server. The GGSN does not wait for a RADIUS accounting response from the RADIUS accounting server.
Command Modes
Access-point configuration
Command History
Usage Guidelines
Use the gtp response-message wait-accounting command to configure the GGSN to wait for a RADIUS accounting response from the RADIUS accounting server, before sending a create PDP context response to the SGSN.
If the GGSN does not receive a response from the RADIUS accounting server when you have configured the gtp response-message wait-accounting command, then the GGSN rejects the PDP context request.
The GGSN supports configuration of RADIUS response message waiting at both the global and access-point configuration levels. You can minimize your configuration by specifying the configuration that you want to support across most APNs, at the global configuration level. Then, at the access-point configuration level, you can selectively modify the behavior that you want to support at a particular APN. Therefore, at the APN configuration level, you can override the global configuration of RADIUS response message waiting.
To configure the GGSN to wait for a RADIUS accounting response as the default behavior for all APNs, use the gprs gtp response-message wait-accounting global configuration command. To disable this behavior for a particular APN, use the no gtp response-message wait-accounting access-point configuration command.
To verify whether RADIUS response message waiting is enabled or disabled at an APN, you can use the show gprs access-point command and observe the value reported in the wait_accounting output field.
Examples
The following examples show only a partial configuration of the GGSN, to highlight those commands related to implementing RADIUS response message waiting. Additional configuration statements are required to complete a full configuration of the GGSN.
Example 1
The following example configures the GGSN to wait for an accounting response from the RADIUS server before sending a create PDP context response to the SGSN, for PDP context requests at access-point 1:
aaa new-model!aaa group server radius fooserver 10.2.3.4server 10.6.7.8!aaa authentication ppp foo group fooaaa authorization network default group radiusaaa accounting exec default start-stop group foo!gprs access-point-list gprsaccess-point 1access-mode non-transparentaccess-point-name www.pdn1.comaaa-group authentication foogtp response-message wait-accounting!radius-server host 10.2.3.4 auth-port 1645 acct-port 1646 non-standardradius-server host 10.6.7.8 auth-port 1645 acct-port 1646 non-standardradius-server key ggsntelExample 2
The following example globally configures the GGSN to wait for a RADIUS accounting response from the RADIUS server before sending a create PDP context response to the SGSN. The GGSN waits for a response for PDP context requests received across all access points, except access-point 1. RADIUS response message waiting has been overridden at access-point 1 using the no gtp response-message wait-accounting command:
aaa new-model!aaa group server radius fooserver 10.2.3.4server 10.6.7.8!aaa authentication ppp foo group fooaaa authorization network default group radiusaaa accounting exec default start-stop group foo!gprs access-point-list gprsaccess-point 1access-mode non-transparentaccess-point-name www.pdn1.comaaa-group authentication foono gtp response-message wait-accountingexitaccess-point 2access-mode non-transparentaccess-point-name www.pdn2.comaaa-group authentication foo!gprs gtp response-message wait-accounting!radius-server host 10.2.3.4 auth-port 1645 acct-port 1646 non-standardradius-server host 10.6.7.8 auth-port 1645 acct-port 1646 non-standardradius-server key ggsntelRelated Commands
group (local RADIUS server)
To enter user group configuration mode and to configure shared settings for a user group, use the group command in local RADIUS server configuration mode. To remove the group configuration from the local RADIUS server, use the no form of this command.
group group-name
no group group-name
Syntax Description
Defaults
No default behavior or values
Command Modes
Local RADIUS server configuration
Command History
Examples
The following example shows that shared settings are being configured for group "team1":
group team1Related Commands
interface cdma-Ix
To define the virtual interface for the R-P tunnels, use the interface cdma-Ix command in global configuration mode. To disable the interface, use the no form of this command.
interface cdma-Ix1
no interface cdma-Ix1
Syntax Description
Defaults
No default behavior or values.
Command Modes
Global Configuration
Command History
12.1(3)XS
This command was introduced.
12.3(4)T
This command was incorporated in Cisco IOS Release 12.3(4)T.
Usage Guidelines
The only interface level command allowed on the virtual interface is the IP address configuration.
Examples
The following example defines the virtual interface for the R-P tunnel and configures the IP address:
interface cdma-Ix1ip address 1.1.1.1 255.255.0.0Related Commands
ip mobile foreign-agent skip-aaa-reauthentication
To enable FA-CHAP during Mobile IP registration, and then to skip it in all subsequent re-registrations, use the ip mobile foreign-agent skip-aaa-reauthentication command in global configuration mode. To disable this feature, use the no form of this command.
ip mobile foreign-agent skip-aaa-reauthentication
no ip mobile foreign-agent skip-aaa-reauthentication
Syntax Description
There are no keywords or arguments for this commmand.
Defaults
Disabled
Command Modes
Global configuration
Command History
Usage Guidelines
FA-CHAP is a mechanism for authentication in Mobile IP. As per IS835, FA-CHAP is mandatory during Mobile IP call setup (registration), and requires access to a AAA server. A Mobile IP call has a parameter lifetime, so in order to continue a Mobile IP call, re-registration is required before the lifetime expires, and this re-registration leads to extending of lifetime.
Because FA-CHAP is mandatory, and the call is authenticated during registration, it may be undesirable to access AAA during re-registration of the Mobile IP call. The ip mobile foreign-agent skip-aaa-reauthentication command provides flexibility in this scenario.
When this command is configured, FA-CHAP is performed during Mobile IP registration, and is skipped in all subsequent re-registrations.
The default value is "false", implying that AAA access is not skipped during Mobile IP re-registration.
Examples
The following example shows that FA-CHAP is enabled during Mobile IP registration, but disabled for all subsequent re-registrations:
ip mobile foreign-agent skip-aaa-reauthenticationip mobile foreign-service
To enable foreign agent service on if care-of addresses are configured, use the ip mobile foreign-service command in interface or global configuration mode. To disable this service, use the no form of this command.
ip mobile foreign-service [home-access access-list] [limit number] [registration-required] [challenge {timeout value | window number | forward-mfce}] [reverse-tunnel [mandatory]]
no ip mobile foreign-service [home-access access-list] [limit number] [registration-required] [challenge {timeout value | window number | forward-mfce}] [reverse-tunnel [mandatory]]
Syntax Description
Defaults
Foreign agent service is not enabled.
There is no limit to the number of visitors allowed on an interface.
window number: 2
Foreign agent reverse tunneling is not enabled. When foreign agent reverse tunneling is enabled, it is not mandatory by default.Command Modes
Interface and global configuration
Command History
Usage Guidelines
This command enables foreign agent service on the interface or all interfaces (global configuration). The foreign agent (F) bit will be set in the agent advertisement, which is appended to the IRDP router advertisement whenever the foreign agent or home agent service is enabled on the interface.
Note
When you use the reverse-tunnel keyword to enable foreign agent reverse tunneling on an interface, the reverse tunneling support (T) bit is set in the agent advertisement.
Cisco Express Forwarding (CEF) switching is currently not supported on a foreign agent when reverse tunneling is enabled. If reverse tunneling is enabled at the foreign agent, disable CEF on the foreign agent, using the no ip cef global configuration command. If the foreign agent does not support reverse tunneling, then there is no need to disable CEF at the global configuration level.
Table 2 lists the advertised bitflags.
Examples
The following example shows how to enable foreign agent service for up to 100 visitors:
interface Ethernet 0ip mobile foreign-service limit 100 registration-requiredThe following example shows how to enable foreign agent reverse tunneling:
interface ethernet 0ip mobile foreign-service reverse-tunnelThe following example shows how to configure foreign agent challenge parameters:
interface ethernet 0ip mobile foreign-service challenge window 2Related Commands
ip mobile host
To configure the mobile host or mobile node group, use the ip mobile host command in global configuration mode. To disable these services, use the no form of this command.
ip mobile host {lower [upper] | nai string [static-address {addr1 [addr2] [addr3] [addr4] [addr5] | local-pool name}] [address {addr | pool {local name | dhcp-proxy-client [dhcp-server addr]}]} {interface name | virtual-network network-address mask} [aaa [load-sa [permanent]]] [authorized-pool name] [skip-aaa-reauthentication][care-of-access access-list] [lifetime seconds]
no ip mobile host {lower [upper] | nai string [static-address {addr1 [addr2] [addr3] [addr4] [addr5] | local-pool name}] [address {addr | pool {local name | dhcp-proxy-client [dhcp-server addr]}]} {interface name | virtual-network network-address mask} [aaa [load-sa [permanent]]] [authorized-pool name] [skip-aaa-reauthentication] [care-of-access access-list] [lifetime seconds]
Syntax Description
lower [upper]
One or a range of mobile host or mobile node group IP addresses. The upper end of the range is optional.
nai string
Network access identifier. The NAI can be a unique identifier (username@realm) or a group identifier (@realm).
static-address
(Optional) Indicates that a static IP address is to be assigned to the flows on this NAI. This parameter is not valid if the NAI is a realm.
addr1, addr2, ...
(Optional) One to a maximum of five IP addresses to be assigned using the static-address keyword.
local-pool name
(Optional) Name of the local pool of addresses to use for assigning a static IP address to this NAI.
address
(Optional) Indicates that a dynamic IP address is to be assigned to the flows on this NAI.
addr
(Optional) IP address to be assigned using the address keyword.
pool
(Optional) Indicates that a pool of addresses is to be used in assigning a dynamic IP address.
local name
(Optional) The name of the local pool to use in assigning addresses.
dhcp-proxy-client
(Optional) Indicates that the DHCP request should be sent to a DHCP server on behalf of the mobile node.
dhcp-server addr
(Optional) IP address of the DHCP server.
interface name
When used with DHCP, specifies the gateway address from which the DHCP server should select the address.
virtual-network network-address mask
Indicates that the mobile station resides in the specified virtual network, which was created using the ip mobile virtual-network command.
aaa
(Optional) Retrieves security associations from a AAA (TACACS+ or RADIUS) server. Allows the home agent to download address configuration details from the AAA server.
load-sa
(Optional) Caches security associations after retrieval by loading the security association into RAM. See Table 4 for details on how security associations are cached for NAI hosts and non-NAI hosts.
permanent
(Optional) Caches security associations in memory after retrieval permanently. Use this optional keyword only for NAI hosts.
authorized-pool name
(Optional) Verifies the IP address assigned to the mobile node if it is within the pool specified by the name argument.
skip-aaa-reauthentication
(Optional) When configured, the home agent does not send an access request for authentication for mobile IP re-registration requests. When disabled, the home agent sends an access request for all Mobile IP registration requests.
care-of-access access-list
(Optional) Access list. This can be a named access list or standard access list. The range is from 1 to 99. Controls where mobile nodes roam—the acceptable care-of addresses.
lifetime seconds
(Optional) Lifetime (in seconds). The lifetime for each mobile node (group) can be set to override the global value. The range is from 3 to 65535 (infinite).
Defaults
No host is configured.
Command Modes
Global configuration
Command History
Usage Guidelines
This command configures the mobile host or mobile node group (ranging from lower address to upper address) to be supported by the home agent. These mobile nodes belong to the network on an interface or a virtual network (via the ip mobile virtual-network command). The security association for each mobile host must be configured using the ip mobile secure command or downloaded from a AAA server.
All hosts must have security associations for registration authentication. Mobile nodes can have more than one security association. The memory consumption calculations shown in Table 3 are based on the assumption of one security association per mobile node. Caching behavior of security associations differs between NAI and non-NAI hosts as described in Table 4.
The nai keyword allows you to specify a particular mobile node or range of mobile nodes. The mobile node can request a static IP address (static-address keyword), which is configured using the addr1 variable (for a specific address) or the local-pool keyword (for an IP address from an address pool; the requested address must be in the pool). Or, the mobile node can request a dynamic address (address keyword), which is configured using the addr variable (for a specific address) or the pool keyword (for an IP address from a pool or DHCP server). If this command is used with the Packet Data Serving Node (PDSN) proxy Mobile IP feature and a realm is specified in the ip mobile proxy-host nai command, then only a pool of addresses can be specified in this command.
The address pool can be defined by a local pool or by use of a DHCP proxy client. For DHCP, the interface name keyword and argument combination specifies the gateway address from which the DHCP server should select the address and the dhcp-server keyword specifies the DHCP server address. The NAI is sent in the client-id option of the DHCP packet and can be used to provide dynamic DNS services.
You can also use this command to configure the static IP address or address pool for multiple flows with the same NAI. A flow is a set of {NAI, IP address}.
Security associations can be stored using one of three methods:
•
•
•
Each method has advantages and disadvantages, which are described in Table 3.
The caching behavior of security associations for NAI hosts and non-NAI hosts is described in Table 4.
Examples
The following example configures a mobile node group to reside on virtual network 20.0.0.0 and retrieve mobile node security associations from a AAA server every time the mobile node registers:
ip mobile host 20.0.0.1 20.0.0.3 virtual-network 20.0.0.0 aaaThe following example configures a mobile node group to reside on virtual network 10.99.1.0 and retrieve and cache mobile node security associations from a AAA server. The cached security association is then used for subsequent registrations.
ip mobile host 10.99.1.1 10.99.1.100 virtual-network 10.99.1.0 aaa load-saThe following example configures a local pool of dynamic addresses to be used in assigning IP addresses to mobile nodes in the cisco.com domain:
ip mobile host nai @cisco.com address pool local mobilenodes virtual-network 9.0.0.0 255.0.0.0 aaa lifetime 180The following example configures a local pool of dynamic addresses to be used in assigning IP addresses to mobile nodes in the cisco.com domain. The security associations that are retrieved from the AAA server are cached as long as the binding is present and are deleted on the home agent when the binding is removed (due to manual clearing of the binding or lifetime expiration).
ip mobile host nai @cisco.com address pool local mobilenodes virtual-network 10.2.0.0 255.255.0.0 aaa load-sa lifetime 180The following example configures a local pool of static addresses to be used in assigning IP addresses to mobile nodes in the cisco.com domain:
ip mobile host nai @cisco.com static-address local-pool mobilenodesThe following example configures a local pool of dynamic addresses to be used in assigning IP addresses to mobile nodes in the cisco.com domain. The security associations that are retrieved from the AAA server are cached permanently until cleared manually.
ip mobile host nai @cisco.com address pool local mobilenodes virtual network 10.2.0.0 255.255.0.0 aaa load-sa permanent lifetime 180The following example configures the DHCP proxy client to use a DHCP server located at 10.1.2.3 to allocate a dynamic home address:
ip mobile host nai @dhcppool.com address pool dhcp-proxy-client dhcp-server 10.1.2.3 interface FastEthernet 0/0Related Commands
ip mobile prefix-length
To append the prefix-length extension to the advertisement, use the ip mobile prefix-length command in interface configuration mode. To restore the default, use the no form of this command.
ip mobile prefix-length
no ip mobile prefix-length
Syntax Description
This command has no arguments or keywords.
Defaults
The prefix-length extension is not appended.
Command Modes
Interface and Global configuration
Command History
12.0(1)T
This command was introduced.
12.3(11)T
Global configuration mode was added.
Usage Guidelines
The prefix-length extension is used for movement detection. When a mobile node registered with one foreign agent receives an agent advertisement from another foreign agent, the mobile node uses the prefix-length extension to determine whether the advertisements arrived on the same network. The mobile node needs to register with the second foreign agent if it is on a different network. If the second foreign agent is on the same network, reregistration is not necessary.
Examples
The following example appends the prefix-length extension to agent advertisements sent by a foreign agent:
ip mobile prefix-lengthRelated Commands
show ip mobile interface
Displays advertisement information for interfaces that are providing foreign agent service or are home links for mobile nodes.
ip mobile registration-lifetime
To set the registration lifetime value advertised, use the ip mobile registration-lifetime command in interface or global configuration mode.
ip mobile registration-lifetime seconds
Syntax Description
Defaults
36000 seconds
Command Modes
Interface and global configuration
Command History
12.0(1)T
This command was introduced.
12.3(11)T
Global configuration mode was added.
Usage Guidelines
This command allows an administrator to control the advertised lifetime on the interface. The foreign agent uses this command to control duration of registration. Visitors requesting longer lifetimes will be denied.
Examples
The following example sets the registration lifetime to 10 minutes on interface Ethernet 1 and 1 hour on interface Ethernet 2:
interface e1ip mobile registration-lifetime 600interface e2ip mobile registration-lifetime 3600Related Commands
show ip mobile interface
Displays advertisement information for interfaces that are providing foreign agent service or are home links for mobile nodes.
ip mobile secure host
To specify the mobility security associations (SAs) for a mobile host, use the ip mobile secure host command in global configuration mode. To remove the mobility SAs, use the no form of this command.
ip mobile secure host {lower-address [upper-address] | nai nai-string} {inbound-spi spi-in outbound-spi spi-out | spi {hex-value | decimal decimal-value}} key {ascii string | hex string} [replay timestamp seconds] [algorithm {md5 mode prefix-suffix | hmac-md5}] [skip-aaa-reauthentication]
no ip mobile secure host {lower-address [upper-address] | nai nai-string} {inbound-spi spi-in outbound-spi spi-out | spi {hex-value | decimal decimal-value}} key {ascii string | hex string} [replay timestamp seconds] [algorithm {md5 mode prefix-suffix | hmac-md5}] [skip-aaa-reauthentication]
Syntax Description
Defaults
No SA is specified for mobile hosts.
Command Modes
Global configuration
Command History
Usage Guidelines
The SA consists of an entity address, SPI, key, replay protection method, authentication algorithm, and authentication algorithm mode (prefix-suffix).
The SA of a visiting mobile host on the MFAE and the SA of the home agent (HA) on the FHAE are optional as long as they are not specified on the other entity. Multiple SAs for each entity can be configured.
The HMAC-MD5 authentication algorithm is mandatory for MHAE, MFAE, and FHAE.
Note
Examples
The following example shows the configuration of an SA for a host:
ip mobile secure host 10.0.0.4 spi 100 key hex 12345678123456781234567812345678Related Commands
ip probe path
To enable route probe support on an APN, use the ip probe path access-point configuration command. To return to the default, use the no form of this command.
ip probe path ip_address protocol udp [port port ttl ttl]
no ip probe path ip_address protocol udp [port port ttl ttl]
Syntax Description
Defaults
Disabled
Command Modes
Access-point configuration
Command History
12.3(2)XB1
This command was introduced.
12.3(8)T
This command was incorporated in Cisco IOS Release 12.3(8)T.
Usage Guidelines
Use the ip probe path access-point configuration command to enable the GGSN to send a probe packet to a specific destination for each PDP context that is successfully established.
An example of how to use this feature is when a firewall load balancer (FWLB) is being used in the network. If the ip probe path command is configured, when a PDP context is established, the GGSN sends a probe packet the FWLB. This enables the FWLB to create an entry for the PDP context even if there is no upstream packet from the MS. Once an entry is created, the FWLB can forward any downstream packet from the network for the MS to the appropriate GGSN without depending on the MS to send the packet first.
Note
ip rtp compression-connections
To specify the total number of Real-Time Transport Protocol (RTP) header compression connections that can exist on an interface, use the ip rtp compression-connections command in interface configuration mode. To restore the default value, use the no form of this command.
ip rtp compression-connections number
no ip rtp compression-connections
Syntax Description
number
Number of RTP header compression connections the cache supports, in the range from 3 to 1000.
Defaults
For PPP and High-Level Data Link Control (HDLC) interfaces, the default is 16 compression connections.
For Frame Relay interfaces, the default is 256 compression connections.
Command Modes
Interface configuration
Command History
Usage Guidelines
You should configure one connection for each RTP call through the specified interface.
Each connection sets up a compression cache entry, so you are in effect specifying the maximum number of cache entries and the size of the cache. Too few cache entries for the specified interface can lead to degraded performance, and too many cache entries can lead to wasted memory.
Note
Note
Examples
The following example changes the number of RTP header compression connections supported to 150:
Router> enableRouter# configure terminalRouter(config)# interface Serial1/0.0Router(config-if)# encapsulation pppRouter(config-if)# ip rtp header-compressionRouter(config-if)# ip rtp compression-connections 150Router(config-if)# exitRelated Commands
ip rtp header-compression
Enables RTP header compression.
show ip rtp header-compression
Displays RTP header compression statistics.
ip rtp header-compression
To enable Real-Time Transport Protocol (RTP) header compression, use the ip rtp header-compression command in interface configuration mode. To disable RTP header compression, use the no form of this command.
ip rtp header-compression [passive | iphc-format | ietf-format] [periodic-refresh] [ignore-id]
no ip rtp header-compression [passive | iphc-format | ietf-format] [periodic-refresh] [ignore-id]
Syntax Description
Defaults
Disabled
For PPP interfaces, the default format for header compression is the IPHC format.
For High-Level Data Link Control (HDLC) and Frame Relay interfaces, the default format for header compression is the original proprietary Cisco format. The maximum number of compression connections for the proprietary Cisco format is 256.
Command Modes
Interface configuration
Command History
Usage Guidelines
You can compress IP/User Datagram Protocol (UDP)/RTP headers to reduce the size of your packets. Compressing headers is especially useful for RTP because RTP payload size can be as small as 20 bytes, and the uncompressed header is 40 bytes.
Header Compression passive Keyword
By default, the ip rtp header-compression command compresses outgoing RTP traffic. This command includes an optional passive keyword. If you specify the passive keyword, outgoing RTP traffic is compressed only if incoming RTP traffic on the same interface is compressed. If you do not specify the passive keyword, all RTP traffic is compressed.
For PPP interfaces, the passive keyword is ignored. PPP interfaces negotiate the use of header-compression, regardless of whether the passive keyword is specified. Therefore, on PPP interfaces, the passive keyword is replaced by the IPHC format, the default format for PPP interfaces.
Header Compression iphc-format Keyword
This command includes the iphc-format keyword. The iphc-format keyword indicates the type of header compression that will be used. For PPP and HDLC interfaces, when the iphc-format keyword is specified, TCP header-compression is also enabled. For this reason, the ip tcp header-compression command appears in the output of the show running-config command. Since both RTP and TCP header compression are enabled, both UDP and TCP packets are compressed.
The iphc-format keyword includes checking whether the destination port number is even and in the ranges of 16385 to 32767 (for Cisco audio) or 49152 to 65535 (for Cisco video). Valid RTP packets that meet the criteria (that is, the port number is even and within the specified range) are compressed using the compressed RTP packet format. Otherwise, packets are compressed using the less-efficient compressed non-TCP packet format.
Note
Header Compression ietf-format Keyword
This command includes the ietf-format keyword. The ietf-format keyword indicates the type of header compression that will be used. For HDLC interfaces, the ietf-format compresses only UDP packets. For PPP interfaces, when the ietf-format keyword is specified, TCP header-compression is also enabled. For this reason, the ip tcp header-compression command appears in the output of the show running-config command. Since both RTP and TCP header compression are enabled, both UDP and TCP packets are compressed.
However, with the ietf-format keyword, the requirement of checking whether a destination port number is in a specific range has been removed. Any even destination port number higher than 1024 can be used. Valid RTP packets that meet the criteria (that is, the port number is even and higher than 1024), are compressed using the compressed RTP packet format. Otherwise, packets are compressed using the less-efficient compressed non-TCP packet format.
Note
Support for Serial Lines
RTP header compression is supported on serial lines using Frame Relay, HDLC, or PPP encapsulation. You must enable compression on both ends of a serial connection.
Unicast or Multicast RTP Packets
This command can compress unicast or multicast RTP packets, and, hence, multicast backbone (MBONE) traffic can also be compressed over slow links. The compression scheme is beneficial only when you have small payload sizes, as in audio traffic.
Examples
The following example enables RTP header compression on the Serial1/0.0 subinterface and limits the number of RTP header compression connections to 10. In this example, the optional iphc-format keyword of the ip rtp header-compression command is specified.
Router> enableRouter# configure terminalRouter(config)# interface Serial1/0.0Router(config-if)# encapsulation pppRouter(config-if)# ip rtp header-compression iphc-formatRouter(config-if)# ip rtp compression-connections 10Router(config-if)# exitThe following example enables RTP header compression on the Serial2/0.0 subinterface and limits the number of RTP header compression connections to 20. In this example, the optional ietf-format keyword of the ip rtp header-compression command is specified.
Router> enableRouter# configure terminalRouter(config)# interface Serial2/0.0Router(config-if)# encapsulation pppRouter(config-if)# ip rtp header-compression ietf-formatRouter(config-if)# ip rtp compression-connections 20Router(config-if)# exitIn the following example, RTP header compression is enabled on the Serial1/0.1 subinterface and the optional periodic-refresh keyword of the ip rtp header-compression command is specified:
Router> enableRouter# configure terminalRouter(config)# interface Serial1/0.1Router(config-if)# encapsulation pppRouter(config-if)# ip rtp header-compression iphc-format periodic-refreshRouter(config-if)# ip rtp compression-connections 10Router(config-if)# exitRelated Commands
ip-access-group
To specify access permissions between an MS and a PDN through the GGSN at a particular access point, use the ip-access-group access-point configuration command. To disable the input access list, use the no form of this command.
ip-access-group access-list-number {in | out}
no ip-access-group access-list-number {in | out}
Syntax Description
Defaults
No access list is enforced.
Command Modes
Access-point configuration
Command History
Usage Guidelines
Use the ip-access-group command to specify an access list that indicates whether users are given or denied permission to access the mobile station from the PDN through the GGSN using a specified access point.
Examples
The following example grants access-list 101 inbound access to the mobile station from the PDN through the GGSN:
access-list 101 permit ip 10.0.0.2 0.255.255.255 anyinterface virtual-template 1ip address 172.16.10.1 255.255.255.0no ip directed-broadcastencapsulation gtpgprs access-point-list abc!gprs access-point-list abcaccess-point 1access-point-name gprs.somewhere.comdhcp-server 10.100.0.3ip-access-group 101 inexit!ip-address-pool
To specify a dynamic address allocation method using IP address pools for the current access point, use the ip-address-pool access-point configuration command. To return to the default value, use the no form of this command.
ip-address-pool {dhcp-proxy-client | radius-client | local pool-name | disable}
no ip-address-pool {dhcp-proxy-client | radius-client | local pool-name | disable}
Syntax Description
Defaults
The global setting specified with the gprs default ip-address-pool command is used. The default value for the global configuration command is that IP address pools are disabled.
Command Modes
Access-point configuration
Command History
Usage Guidelines
You can specify an IP allocation method for an access point in two ways:
•
•
If you specify dhcp-proxy-client as the method for allocating IP addresses, then you must configure a DHCP server for IP address allocation. You can do this at the global configuration level using the gprs default-dhcp server command, or at the access point level using the dhcp-server command.
If you specify radius-client as the method for allocating IP addresses, then you must configure a RADIUS server for IP address allocation, configure AAA on the GGSN, and configure AAA server groups globally on the GGSN or at the access point. For more information about configuring RADIUS on the GGSN, refer to the Usage Guidelines section for the aaa-group and gprs default aaa-group commands.
Note
Examples
The following example configures DHCP as the IP address pool allocation method for access-point 1 and specifies that the other access points use the global default, which is specified as RADIUS:
aaa new-model!aaa group server radius fooserver 10.2.3.4server 10.6.7.8aaa group server radius foo1server 10.10.0.1!aaa authentication ppp foo group fooaaa authentication ppp foo group foo1aaa authorization network default group radiusaaa accounting exec default start-stop group fooaaa accounting network foo1 start-stop group foo1!interface Loopback0ip address 10.88.0.1 255.255.255.255!interface virtual-template 1ip unnumber Loopback0no ip directed-broadcastencapsulation gtpgprs access-point-list abc!gprs access-point-list abcaccess-point 1access-point-name gprs.pdn1.comip address-pool dhcp-proxy-clientaggregate autodhcp-server 10.100.0.3dhcp-gateway-address 10.88.0.1exit!access-point 2access-point-name gprs.pdn2.comaccess-mode non-transparentaaa-group authentication fooexit!gprs default ip-address-pool radius-client!radius-server host 10.2.3.4 auth-port 1645 acct-port 1646 non-standardradius-server host 10.6.7.8 auth-port 1645 acct-port 1646 non-standardradius-server host 10.10.0.1 auth-port 1645 acct-port 1646 non-standardradius-server key ggsntelRelated Commands
keepalive
To enable keepalive packets and to specify the number of times that the Cisco IOS software tries to send keepalive packets without a response before bringing down the interface or before bringing the tunnel protocol down for a specific interface, use the keepalive command in interface configuration mode. When the keepalive function is enabled, a keepalive packet is sent at the specified time interval to keep the interface active. To turn off keepalive packets entirely, use the no form of this command.
keepalive [period [retries]]
no keepalive [period [retries]]
Syntax Description
Defaults
period: 10 seconds
retries: 5
If you enter only the keepalive command with no arguments, defaults for both arguments are used.
If you enter only the keepalive command and the timeout parameter, the default number of retries (5) is used.
If you enter the no keepalive command, keepalive packets are disabled on the interface.Command Modes
Interface configuration
Command History
Usage Guidelines
Keepalive Time Interval
You can configure the keepalive time interval, which is the frequency at which the Cisco IOS software sends messages to itself (Ethernet and Token Ring) or to the other end (serial and tunnel), to ensure that a network interface is alive. The interval is adjustable in 1-second increments down to 1 second. An interface is declared down after three update intervals have passed without receiving a keepalive packet unless the retry value is set higher.
Setting the keepalive timer to a low value is very useful for rapidly detecting Ethernet interface failures (transceiver cable disconnecting, cable not terminated, and so on).
Line Failure
A typical serial line failure involves losing Carrier Detect (CD) signal. Because this sort of failure is typically noticed within a few milliseconds, adjusting the keepalive timer for quicker routing recovery is generally not useful.
Keepalive Packets with Tunnel Interfaces
GRE keepalive packets may be sent from both sides of a tunnel, or from just one side. If they are sent from both sides, the period and retry parameters can be different at each side of the link. If you configure keepalives on only one side of the tunnel, the tunnel interface on the sending side might perceive the tunnel interface on the receiving side to be down because the sending interface is not receiving keepalives. From the receiving side of the tunnel, the link appears normal because no keepalives were enabled on the second side of the link.
Dropped Packets
Keepalive packets are treated as ordinary packets, so it is possible that they will be dropped. To reduce the chance that dropped keepalive packets will cause the tunnel interface to be taken down, increase the number of retries.
Note
delay the smaller keepalive packets long enough to cause the line protocol to go down. You may
need to experiment to determine the best values to use for the timeout and the number of
retry attempts.GRE Tunnels with IPSec
When using GRE with IPSec, the keepalives are encrypted like any other traffic. As with user data packets, if the IKE and IPSec security associations are not already active on the GRE tunnel, the first GRE keepalive packet will trigger IKE/IPSec initialization.
Examples
The following example shows how to set the keepalive interval to 3 seconds:
Router(config)# interface ethernet 0Router(config-if)# keepalive 3The following example shows how to set the keepalive interval to 3 seconds and the retry value to 7:
Router(config)# interface tunnel 1Router(config-if)# keepalive 3 7mode y-cable
To access the command mode that allows you to manually control the relays on the VWIC card, use the mode y-cable command.
mode y-cable
Syntax Description
This command has no parameters, it invokes the y-cable mode.
Defaults
There are no default settings or behaviors.
Command Modes
Redundancy configuration
Command History
12.2(8)MC2
This command was introduced.
12.2(15)MC1
This command was incorporated in Cisco IOS 12.2(15)MC1.
12.3(11)T
This command was incorporated in Cisco IOS 12.3(11)T.
Examples
The following example enables y-cable mode.
mode y-cableRelated Commands
msisdn suppression
To specify that the GGSN overrides the mobile station integrated services digital network (MSISDN) number with a pre-configured value in its authentication requests to a RADIUS server, use the msisdn suppression access point configuration command. To enable the GGSN to send the MSISDN number in authentication requests to a RADIUS server, use the no form of the command.
msisdn suppression [value]
no msisdn suppression [value]
Syntax Description
Defaults
The MSISDN number is suppressed, and no ID string is sent to the RADIUS server in place of the MSISDN number.
Command Modes
Access point configuration
Command History
Usage Guidelines
Certain countries have privacy laws which prohibit service providers from identifying the MSISDN number of mobile stations in authentication requests. Use the msisdn suppression command to specify a value that the GGSN sends in place of the MSISDN number in its authentication requests to a RADIUS server. If no value is configured, then no number is sent to the RADIUS server.
To use the msisdn suppression command, you must configure a RADIUS server either globally or at the access point and specify non-transparent access mode.
Examples
The following example will override the MSISDN ID sent in the create request and will not send any ID to the RADIUS server:
gprs access-point-list abcaccess-point 1radius-server 192.168.1.1access-mode non-transparentmsisdn suppressionRelated Commands
nas
To add an access point or router to the list of devices that use the local authentication server, use the nas command in local RADIUS server configuration mode. To remove the identity of the network access server (NAS) that is configured on the local RADIUS server, use the no form of this command
nas ip-address key shared-key
no nas ip-address key shared-key
Syntax Description
Defaults
No default behavior or values
Command Modes
Local RADIUS server configuration
Command History
Examples
The following command adds the access point having the IP address 192.168.12.17 to the list of devices that use the local authentication server, using the shared key "shared256."
nas 192.168.12.17 key shared256Related Commands
nbns primary
To specify a primary (and backup) NBNS to be sent in create PDP responses at the access point, use the nbns primary access-point configuration command. To remove the NBNS from the access-point configuration, use the no form of this command
nbns primary ip-address [secondary ip-address]
Syntax Description
ip-address
IP address of the primary NBNS.
secondary ip-address
(Optional) Specifies the IP address of the backup NBNS.
Defaults
No default behavior or values.
Command Modes
Access-point configuration
Command History
12.3(2)XB
This command was introduced.
12.3(8)T
This command was incorporated in Cisco IOS Release 12.3(8)T.
Usage Guidelines
Use the nbns primary command to specify the primary (and backup) NBNS at the access point level.
This feature is benefits address allocation schemes where there is no mechanism to obtain these address. Also, for a RADIUS-based allocation scheme, it prevents the operator from having to configure a NBNS and DNS under each user profile.
The NBNS address can come from three possible sources: DHCP server, RADIUS server, or local APN configuration. The criterium for selecting the NBNS address depends on the IP address allocation scheme configured under the APN. Depending on the configuration, the criterium for selecting the DNS and NBNS addresses is as follows:
1.
2.
3.
4.
Note
Examples
The following example specifies a primary and secondary NBNS at the access point level:
access-point 2access-point-name xyz.comnbns primary 10.60.0.1 secondary 10.60.0.2exitRelated Commands
Specifies a dynamic address allocation method using IP address pools for the current access point.
Specifies a primary (and backup) DNS at the access point level.
network-behind-mobile
To enable an access point to support routing behind the mobile station (MS), use the network-behind-mobile access-point configuration command. To disable support for routing behind the MS, use the no form of this command.
network-behind-mobile
no network-behind-mobile
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values.
Command Modes
Access-point configuration
Command History
Usage Guidelines
Use the network-behind-mobile access-point configuration command to enable an access point to support routing behind the MS. The routing behind the MS feature enables the routing of packets to IP addresses that do not belong to the PDP context (the MS), but exist behind it. The network address of the destination can be different than the MS address.
Before enabling routing behind the MS, the following requirements must be met:
•
•
When configured, the Framed-Route attribute is automatically downloaded to the GGSN during the authentication and authorization phase of the PDP context creation. If routing behind the MS is not enabled, the GGSN ignores the Framed-Route attribute. If multiple Framed-Route attributes have been configured for an MS, the GGSN uses the first attribute configured. When the MS session is no longer active, the route is deleted.
•
•
Examples
The following example shows how to enable support for routing behind the MS at access point 200:
gprs access-point-list abcaccess-point 200network-behind-mobileRelated Commands
security verify
Specifies the verification of source and/or destination addresses.
network-request-activation
To enable an access point to support network-initiated PDP requests, use the network-request-activation access-point configuration command. To disable support for network-initiated PDP requests at an access point, use the no form of this command.
network-request-activation
no network-request-activation
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values.
Command Modes
Access-point configuration
Command History
Usage Guidelines
In addition to configuring the network-request-activation command, you must configure the following other commands to support network-initiated PDP requests on the GGSN:
•
•
Examples
The following example shows how to enable support for network-initiated PDP requests at access point 200:
gprs access-point-list abcaccess-point 200network-request-activationRelated Commands
ppp accm
To specify the Asynchronous Control Character Map (ACCM) to be negotiated with a mobile station or sent to a peer in PPP outbound requests, use the ppp accm command in interface configuration mode. To restore the default state, use the no form of this command.
ppp accm hex-number
no ppp accm
Syntax Description
Defaults
0xA0000.
Command Modes
Interface configuration
Command History
12.1(3)XS
This command was introduced.
12.2
This command was integrated into Cisco IOS Release 12.2.
Usage Guidelines
The ACCM is a four octet hexadecimal number that is sent to a peer in a PPP outbound Config-Request packet, informing the peer of which characters need to be escaped during transmission of Asynchronous HDLC (AHDLC) frames containing control characters. The escaped characters set by the ppp accm command are useful for allowing data to pass uninterpreted through a network that would normally interpret the control sequences as a command.
For example, the ^Q and ^S characters are software flow control commands used by asynchronous modems to start and stop data transmissions. To allow these characters to be sent as part of a data stream and not be interpreted as control codes by intervening devices, the characters must be escaped, and the ppp accm command specifies which characters to use.
The TIA/EIA/IS-835-B requires that the PDSN propose an ACCM of 0x00000000. To be compliant with TIA/EIA/IS-835-B, ppp accm 00000000 must be configured on the virtual template interface on Cisco PDSN.
The ppp accm command is meaningful only on asynchronous interfaces. If entered on other interface types, it will be ignored.
Examples
In the following example, all characters can be transmitted intact to the receiver so that it is not necessary for the transmitter to escape anything:
interface async 0encapsulation pppppp accm 0Related Commands
ppp authentication
To enable at least one PPP authentication protocol and to specify the order in which the protocols are selected on the interface, use the ppp authentication command in interface configuration mode. To disable this authentication, use the no form of this command.
ppp authentication {protocol1 [protocol2...]} [if-needed] [list-name | default] [callin] [one-time] [optional]
no ppp authentication
Syntax Description
protocol1 [protocol2...]
At least one of the keywords described in Table 5.
if-needed
(Optional) Used with TACACS and extended TACACS. Does not perform Challenge Handshake Authentication Protocol (CHAP) or Password Authentication Protocol (PAP) authentication if authentication has already been provided. This option is available only on asynchronous interfaces.
list-name
(Optional) Used with authentication, authorization, and accounting (AAA). Specifies the name of a list of methods of authentication to use. If no list name is specified, the system uses the default. The list is created with the aaa authentication ppp command.
default
(Optional) Name of the method list created with the aaa authentication ppp command.
callin
(Optional) Authentication on incoming (received) calls only.
one-time
(Optional) The username and password are accepted in the username field.
optional
(Optional) Accepts the connection even if the peer refuses to accept the authentication methods that the router has requested.
Defaults
PPP authentication is not enabled.
Command Modes
Interface configuration
Command History
Usage Guidelines
When you enable PAP, CHAP, or Extensible Authentication Protocol (EAP) authentication (or all three methods), the local router requires the remote device to prove its identity before allowing data traffic to flow. PAP authentication requires the remote device to send a name and a password, which is checked against a matching entry in the local username database or in the remote security server database. CHAP authentication sends a challenge message to the remote device. The remote device encrypts the challenge value with a shared secret and returns the encrypted value and its name to the local router in a Response message. The local router attempts to match the name of the remote device with an associated secret stored in the local username or remote security server database; it uses the stored secret to encrypt the original challenge and verify that the encrypted values match. EAP works much as CHAP does, except that identity request and response packets are exchanged when EAP starts.
You can enable CHAP, Microsoft CHAP (MS-CHAP), PAP, or EAP in any order. If you enable all four methods, the first method specified is requested during link negotiation. If the peer suggests using the second method, or refuses the first method, the second method is tried. Some remote devices support only one method. Base the order in which you specify methods on the ability of the remote device to correctly negotiate the appropriate method and on the level of data-line security you require. PAP usernames and passwords are sent as clear text strings, which can be intercepted and reused.
Caution
Table 5 lists the protocols used to negotiate PPP authentication.
Enabling or disabling PPP authentication does not affect the ability of the local router to authenticate itself to the remote device.
If you are using autoselect on a tty line, you can use the ppp authentication command to turn on PPP authentication for the corresponding interface.
MS-CHAP is the Microsoft version of CHAP. Like the standard version of CHAP, MS-CHAP is used for PPP authentication; authentication occurs between a personal computer using Microsoft Windows NT or Microsoft Windows 95 and a Cisco router or access server acting as a network access server.
To configure Cisco PDSN in compliance with the TIA/EIA/IS-835-B standard, you must configure the PDSN virtual template as follows:
ppp authentication chap pap optionalExamples
The following example configures virtual-template interface 4:
interface virtual-template 4ip unnumbered loopback0ppp authentication chap pap optionalThe following example enables CHAP on asynchronous interface 4 and uses the authentication list MIS-access:
interface async 4encapsulation pppppp authentication chap MIS-accessThe following example enables EAP on dialer interface 1:
interface dialer 1encapsulation pppppp authentication eapRelated Commands
ppp mux
To enable PPP multiplexing/demultiplexing, use the ppp mux command in interface configuration mode. To disable PPP multiplexing/demultiplexing, use the no form of this command.
ppp mux
no ppp mux
Syntax Description
This command has no parameters.
Defaults
PPP multiplexing/demultiplexing is disabled by default.
Command Modes
Interface configuration
Command History
Examples
The following example enables PPP multiplexing/demultiplexing.
ppp muxRelated Commands
ppp mux delay
To set the maximum time the processor can wait before sending a superframe, use the ppp mux delay command in interface configuration mode. To set the maximum delay to the default, use the no form of this command.
ppp mux delay integer
no ppp mux delay
Syntax Description
Defaults
Cisco MWR 1941-DC router—The default maximum delay is 0, which indicates that a superframe will be sent when the transmit queue is full.
MGX-RPM-1FE-CP back card—The default maximum delay is 800.
Command Modes
Interface configuration
Command History
Usage Guidelines
To use this command, you must first enable PPP multiplexing/demultiplexing.
MGX-RPM-1FE-CP Back Card
When the ppp mux delay command is configured, the maximum number of microseconds that the processor can wait resolves to the nearest 200-microsecond increment. For example, if ppp mux delay 302 is specified, the actual maximum number of microseconds that the processor can wait before sending out a PPP superframe is 400. If ppp mux delay 298 is specified, the actual maximum number of microseconds that the processor can wait before sending out a PPP superframe is 200.
Examples
The following example sets the maximum delay to 5 microseconds on the MWR 1941-DC router.
ppp mux delay 5The following example sets the maximum delay to 200 microseconds on the MGX-RPM-1FE-CP back card.
ppp mux delay 200Related Commands
ppp mux frame
To set the maximum length (in bytes) of the PPP superframes, use the ppp mux frame command in interface configuration mode. To set the maximum length to the default, use the no form of this command.
ppp mux frame integer
no ppp mux frame
Syntax Description
integer
The maximum number of bytes in any multiplexed PPP superframe.
Possible values:
•
•
Defaults
The default maximum length is 197.
Command Modes
Interface configuration
Command History
Usage Guidelines
To use this command, you must first enable PPP multiplexing/demultiplexing.
Examples
The following example sets the maximum superframe length to 80 bytes.
ppp mux frame 80Related Commands
ppp mux pid
To set the default receiving PPP protocol ID, use the ppp mux pid command in interface configuration mode. To remove this configuration, use the no form of this command.
ppp mux pid integer
no ppp mux pid
Syntax Description
Defaults
The default is 33 (0x21), which is the IP protocol.
Command Modes
Interface configuration
Command History
Usage Guidelines
To use this command, you must first enable PPP multiplexing/demultiplexing.
Examples
The following example sets the default PPP protocol ID to 8.
ppp mux pid 8Related Commands
ppp mux subframe count
To set the maximum number of PPP subframes that can be contained in a superframe, use the ppp mux subframe count command in interface configuration mode. To set the maximum number to the default, use the no form of this command.
ppp mux subframe count integer
no ppp mux subframe count
Syntax Description
Defaults
The default maximum is 15.
Command Modes
Interface configuration
Command History
Usage Guidelines
To use this command, you must first enable PPP multiplexing/demultiplexing.
Examples
The following example sets the maximum subframe count to 20 bytes.
ppp mux subframe count 20Related Commands
ppp mux subframe length
To set the maximum length (in bytes) of the PPP subframes, use the ppp mux subframe length command in interface configuration mode. To set the maximum length to the default, use the no form of this command.
ppp mux subframe length integer
no ppp mux subframe length
Syntax Description
integer
The maximum number of bytes in any single subframe that is to be multiplexed.
Possible values:
•
•
Defaults
The default maximum length is 195.
Command Modes
Interface configuration
Command History
12.2(8)MC2
This command was introduced.
12.3(11)T
This command was incorporated in Cisco IOS 12.3(11)T.
Usage Guidelines
To use this command, you must first enable PPP multiplexing/demultiplexing. The maximum length of the subframe should be the maximum length of the superframe minus the length of the L2 header.
Examples
The following example sets the maximum subframe length to 20 bytes.
ppp mux subframe length 20Related Commands
ppp-regeneration
To enable an access point to support PPP regeneration, use the ppp-regeneration access-point configuration command. To disable support for PPP regeneration at an access point, use the no form of this command.
ppp-regeneration [max-session number] [setup-time seconds]
no ppp-regeneration [max-session number] [setup-time seconds]
Syntax Description
Defaults
The default max-session value is 65535.
The default setup-time is 60 seconds.
Command Modes
Access-point configuration
Command History
Usage Guidelines
Use the ppp-regeneration command to enable an access point to support PPP regeneration and to specify parameters for PPP regeneration sessions on the GGSN.
Note
The maximum setup-time value should allow for the total amount of time required to create the PPP virtual access (VA) and to establish a PPP session. If the setup-time is reached before the PPP IP Control Protocol (IPCP) is up, the GGSN tears down the L2TP session, PPP VA, and PDP context.
The method of PPP configured to forward packets beyond the terminal equipment and mobile termination affects the maximum number of PDP contexts supported on the GGSN. For more information, see the "Configuring PPP Support on the GGSN" chapter of the Cisco IOS Mobile Wireless Configuration Guide for Cisco IOS Release 12.2(8)YD.
Examples
The following example shows a partial GGSN configuration for PPP regeneration, where PPP regeneration is enabled at access point 1. It specifies a maximum of 100 PPP regeneration sessions, with a limit of 30 seconds to create the PPP VA and establish a PPP session:
gprs access-point-list abcaccess-point 1access-point-name gprs.corporate.comppp-regeneration max-session 100 setup-time 30exitRelated Commands
radius attribute nas-id
To specify that the GGSN include the NAS-Identifier (attribute 32) in access requests at an APN, use the following access-point configurationcommand. To disable this configuration, use the no form of this command.
radius attribute nas-id format
no radius attribute nas-id
Syntax Description
format
String sent in attribute 32 containing an IP address (%i), a hostname (%h), and a domain name (%d).
Defaults
The default is to not send the NAS-Identifier in access requests.
Command Modes
Access point configuration
Command History
12.3(2)XB
This command was introduced.
12.3(8)T
This command was incorporated in Cisco IOS Release 12.3(8)T.
Usage Guidelines
Use the radius attribute nas-id command to include the NAS-Identifier in access requests at an APN.
This command overrides the configuration of the radius-server attribute 32 include-in-access-req format global configuration command.
Examples
The following example configures the GGSN to send the NAS-Identifier in access requests at the APN:
gprs access-point-list abcaccess-point 1radius attribute nas-id %hRelated Commands
radius attribute suppress imsi
To specify that the GGSN suppress the Third Generation Partnership Project (3GPP) vendor-specific attribute (VSA) 3GGP-IMSI number in its authentication and accounting requests to a RADIUS server, use the radius attribute suppress imsi access point configuration command. To enable the GGSN to send the 3GPP VSA 3GPP-IMSI number in authentication and accounting requests to a RADIUS server, use the no form of the command.
radius attribute suppress imsi
no radius attribute suppress imsi
Syntax Description
This command has no arguments or keywords.
Defaults
The default is to send the 3GPP VSA 3GPP-IMSI number in authentication and accounting requests to a RADIUS server.
Command Modes
Access point configuration
Command History
Usage Guidelines
Use the radius attribute suppress imsi command to have GGSN suppress the 3GPP VSA 3GPP-IMSI number in its authentication and accounting requests to a RADIUS server.
Examples
The following example will not send the 3GPP VSA 3GPP-IMSI to the RADIUS server:
gprs access-point-list abcaccess-point 1radius attribute suppress imsiRelated Commands
radius attribute suppress qos
To specify that the GGSN suppress the 3GPP VSA 3GPP-GPRS-QoS-Profile in its authentication and accounting requests to a RADIUS server, use the radius attribute suppress qos access point configuration command. To enable the GGSN to send the 3GPP VSA 3GPP-GPRS-QoS-Profile in authentication and accounting requests to a RADIUS server, use the no form of the command.
radius attribute suppress qos
no radius attribute suppress qos
Syntax Description
This command has no arguments or keywords.
Defaults
The default is to send the 3GPP VSA 3GPP-GPRS-QoS-Profile in authentication and accounting requests to a RADIUS server.
Command Modes
Access point configuration
Command History
12.2(8)B
This command was introduced.
12.3(4)T
This command was incorporated in Cisco IOS Release 12.3(4)T.
12.3(8)T
This command was incorporated in Cisco IOS Release 12.3(8)T.
Usage Guidelines
Use the radius attribute suppress qos command to have GGSN suppress the 3GPP VSA 3GPP-GPRS-QoS-Profile in its authentication and accounting requests to a RADIUS server.
Examples
The following example will not send the 3GPP VSA 3GPP-GPRS-QoS-Profile to the RADIUS server:
gprs access-point-list abcaccess-point 1radius attribute suppress qosRelated Commands
radius attribute suppress sgsn-address
To specify that the GGSN suppress the 3GPP VSA 3GPP-SGSN-Address in its authentication and accounting requests to a RADIUS server, use the radius attribute suppress sgsn-address access point configuration command. To enable the GGSN to send the 3GPP VSA 3GPP-SGSN-Address in authentication and accounting requests to a RADIUS server, use the no form of the command.
radius attribute suppress sgsn-address
no radius attribute suppress sgsn-address
Syntax Description
This command has no arguments or keywords.
Defaults
The default is to send the 3GPP VSA 3GPP-SGSN-Address in authentication and accounting requests to a RADIUS server.
Command Modes
Access point configuration
Command History
12.2(8)B
This command was introduced.
12.3(4)T
This command was incorporated in Cisco IOS Release 12.3(4)T.
12.3(8)T
This command was incorporated in Cisco IOS Release 12.3(8)T.
Usage Guidelines
Use the radius attribute suppress sgsn-address command to have GGSN suppress the 3GPP VSA 3GPP-SGSN-Address in its authentication and accounting requests to a RADIUS server.
Examples
The following example will not send the 3GPP VSA 3GPP-SGSN-Address to the RADIUS server:
gprs access-point-list abcaccess-point 1radius attribute suppress sgsn-addressRelated Commands
radius-server local
To enable the access point or wireless-aware router as a local authentication server and to enter into configuration mode for the authenticator, use the radius-server local command in global configuration mode. To remove the local RADIUS server configuration from the router or access point, use the no form of this command.
radius-server local
no radius-server local
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values
Command Modes
Global configuration
Command History
Examples
The following example shows that the access point is being configured to serve as a local authentication server:
Router (config)# radius-server localRelated Commands
reauthentication time
To enter the time limit after which the authenticator should reauthenticate, use the reauthentication time command in local RADIUS server group configuration mode. To remove the requirement that users reauthenticate after the specified duration, use the no form of this command.
reauthentication time seconds
no reauthentication time seconds
Syntax Description
Defaults
The default setting is 0 seconds, which means that group members are not required to reauthenticate.
Command Modes
Local RADIUS server group configuration
Command History
Examples
The following example shows that the time limit after which the authenticator should reauthenticate is 30 seconds:
reauthentication time 30Related Commands
redirect all ip
To redirect all traffic to an external device, use the redirect all ip access-point configuration command. To disable the redirection of all traffic, use the no form of this command.
redirect intermobile ip ip-address
no redirect intermobile ip ip-address
Syntax Description
Defaults
Disabled
Command Modes
Access-point configuration
Command History
12.3(2)XB2
This command was introduced.
12.3(8)T
This command was incorporated in Cisco IOS Release 12.3(8)T.
Usage Guidelines
Use the redirect all ip access-point command to redirect all traffic to an IP address.
The redirect all traffic feature enables you to do the following:
•
If redirecting traffic using the Mobile-to-Mobile Redirect feature, only packets for which the destination address belongs to an MS that is active on the same GGSN can be redirected. If the receiving MS has no PDP context in the GGSN where the sending MS PDP context is created, the packets are dropped.
•
Examples
The following example redirects traffic to 5.5.5.13:
redirect all ip 5.5.5.13Related Commands
gprs plmn ip address
Specifies the IP address range of a PLMN.
security verify
Specifies the verification of source and/or destination addresses.
redirect intermobile ip
To redirect mobile-to-mobile traffic to an external device, use the redirect intermobile interface ip access-point configuration command. To disable the redirection of mobile-to-mobile traffic, use the no form of this command.
redirect intermobile ip ip-address
no redirect intermobile ip ip-address
Syntax Description
ip-address
IP address of the external device to which you want to redirect mobile-to-mobile traffic.
Defaults
Disabled
Command Modes
Access-point configuration
Command History
12.2(8)B
This command was introduced.
12.3(4)T
This command was incorporated in Cisco IOS Release 12.3(4)T.
12.3(8)T
This command was incorporated in Cisco IOS Release 12.3(8)T.
Usage Guidelines
Use the redirect intermobile ip access-point command to redirect mobile-to-mobile traffic to an external device (such as an external firewall) for verification.
Redirection of intermobile traffic does not occur on an ingress APN unless the TPDUs are exiting the same APN. In addition, redirection of TPDUs tunneled by L2TP from the ingress APN to the LNS of the PDN does not occur.
Note
Examples
The following example redirects mobile-to-mobile traffic to 5.5.5.13:
redirect intermobile ip 5.5.5.13Related Commands
gprs plmn ip address
Specifies the IP address range of a PLMN.
security verify
Specifies the verification of source and/or destination addresses.
redundancy
To enter redundancy configuration mode, use the redundancy command in global configuration mode. To disable, use the no form of this command.
redundancy
no redundancy
Syntax Description
This command has no arguments or keywords.
Defaults
Redundancy is disabled.
Command Modes
Global configuration
Command History
Usage Guidelines
Use the redundancy command to enter redundancy configuration mode where you can define aspects of redundancy, such as shelf redundancy for the Cisco AS5800 universal access server.
Examples
Cisco AS5800 Example
The following example assigns the configured router shelf to the redundancy pair designated as 25. This command must be issued on both router shelves in the redundant router-shelf pair:
Router(config)# redundancyRouter(config-red)# failover group-number 25Cisco MWR 1941-DC Router Example
The following example enables redundancy mode on the Cisco MWR 1941-DC router:
Router(config)# redundancyRelated Commands
security verify
To enable the GGSN to verify the IP verification of IP addresses in TPDUs, use the security verify access-point configuration command. To disable the verification of IP addresses, use the no form of this command.
security verify {source | destination}
no security verify {source | destination}
Syntax Description
Defaults
Disabled
Command Modes
Access-point configuration
Command History
12.2(8)B
This command was introduced.
12.3(4)T
This command was incorporated in Cisco IOS Release 12.3(4)T.
12.3(8)T
This command was incorporated in Cisco IOS Release 12.3(8)T.
Usage Guidelines
Use the security verify source access point configuration command to configure the GGSN to verify the source IP address of an upstream TPDU against the address previously assigned to an MS.
When the security verify source command is configured on an APN, the GGSN verifies the source address of a TPDU before GTP will accept and forward it. If the GGSN determines that the address differs from that previously assigned to the MS, it drops the TPDU and accounts it as an illegal packet in its PDP context and APN. Configuring the security verify source access point configuration command protects the GGSN from faked user identities.
Use the security verify destination access point configuration command to have the GGSN verify the destination addresses of upstream TPDUs against global lists of PLMN addresses specified using the gprs plmn ip address command. If the GGSN determines that a destination address of a TPDU is within the range of a list of addresses, it drops the TPDU. If it determines that the TPDU contains a destination address that does not fall within the range of a list, it forwards the TPDU to its final destination.
Note
Examples
The following example enables the verification of source IP addresses received in upstream TPDUs:
security verify sourceRelated Commands
service cdma pdsn
To enable PDSN service, use the service cdma pdsn command in global configuration mode. To disable PDSN service, use the no form of this command.
service cdma pdsn
no service cdma pdsn
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values.
Command Modes
Global Configuration
Command History
12.1(3)XS
This command was introduced.
12.3(4)T
This command was incorporated in Cisco IOS Release 12.3(4)T.
Usage Guidelines
This command must be configured to enable CDMA PDSN on the router.
Examples
The following example enables PDSN service:
service cdma pdsnRelated Commands
show cdma pdsn pcf brief
Displays a table of all PCFs that have R-P tunnels to the PDSN.
show cdma pdsn session
Displays PDSN session information.
service gprs ggsn
To configure a router for gateway GPRS support node functions, use the service gprs ggsn command. To disable GGSN functionality, use the no form of this command.
service gprs ggsn
no service gprs ggsn
Syntax Description
This command has no keywords or arguments.
Defaults
Disabled
Command Modes
Global configuration
Command History
Usage Guidelines
Use the service gprs ggsn command to configure the router as a gateway GPRS support node.
Examples
The following example configures the router as a GGSN:
service gprs ggsnservice gprs gtp-director
To configure a router for GTP Director Module (GDM) functions, use the service gprs gtp-director command. To disable GDM functionality, use the no form of this command.
service gprs gtp-director
no service gprs gtp-director
Syntax Description
This command has no keywords or arguments.
Defaults
Disabled
Command Modes
Global configuration
Command History
Usage Guidelines
Use the service gprs gtp-director command to configure the router for GTP director module (GDM) services. The router cannot be configured to provide GGSN and GDM services at the same time.
Examples
The following example configures the router as a GTP director:
service gprs gtp-directorRelated Commands
session idle-time
To specify the time that the GGSN waits before purging idle mobile sessions for the current access point, use the session idle-time access-point configuration command. To disable the idle timer at the access point, use the no form of this command.
session idle-time number
no session idle-time number
Syntax Description
Defaults
No session idle timer is configured on the access point.
Command Modes
Access-point configuration
Command History
Usage Guidelines
The GGSN implements the idle timer in 3 ways. These implementations are listed in the order in which the GGSN processes them.
•
•
•
The session idle-time command value overrides the value configured in the gprs idle-pdp-context purge-timer command for that access-point.
When the session reaches the timeout value, the PDP context is deleted.
Use the show gprs gtp pdp-context tid command to view the session idle-time value. The value is shown in the "gtp pdp idle time" field.
Examples
The following example specifies that the GGSN waits for 5 hours before purging idle time sessions for access-point 1. The GGSN waits for 60 hours before purging idle time sessions for all access points except access-point 1:
gprs access-point-list abcaccess-point 1access-point-name gprs.pdn1.comsession idle-time 5gprs idle-pdp-context purge-timer 60Related Commands
Specifies the time that the GGSN waits before purging idle mobile sessions.
Displays a list of the currently active PDP contexts (mobile sessions).
Posted: Mon Mar 28 00:09:55 PST 2005
All contents are Copyright © 1992--2005 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.
