The Call Admission Control (CAC) feature is configured to protect the ASR 1000 processing resources that must be configured. CAC can restrict the media bandwidth dedicated to active calls when CPU utilization exceeds the configured threshold.

This section provides the following examples for configuring CAC:

Configuring a PPPoE Session

router(config)# call admission new-model
router(config)# call admission limit 1000
router(config)# call admission cpu-limit 80
router(config)# call admission pppoe 10 1

Configuring a PPPoA Session

router(config)# call admission new-model
router(config)# call admission limit 1000
router(config)# call admission cpu-limit 80
router(config)# call admission pppoa 10 1

Configuring a VPDN Session

router(config)# call admission new-model
router(config)# call admission limit 1000
router(config)# call admission cpu-limit 80
router(config)# call admission vpdn 10 1

The Control Plane Policing feature allows you to configure a QoS filter that manages the traffic flow of control plane packets to protect the control plane of Cisco IOS XE routers and switches against reconnaissance and denial-of-service (DoS) attacks. The control plane thus helps maintain packet forwarding and protocol states despite an attack or heavy traffic load on the router or switch.

For examples about configuring the Control Plane Policing feature, see the “Control Plane Policing” section in the Quality of Service Solutions Configuration Guide located at:

http://www.cisco.com/en/US/docs/ios-xml/ios/qos_plcshp/configuration/xe-3s/qos-plcshp-ctrl-pln-plc.html

Using the Virtual Private Dialup Network (VPDN) Group Session Limiting feature, you can limit the number of VPDN sessions allowed per VPDN group. VPDN session limits can increase performance and reduce latency for routers that are otherwise forced to operate at high capacity.

For more information about VPDN Group Session Limiting, see the feature documentation at:

http://www.cisco.com/en/US/docs/ios-xml/ios/vpdn/configuration/xe-3s/vpd-tunnel-mgmt.html

The PPPoE Session Limit Support feature prevents the router from using too much memory for virtual access by limiting the number of PPPoE sessions that can be created on a router or on all Ethernet interfaces and subinterfaces as well as ATM interfaces and subinterfaces.

For more information about PPPoE session limiting, see the feature documentation at:

http://www.cisco.com/en/US/docs/ios-xml/ios/bbdsl/configuration/xe-3s/bba-limit-legcfg-xe.html

To prevent the virtual access subinterfaces from being registered with the Simple Network Management Protocol (SNMP) functionality of the router and using up the memory, do not use the SNMP management tools of the router to monitor PPP sessions. Use SNMP views to isolate the bulk queries and accidental requests.

Use the no virtual-template snmp command to disable the SNMP management tools:

Router(config)# no virtual-template snmp

The default value of Gigabit Ethernet and 10 Gigabit Ethernet interfaces is 375 packets for the input and output hold queues. If the interfaces are required to handle a high rate of control packets, such as LCP, IPCP, PPP, L2TP, and DHCP, the default value may not be sufficient. To ensure high scalability, set the access interface input and output hold queue to 4096:

Router(config)# interface gig1/0/0
Router(config-if)# hold-queue 4096 in

For PPP sessions, the keepalive command sets the keepalive timer for a specific interface. To ensure proper scaling and to minimize CPU utilization, set the timer for 60 seconds or longer. The default value is 10 seconds:

interface Virtual-Template1
 ip unnumbered Loopback1
 keepalive 60
 no peer default ip address
 ppp authentication pap

Note

For IP sessions, the keepalives are not enabled by default. Enabling keepalives for IP sessions provides the same capability as PPP keepalives except that ICMP or ARP is used to test the presence of subscribers. For more information about Using ARP for Keepalive Messages and Using ICMP for Keepalive Messages, see the feature documentation at: http://www.cisco.com/en/US/docs/ios-xml/ios/isg/configuration/xe-3s/Configuring_ISG_Policies_for_Session_Maintenance.html

To prevent head-of-the-line blocking of the IP input process and save system resources, configure the vpdn ip udp ignore checksum command:

Router(config)# vpdn ip udp ignore checksum

When you configure this command, the router directly queues the L2TP Hello packets and Hello acknowledgements to the L2TP control process. We recommend that you configure this command in all the scaled LAC and LNS L2TP tunnel configurations.

If you do not configure the vpdn ip udp ignore checksum command, the L2TP software sends the packets to UDP to validate the checksum. When too many packets are queued to the IP input process, the router starts Selective Packet Discard (SPD) mechanism that causes IP packets to be dropped.

Note	Head-of-the-line blocking of the IP input process might occur in other nonL2TP configurations. A flush occurring on an input interface indicates that the SPD mechanism is discarding packets.

To enhance scalability of per-user configurations without changing the router configuration, use the ip:vrf-id and ip:ip-unnumbered RADIUS attributes. These per-user vendor-specific attributes (VSAs) are used to map sessions to VRFs and IP unnumbered interfaces. The VSAs are applied to virtual access subinterfaces and are processed during PPP authorization.

The ip:vrf-id attribute is used to map sessions to VRFs. Any profile that uses the ip:vrf-id VSA must also use the ip:ip-unnumbered VSA to install IP configurations on the VAI that is to be created. The PPP that is used on a VAI to be created requires the ip:ip-unnumbered VSA. An Internet Protocol Control Protocol (IPCP) session is not established if IP is not configured on the interface. You must configure either the ip address command or the ip unnumbered command on the interface so that these configurations are present on the VAI that is to be created. However, specifying the ip address and ip unnumbered commands on a virtual template interface is not required because pre-existing IP configurations, if any, are removed when the ip:ip-vrf VSA is installed on the VAI. Therefore, any profile that uses the ip:vrf-id VSA must also use the ip:ip-unnumbered VSA to install IP configurations on the VAI that is to be created.

These per-user VSAs can be applied to VAIs. Therefore, the per-user authorization process does not require the creation of full VAIs, which improves scalability.