New and Changed Information
The following sections list the new hardware and software features that are supported by the Cisco ASR 1000 Series Routers for Cisco IOS XE Release 3.10S:
Note MLPPP Broadband functionality is not supported in release 3.10.1. It is recommended to use the feature with release 3.10.0.
New Software Features in Cisco ASR 1000 Series Aggregation Services Routers Release 3.10.2S
WCCP with generic GRE Support
WCCP is extended to support generic GRE return method on Cisco IOS devices. Since GRE negotiated return is not supported on Cisco WAAS AppNav I/O module, customers need to use generic GRE tunnels (multipoint GRE) on the devices. That is, a mGRE tunnel needs to be configured manually on the device if the Cisco WAAS AppNav is configured with GRE return method.
Note Generic GRE tunnel does not work with loopback source address. Since the highest numbered loopback is reserved for WCCP, customers need to use the second highest loopback address.
Dropping TCP Packets During Router Reboot Process in AppNav Controller Group Scenario
For AppNav Controller Group (ACG) scenarios, a new CLI (service-insertion acg-reload-delay) provides a time delay before enabling WAN traffic for a router that has just rebooted. During the delay, the router drops all TCP packets passing through the WAN interface. This enables the router to synchronize flows before traffic is enabled, preventing unintended resetting of connections.
For detailed information, see the following Cisco document:
http://www.cisco.com/en/US/partner/docs/routers/access/4400/appnav/csr-asr/apnavcsr.html
New Hardware in Cisco ASR 1000 Series Aggregation Services Routers Release 3.10.0S
The following are the new hardware introduced in Cisco ASR 1000 Series Aggregation Services Routers Release 3.10.0S.
Cisco ASR 1000 Series Fixed Ethernet Line Card
The Cisco ASR 1000 Series Fixed Ethernet Line Card (ASR1000-2T+20X1GE) is a fixed-port Ethernet line card for the Cisco ASR 1000 Series Aggregation Services Routers. The line card is capable of 40-Gbps full-duplex traffic forwarding using a fixed-port interface design. This line card has 20 1GigE ports and two 10GigE ports.The small form-factor pluggables (SFP and XFP modules) allow the line card to be configured for different media types (copper or fiber) and different optical requirements (single-mode fiber or multimode fiber), as available.
New Software Features in Cisco ASR 1000 Series Aggregation Services Routers Release 3.10.0S
The following are the new software features introduced in Cisco ASR 1000 Series Aggregation Services Routers Release 3.10.0S.
Configurable RTP port range per IP Address for RTP session connectivity
For ASR boxes, the RTP port range has been increased to a range of 8000 to 48200 to scale high call volumes. This port range allows up 10000 calls on a single interface.
Ethernet over GRE Tunnels
For detailed information, see the following Cisco document:
http://www.cisco.com/en/US/docs/ios-xml/ios/interface/configuration/xe-3s/ir-eogre.html
FlexVPN Mixed Mode support
The FlexVPN Mixed Mode feature provides support for carrying IPv4 traffic over IPsec IPv6 transport. This is the first phase towards providing dual stack support on the IPsec stack. This implementation does not support using a single IPsec security association (SA) pair for both IPv4 and IPv6 traffic.
This feature is only supported for Remote Access VPN with IKEv2 and Dynamic VTI.
IPSec debugability enhancement
The IPSec debugability enhancement feature implements the following:
- An unique session ID for IPsec and IKE debugs. This session is allocated for each active peer and groups the IPsec and IKE debugs.
- The session ID is displayed in the show crypto session command.
- Support for crypto IPsec event tracing.
- Conditional debugging and filtering mechanism for peer sessions.
For more information on these two commands, see the following:
Cisco IOS Security Command Reference: Commands S to Z
IPv6 SNMP MIB support for voice features
The MIB objects relevant to Cisco UBE that have transport-related information such as IPV6 address and type of IP (IPV4 or IPV6) have been verified.
The criteria used for the enhanced MIBs are:
- The MIB should have voice/video related information.
- MIB objects should have IP address element in them.
The following MIBs satisfied the above criteria:
- CISCO-VOICE-DIAL-CONTROL-MIB
- CISCO-RTTMON-MIB
- CISCO-RTTMON-IP-EXT-MIB
- CISCO-SIP-CALLS-MIB
- CISCO-POP-MGMT-MIB
IPv6 Static Route support for Object Tracking
For detailed information, see the following Cisco document:
NHRP SNMP Restructuring
The NHRP SNMP Restructuring feature provides hardening support to NHRP MIBs. The snmp mib nhrp command is disabled by default. To enable you must explicitly configure it using the snmp mib nhrp command.
The snmp mib nhrp status command displays information about the following:
- The state of the tree.
- The enable or disable status of the NHRP MIB.
- The number of allocation tree nodes.
The debug snmp mib nhrp command enables debugging for NHRP MIBs.
For more information, see the following documents:
OTV Enhancements
The OTV enhancement include:
OTV join interfaces can be part of a VRF. This allows for OTV forwarding of L2 packets via a VRF L3 domain.
- OTV Sub-interface as join interface
Sub-interfaces can be configured as OTV join interfaces. This allows more flexibility with the L3 side OTV configuration.
- OTV Port-channel as join interface
Port-channel interfaces can be configured as OTV join interfaces. This allows interface redundancy for L3 side OTV connections.
- OTV Port-channel as internal interface
Port-channel interfaces can be configured as OTV internal interfaces. This allows interface redundancy for L2 side OTV connections.
For detailed information, see the following Cisco document
http://www.cisco.com/en/US/docs/ios-xml/ios/wan_otv/configuration/xe-3s/wan-otv-confg.html
PKI - New cert attributes
The PKI New Cert Attributes feature provides the following enhancements to Public Key Infrastructure (PKI):
- NVRAM Exhaustion
- Fresh Enrollment
NVRAM Exhaustion
Certificates and certificate revocation lists (CRLs) are used by devices when a certificate authority (CA) is used. Certificates and CRLs can be stored in NVRAM or an external database. If an external database is used to store certificates, there is no need to delete the expired certificates. Each certificate and CRL uses a moderate amount of memory. The following are stored in NVRAM:
- CA certificates and CRLs
- Certificates issued by CA server to clients
When a client renews its certificate, the new certificate, along with old certificates, is stored in NVRAM. This decreases the NVRAM space. As more certificates are stored, the NVRAM space is exhausted and this brings down the CA server, which then is unable to retrieve certificates. Manual intervention is required to restore space in NVRAM and bring the CA server up again.
To avoid NVRAM space exhaustion and manual intervention to bring up the CA server, a new timer triggers the database cleanup event. The timer starts when the first certificate is issued, and the timer interval is based on the client certificate life time configuration in the CA server. The timer scans the database and removes expired certificates that are not required, thereby preventing the CA server from going down because of NVRAM exhaustion. The timer information is displayed in the output from the show crypto pki timer command. Note that the timer applies only when certificates are stored in NVRAM and the database level is set to “complete.” However, when NVRAM is used to store certificates and the database level is configured with minimum or names, there is no need to delete the expired certificates because the certificates do not consume much space.
The certificates in the CA server can also be deleted by using the no crypto pki server name command. the following warning appears, when you configure this command:
Device(config)# no crypto pki server ABC-CA
CA certificate, Keypair, CRL and database files will be deleted. Do you wish to continue? [yes/no]:
If “yes” is entered, all files are removed from the database.
For more information on commands, see the following documents:
Cisco IOS Security Command Reference: Commands A to C
Cisco IOS Security Command Reference: Commands S to Z
Fresh Enrollment
The auto-enroll feature helps the device to renew the router certificate when it expires. Sometimes, the router certificate may not be enrolled if the CA server is not reachable or if the client is shut down. The back off mechanism prevents the device from having an expired certificate by renewing the certificates. The certificates are renewed by continuous contact with the CA server at specific intervals by using the retry count and retry period keywords in the enrollment command.
When a device certificate expires, the back off mechanism does the following:
- Issues a fresh enrollment request and starts the default back off mechanism or follow the configured retry counts. This step is repeated to obtain a fresh certificate.
- The enrollment request does not contain expired certificate keys, if the trustpoint is configured with the regenerate command. The regenerate command assigns new keys. To issue an enrollment request with the expired certificate keys, do not specify the regenerate command.
The following example shows how to configure the retry count and period keywords:
Device(config)# no crypto pki server ABC-CA
enrollment retry count 10
enrollment retry period 1
enrollment url http://ABC_CA:80
The default retry count is 10. The following table provides information when the enrollment does not happen:
|
|
1 |
1 minute |
2 |
1 minute |
3 |
2 minutes |
4 |
5 minutes |
5 |
10 minutes |
6 |
20 minutes |
7 |
40 minutes |
8 |
60 minutes |
9 |
90 minutes |
10 |
120 minutes |
After the default retry count, the enrollment request is deleted. If the certificate expires, the 5-second interval is employed to reach the CA.
For more information on the commands, see the following documents:
Cisco IOS Security Command Reference: Commands D to L
Cisco IOS Security Command Reference: Commands M to R
RFC4303 IP Encapsulating Security Payload (ESP) dummy packet for traffic flow confidentiality (TFC)
The RFC 4303 IP Encapsulating Security Payload (ESP) dummy packet for traffic flow confidentiality (TFC) feature provides RFC 4303 support in Cisco software. RFC 4303 describes two methods to hide the characteristics of traffic that is passing through an IPsec flow. The first method involves adding extra padding beyond the allowed maximum of 255 bytes after the payload data when using the Encapsulating Security Payload (ESP) protocol for traffic confidentiality. The second method involves adding extra "dummy" packets to the traffic flow. The generation and transmission of dummy packets is implemented in Cisco software through the RFC4303 IP Encapsulating Security Payload (ESP) dummy packet for traffic flow confidentiality (TFC) feature. A dummy packet is designated by setting the next header field in the ESP packet to a value of 59. The dummy packets are discarded when the packets are received by the device. The standard ESP header and trailer fields are present in a dummy packet. The payload (plain text) in the dummy packet contains zero which becomes random data after encryption. You can specify the time interval at which to generate the dummy packets. You can enable generating dummy packets globally using the crypto ipsec security-association dummy command or you can enable dummy packets for a crypto map using the set security-association dummy command. When enabled for a crypto map, dummy packets are enabled for all flows that are created using the crypto map.
For more information on commands, see the following documents:
Cisco IOS Security Command Reference: Commands A to C
Cisco IOS Security Command Reference: Commands S to Z