This document describes how to implement the protection features that are available for Gateways (GWs) and neighboring network elements on the Cisco Aggregated Services Router (ASR) 5x00 Series in order to protect the overall network performance.
Congestion Control is a generic self-protection feature. It is used in order to protect the system against utilization surges of these resources:
When the utilization exceeds the pre-defined thresholds, all of the new calls (Packet Data Protocol (PDP) activations, Packet Data Network (PDN) session activations) are dropped or rejected, dependent upon the configuration.
Here is an example that shows how to monitor the overall Data Processing Card (DPC) utilization:
congestion-control threshold system-cpu-utilization 85
congestion-control threshold system-memory-utilization 85
congestion-control policy ggsn-service action drop
congestion-control policy sgw-service action drop
congestion-control policy pgw-service action drop
This feature protects the Packet GW (P-GW)/Gateway GPRS Supporting Node (GGSN) processes from transmission surges and network element failures. In a P-GW/Serving GPRS Supporting Node (SGSN), the main bottleneck is related to the user data processing, such as the session manager utilization and the overall DPC CPU and memory utilization.
A No value is configured on the SGSN/Mobility Management Entity (MME) in order to throttle the inbound GPRS Tunnelling Protocol-Control (GTP-C) messages when the network overload protection is activated.
This feature helps control the rate of inbound/outbound messages on the P-GW/GGSN, which helps to ensure that the P-GW/GGSN is not overwhelmed by the GTP control plan messages. In addition, it helps to ensure that the P-GW/GGSN does not overwhelm the GTP-C peer with the GTP control plane messages. This feature requires that the GTP (Version 1 (v1) and Version 2 (v2)) control messages be shaped/policed over the Gn/Gp and S5/S8 interfaces. This feature covers the overload protection of the P-GW/GGSN nodes and the other external nodes with which it communicates. Throttling is done only for session-level control messages, so the path management messages are not rate limited at all.
The external node overload can occur in a scenario where the P-GW/GGSN generates signaling requests at a higher rate than the other nodes can handle. Also, if the inbound rate is high at the P-GW/GGSN node, it might flood the external node. For this reason, the throttling of both inbound and outbound control messages is required. For protection of the external nodes from an overload due to the P-GW/GGSN control signaling, a framework is used in order to shape and police the outbound control messages to the external interfaces.
Enter this command in order to configure the ingress GTP-C message throttling:
gtpc overload-protection Ingress
This configures the overload protection of the GGSN/PGW by throttling inbound GTPv1 and GTPv2 control messages over the Gn/Gp (GTPv1) or S5/S8 (GTPv2) interface with the other parameters for the services that are configured in a context and applied to the GGSN and PGW.
When you enter the previous command, this prompt is generated:
[context_name]host_name(config-ctx)# gtpc overload-protection ingress
{msg-rate msg_rate} [delay-tolerance dur] [queue-size size]
[no] gtpc overload-protection Ingress
Here are some notes about this syntax:
You can use this command in order to enable the GTP inbound control message throttling for the GGSN/PGW services that are configured in the same context. As an example, this command enables the inbound GTP control messages in a context with a message rate of 1,000 per second, a message queue size of 10,000, and a delay of one second:
gtpc overload-protection ingress msg-rate 1000 delay-tolerance 1 queue-size 10000
Many neighbor network elements use their own mechanisms in order to protect themselves, and additional network overload protection on the ASR5x00 side might not be needed. Protection of the neighbor network elements might be required in cases where the overall network stability can be reached only when message throttling is applied on the egress side.
This feature protects the S6a and S13 interfaces in the egress direction. It protects the Home Subscriber Server (HSS), the Diameter Routing Agent (DRA), and the Equipment Identity Register (EIR). The feature uses the Rate Limiting Function (RLF).
Consider these important notes when you apply the diameter endpoint configuration:
Here is the command syntax that is used in order to configure diameter throttling on an S6a interface:
[context_na>me]host_name(config-ctx-diameter)#>peer [*] peer_name [*]
[ realm realm_name ] { address ipv4/ipv6_address [ [ port port_number ]
[connect-on-application-access] [ send-dpr-before-disconnect disconnect-cause
disconnect_cause ] [ sctp ] ] + | fqdn fqdn [ [ port port_number ]
[ send-dpr-before-disconnect disconnect-cause disconnect_cause ]
[ rlf-template rlf_template_name ] ] }
no peer peer_name [ realm realm_name ]
Here are some notes about this syntax:
This feature protects the Gx and Gy interfaces in the egress direction. It protects the Policy and Charging Rules Function (PCRF) and the Online Charging System (OCS) and uses RLF.
Consider these important notes when you apply the diameter endpoint configuration:
This command is used in order to configure the network overload protection:
[context_name]host_name(config-ctx-diameter)# rlf-template rlf_template_name
You might consider the use of the RLF for diameter interfaces. Here is an example configuration:
rlf-template rlf1
msg-rate 1000 burst-size 100
threshold upper 80 lower 60
delay-tolerance 4
#exit
diameter endpoint Gy
use-proxy
origin host Gy address 10.55.22.3
rlf-template rlf1
peer peer1 realm foo.com address 10.55.22.1 port 3867 rlf-template rlf2
peer peer2 realm fo.com address 10.55.22.1 port 3870
#exit
Here are some notes about this configuration:
no peer peer2 realm foo.com
peer peer2 realm foo.com address 10.55.22.1 port 3867
show rlf-context-statistics diamproxy
show rlf-context-statistics diamproxy verbose
The page throttling feature limits the number of paging messages that are sent out of the SGSN. It provides flexibility and control to the operator, who can now reduce the number of paging messages that are sent out from the SGSN based on the network conditions. In some locations, the amount of paging messages that are initiated from the SGSN is very high due to bad radio conditions. A higher number of paging messages results in the consumption of bandwidth in the network. This feature provides a configurable rate limit, in which the paging message is throttled at these levels:
This feature improves the bandwidth consumption on the radio interface.
Here is an example of the paging process with 2G access and rate limiting:
Here is an example of the paging process with 3G access and rate limiting:
The commands that are described in this section are used in order to configure the page throttling feature. These CLI commands are used in order to associate/remove the RLF template for page throttling at the global level, the NSE level, and the RNC level on the SGSN.
Map the RNC Name to the RNC Identifier
The interface command is used in order to configure the mapping between the RNC Identifier (ID) and the RNC name. You can configure the paging-rlf-template either by RNC name or RNC ID. Here is the syntax that is used:
config
sgsn-global
interface-management
[ no ] interface {gb
peer-nsei | iu peer-rnc} {name <value> | id <value>}
exit
Here is an example configuration:
[local]asr5000# configure
[local]asr5000(config)# sgsn-global
[local]asr5000(config-sgsn-global)# interface-management
[local]asr5000(config-sgsn-interface-mgmt)# interface
iu peer-rnc id 250 name bng_rnc1
[local]asr5000(config-sgsn-interface-mgmt)# end
[local]asr5000#
Associate a Paging RLF Template
This command allows the SGSN to associate an RLF template either at the global level, which limits the paging messages that are initiated across both the 2G (NSE-level) and 3G (RNC-level) access, or at the per-entity level, which is either at the RNC level for 3G access or at the NSE level for 2G access. Here is the syntax that is used:
config
sgsn-global
interface-management
[no] paging-rlf-template {template-name <template-name>} {gb
peer-nsei | iu peer-rnc} {name <value> | id <value>}
exit
Here is an example configuration:
[local]asr5000(config)# sgsn-global
[local]asr5000(config-sgsn-global)# interface-management
[local]asr5000(config-sgsn-interface-mgmt)# paging-rlf-template
template-name rlf1
[local]asr5000(config-sgsn-interface-mgmt)# end
[local]asr5000#
[local]asr5000# configure
[local]asr5000(config)# sgsn-global
[local]asr5000(config-sgsn-global)# interface-management
[local]asr5000(config-sgsn-interface-mgmt)# paging-rlf-template
template-name rlf2 gb peer-nsei id 1
[local]asr5000(config-sgsn-interface-mgmt)# end
[local]asr5000#
[local]asr5000# configure
[local]asr5000(config)# sgsn-global
[local]asr5000(config-sgsn-global)# interface-management
[local]asr5000(config-sgsn-interface-mgmt)# paging-rlf-template
template-name rlf2 iu peer-rnc name bng_rnc1
[local]asr5000(config-sgsn-interface-mgmt)# end
[local]asr5000#