1. CISCO IOS SOFTWARE RELEASE 12.2S INTRODUCTION
1.1 Release 12.2SX Ordering Information, Feature Sets, and Image Names
1.2 Additional Information
• Cisco IOS Software Release 12.2S: http://www.cisco.com/go/release122s/
• Cisco IOS Software Release feedback and questions: http://www.cisco.com/warp/public/732/feedback/release/
• Release 12.2SX Release Notes: http://www.cisco.com/en/US/products/hw/switches/ps708/prod_release_note09186a00801c8339.html
• Cisco IOS Software Product Lifecycle Dates & Milestones: http://www.cisco.com/en/US/products/sw/iosswrel/ps5187/prod_bulletin0900aecd801eda8a.html
• Cisco IOS Software Center: http://www.cisco.com/kobayashi/library/12.2/index.shtml
1.3 Release 12.2(18)SXE Hardware and Security Feature Highlights
Dynamic Multipoint VPN
• NHRP: a client and server protocol where the hub is the server and the spokes are the clients. The hub maintains an NHRP database of the public interface addresses of the each spoke. Each spoke registers its real address when it boots and queries the NHRP database for real addresses of the destination spokes in order to build direct tunnels.
• mGRE Tunnel Interface: allows a single GRE interface to support multiple IPsec tunnels and simplifies the size and complexity of the configuration.
Figure 1. DMVPN
• Each spoke has a permanent IPsec tunnel to the hub, not to the other spokes within the network. Each spoke registers as clients of the NHRP server.
• When a spoke needs to send a packet to a destination (private) subnet on another spoke, it queries the NHRP server for the real (outside) address of the destination (target) spoke.
• After the originating spoke learns the peer address of the target spoke, it can initiate a dynamic IPsec tunnel to the target spoke.
• The spoke-to-spoke tunnel is built over the multipoint GRE interface.
• The spoke-to-spoke links are established on demand whenever there is traffic between the spokes. Thereafter, packets are able to bypass the hub and use the spoke-to-spoke tunnel.
• Hub Router Configuration Reduction
– Currently, for each spoke router, there is a separate block of configuration lines on the hub router that define the crypto map characteristics, the crypto access list, and the GRE tunnel interface. This feature allows users to configure a single multipoint GRE tunnel interface, a single IPsec profile, and no crypto access lists on the hub router to handle all spoke routers. Thus, the size of the configuration on the hub router remains constant even if spoke routers are added to the network.
• Automatic IPsec Encryption Initiation
– GRE has the peer source and destination address configured or resolved with NHRP. Thus, this feature allows IPsec to be immediately triggered for the point-to-point GRE tunneling or when the GRE peer address is resolved via NHRP for the multipoint GRE tunnel.
• Support for Dynamically Addressed Spoke Routers
– When using point-to-point GRE and IPsec hub-and-spoke VPN networks, the physical interface IP address of the spoke routers must be known when configuring the hub router because IP address must be configured as the GRE tunnel destination address. This feature allows spoke routers to have dynamic physical interface IP addresses (common for cable and DSL connections). When the spoke router comes online, it will send registration packets to the hub router: Within these registration packets is the current physical interface IP address of this spoke.
• Simplifies the burden of headend management and thus reduces the total cost of ownership.
VPN Routing and Forwarding---Aware Dynamic Multipoint VPN
Figure 2. VRF Aware DMVPN
• DMVPNs can be used to extend the MPLS networks deployed by service providers to leverage the ease of configuration of hub and spokes, support for dynamically addressed CPEs and zero touch provisioning for adding new spokes into a DMVPN.
• DMVPN architecture can unite many spokes into a single multipoint GRE interface, removing the need for a distinct physical/logical interface for each spoke in a native IPsec installation.
Network Address Translation Transparency Aware Dynamic Multipoint VPN
Figure 3. NAT Transparency Aware DMVPN
Dynamic Multipoint VPN Spoke-to-Spoke Functionality
Figure 4. DMVPN Spoke-to-Spoke Functionality
• Direct spoke-to-spoke tunnels
– This functionality allows direct spoke-to-spoke tunnel creation between two branch offices without the traffic having to go through the hub. Spokes can take advantage of an internet connection directly available between them. This leads to reduced latency and jitter for spoke-to-spoke traffic and improved bandwidth utilization. DMVPN networks deliver a lower cost per MByte of Bandwidth than native IPsec networks because the spoke-to-spoke traffic is not restricted by hub bandwidth utilization and at the same time it does not add any additional overhead to the hub bandwidth utilization.
• Avoids dual encrypts and decrypts
– Native IPsec and IPsec + GRE networks are organized as hub and spoke networks. As a result, all spoke-to-spoke traffic traversing the hub and requiring a dual encrypt and decrypt for all traffic putting an additional burden on the hub CPU. DMVPN alleviates the problem by creating direct on-demand spoke-to-spoke tunnels.
• Smaller spoke CPEs can participate in a virtual on-demand full mesh
– DMVPN allows smaller spoke CPE to participate in a virtual on-demand full mesh. Creating and managing a full mesh is often not possible for smaller spoke CPE, which cannot handle more than a dozen IPsec tunnels. DMVPN allows the spokes to create tunnels to other spokes on demand and tear down the tunnels after use
SafeNet IPsec VPN Client Support
Key Rollover for Certificate Renewal
Port Security with 4096 Secure MAC addresses
Port Security with Sticky MAC Address
Encapsulated Remote SPAN
SPAN Destination Port Permit List