- Index
- Preface
- Using Cisco IOS Software
- SIP, SSC, and SPA Product Overview
-
- Overview of the IPsec VPN SPA
- Configuring VPNs in Crypto-Connect Mode
- Configuring VPNs in VRF Mode
- Configuring IPsec VPN Fragmentation and MTU
- Configuring IKE Features Using the IPsec VPN SPA
- Configuring Enhanced IPsec Features Using the IPsec VPN SPA
- Configuring PKI Using the IPsec VPN SPA
- Configuring Advanced VPNs Using the IPsec VPN SPA
- Configuring Duplicate Hardware and IPsec Failover Using the IPsec VPN SPA
- Configuring Monitoring and Accounting for the IPsec VPN SPA
- Troubleshooting the IPsec VPN SPA
- Glossary
- Release History
- Overview of the IPsec VPN SPA
- Overview of Basic IPsec and IKE Configuration Concepts
- Configuring VPNs with the IPsec VPN SPA
- IPsec Feature Support
- Software Requirements
- Interoperability
- Restrictions
- Supported MIBs
- IPsec VPN SPA Hardware Configuration Guidelines
- Displaying the SPA Hardware Type
Overview of the IPsec VPN SPA
This chapter provides an overview of the release history, and feature and Management Information Base (MIB) support for the IPsec VPN SPA.
This chapter includes the following sections:
•Overview of the IPsec VPN SPA
•Overview of Basic IPsec and IKE Configuration Concepts
•Configuring VPNs with the IPsec VPN SPA
•IPsec VPN SPA Hardware Configuration Guidelines
•Displaying the SPA Hardware Type
Release History
Overview of the IPsec VPN SPA
The IPsec VPN SPA is a Gigabit Ethernet IP Security (IPsec) cryptographic SPA that you can install in a Catalyst 6500 Series switch to provide hardware acceleration for IPsec encryption and decryption, generic routing encapsulation (GRE), and Internet Key Exchange (IKE) key generation.
Note Software-based IPsec features are not supported in any Cisco IOS releases that support the IPsec VPN SPA.
The traditional software-based implementation of IPsec in Cisco IOS supports the entire suite of security protocols including Authentication Header (AH), Encapsulating Security Payload (ESP), and IKE. The resources consumed by these activities are significant and make it difficult to achieve line-rate transmission speeds over secure virtual private networks (VPNs). To address this problem, certain platforms with large VPN bandwidth requirements support bump-in-the-wire (BITW) IPsec hardware modules in conjunction with the hardware forwarding engines. These modules off-load policy enforcement, as well as bulk encryption and forwarding, from the route processor (RP) so that it is not required to look at each packet coming through the switch. This frees up resources that can be used for session establishment, key management, and other features. The IPsec VPN SPA provides a bump-in-the-wire (BITW) IPsec implementation using virtual LANs (VLANs) for a Catalyst 6500 Series switch.
Note BITW is an IPsec implementation that starts egress packet processing after the IP stack has finished with the packet and completes ingress packet processing before the IP stack receives the packet.
The IPsec VPN SPA can use multiple Fast Ethernet or Gigabit Ethernet ports on other Catalyst 6500 Series switch modules to connect to the Internet through WAN routers. The physical ports may be attached to the IPsec VPN SPA through a VLAN called the port VLAN. Packets that are received from the WAN routers pass through the IPsec VPN SPA for IPsec processing. The packets are output on a dedicated VLAN called the interface VLAN or inside VLAN. Depending on the configuration mode (VRF mode or crypto-connect mode), the interface VLAN or port VLAN may be configured explicitly or may be allocated implicitly by the system.
On the LAN side, traffic between the LAN ports can be routed or bridged on multiple Fast Ethernet or Gigabit Ethernet ports. Because the LAN traffic is not encrypted or decrypted, it does not pass through the IPsec VPN SPA.
The IPsec VPN SPA does not route, maintain routing information, or change the MAC header of a packet (except for the VLAN ID from one VLAN to another).
Overview of Basic IPsec and IKE Configuration Concepts
This section reviews some basic IPsec and IKE concepts that are used throughout the configuration of the IPsec VPN SPA, such as security associations (SAs), access control lists (ACLs), crypto maps, transform sets, and IKE policies. The information presented here is introductory and should not be considered complete.
Note For more detailed information on IPsec and IKE concepts and procedures, refer to the Cisco IOS Security Configuration Guide.
Information About IPsec Configuration
IPsec provides secure tunnels between two peers, such as two routers or switches. More accurately, these tunnels are sets of security associations (SAs) that are established between two IPsec peers. The SAs define which protocols and algorithms should be applied to sensitive packets and specify the keying material to be used by the two peers. SAs are unidirectional and are established per security protocol (Authentication Header (AH) or Encapsulating Security Payload (ESP)). Multiple IPsec tunnels can exist between two peers to secure different data streams, with each tunnel using a separate set of SAs. For example, some data streams might be authenticated only while other data streams must both be encrypted and authenticated.
Note The use of the term "tunnel" in this subsection does not refer to using IPsec in tunnel mode.
With IPsec, you define what traffic should be protected between two IPsec peers by configuring ACLs and applying these ACLs to interfaces by way of crypto maps. (The ACLs used for IPsec are used only to determine which traffic should be protected by IPsec, not which traffic should be blocked or permitted through the interface. Separate ACLs define blocking and permitting at the interface.)
If you want certain traffic to receive one combination of IPsec protection (for example, authentication only) and other traffic to receive a different combination of IPsec protection (for example, both authentication and encryption), you must create two different crypto ACLs to define the two different types of traffic. These different ACLs are then used in different crypto map entries, which specify different IPsec policies.
Crypto ACLs associated with IPsec crypto map entries have four primary functions:
•Select outbound traffic to be protected by IPsec (permit = protect).
•Indicate the data flow to be protected by the new SAs (specified by a single permit entry) when initiating negotiations for IPsec security associations.
•Process inbound traffic in order to filter out and discard traffic that should have been protected by IPsec.
•Determine whether or not to accept requests for IPsec security associations on behalf of the requested data flows when processing IKE negotiation from the IPsec peer. Negotiation is performed only for ipsec-isakmp crypto map entries. In order to be accepted, if the peer initiates the IPsec negotiation, it must specify a data flow that is "permitted" by a crypto ACL associated with an ipsec-isakmp crypto map entry.
Crypto map entries created for IPsec combine the various parts used to set up IPsec SAs, including:
•Which traffic should be protected by IPsec (per a crypto ACL)
•The granularity of the flow to be protected by a set of SAs
•Where IPsec-protected traffic should be sent (the name of the remote IPsec peer)
•The local address to be used for the IPsec traffic
•What IPsec SA should be applied to this traffic (selecting from a list of one or more transform sets)
•Whether SAs are manually established or are established via IKE
•Other parameters that might be necessary to define an IPsec SA
Crypto map entries are searched in order. The switch attempts to match the packet to the access list specified in that entry.
Crypto map entries also include transform sets. A transform set is an acceptable combination of security protocols, algorithms, and other settings to apply to IPsec-protected traffic.
You can specify multiple transform sets, and then specify one or more of these transform sets in a crypto map entry. During IPsec security association negotiations with IKE, the peers search for a transform set that is the same at both peers. When such a transform set is found, it is selected and will be applied to the protected traffic as part of both peers' IPsec SAs. (With manually established SAs, there is no negotiation with the peer, so both sides must specify the same transform set.)
Note To minimize the possibility of packet loss during rekeying, we recommend using time-based rather than volume-based IPsec SA expiration. By setting the lifetime volume to the maximum value using the set security-association lifetime kilobytes 536870912 command, you can usually force time-based SA expiration.
In Cisco IOS Release 12.2(33)SXF and earlier releases, IPsec can be configured with manual keying instead of IKE, but IKE enhances IPsec by providing additional features, flexibility, and ease of configuration for the IPsec standard. IKE is enabled by default.
Note If you configure manual keying, you must configure SPI to be greater than 4096.
Information About IKE Configuration
IKE is a key management protocol standard that is used in conjunction with the IPsec standard.
IKE is a hybrid protocol that implements the Oakley key exchange and Skeme key exchange inside the Internet Security Association and Key Management Protocol (ISAKMP) framework. (ISAKMP, Oakley, and Skeme are security protocols implemented by IKE.)
You configure IKE by creating IKE policies at each peer using the crypto isakmp policy command. An IKE policy defines a combination of security parameters to be used during the IKE negotiation and mandates how the peers are authenticated.
You can create multiple IKE policies, each with a different combination of parameter values, but at least one of these policies must contain exactly the same encryption, hash, authentication, and Diffie-Hellman parameter values as one of the policies on the remote peer. For each policy that you create, you assign a unique priority (1 through 10,000, with 1 being the highest priority).
If you do not configure any policies, your router uses the default policy, which is always set to the lowest priority, and which contains each parameter's default value.
There are five parameters to define in each IKE policy:
•Encryption algorithm
•Hash algorithm
•Authentication method
•Diffie-Hellman group identifier
•Security association lifetime
For more information about IKE, see the "Overview of IKE" section.
Configuring VPNs with the IPsec VPN SPA
To configure a VPN using the IPsec VPN SPA, you have two basic options: crypto-connect mode or Virtual Routing and Forwarding (VRF) mode. In either mode, you may also configure GRE tunneling to encapsulate a wide variety of protocol packet types, including multicast packets, inside the VPN tunnel.
Note Switching between crypto-connect mode and VRF mode requires a reload.
Note We recommend that you do not make changes to the VPN configuration while VPN sessions are active. To avoid system disruption, we recommend that you plan a scheduled maintenance time and clear all VPN sessions using the clear crypto sessions command before making VPN configuration changes.
Crypto-Connect Mode
Traditionally, VPNs are configured on the IPsec VPN SPA by attaching crypto maps to interface VLANs and then crypto-connecting a physical port to the interface VLAN. This method, known as crypto-connect mode, is similar to the method used to configure VPNs on routers running Cisco IOS software. When you configure VPNs on the IPsec VPN SPA using crypto-connect mode, you attach crypto maps to VLANs (using interface VLANs); when you configure VPNs on switches running Cisco IOS software, you configure individual interfaces.
Note With the IPsec VPN SPA, crypto maps are attached to individual interfaces but the set of interfaces allowed is restricted to interface VLANs.
Crypto-connect mode VPN configuration is described in Chapter 21 "Configuring VPNs in Crypto-Connect Mode."
VRF Mode
VRF mode, also known as VRF-aware IPsec, allows you to map IPsec tunnels to VPN routing and forwarding instances (VRFs) using a single public-facing address. A VRF instance is a per-VPN routing information repository that defines the VPN membership of a customer site attached to the Provider Edge (PE) router. A VRF comprises an IP routing table, a derived Cisco Express Forwarding (CEF) table, a set of interfaces that use the forwarding table, and a set of rules and routing protocol parameters that control the information that is included in the routing table. A separate set of routing and CEF tables is maintained for each VPN customer.
When you configure a VPN on the IPsec VPN SPA using VRF mode, the model of interface VLANs is preserved, but the crypto connect vlan command is not used. Instead, a route must be installed so that packets destined for that particular subnet in that particular VRF are directed to that interface VLAN.
When configuring a VPN using VRF mode, you have these additional tunneling options: tunnel protection (TP) using GRE, and Virtual Tunnel Interface (VTI). With either of these options, you can terminate tunnels in VRFs (normal VRF mode) or in the global context.
VRF mode VPN configuration is described in Chapter 22 "Configuring VPNs in VRF Mode."
IPsec Feature Support
The tables in the following sections display supported and unsupported IPsec features of the VSPA in each VPN mode according to the software release:
•IPsec Features Common To All VPN Modes
•IPsec Features in Crypto-Connect Mode
Note This document describes IPsec VPN SPA features and applications that have been tested and are supported. Features and applications that do not explicitly appear in this table and in the following chapters should be considered unsupported. Contact your Cisco account team before implementing a configuration that is not described in this document.
IPsec Features Common To All VPN Modes
Table 20-1 lists the supported and unsupported IPsec features common to all VPN modes.
|
Cisco IOS Software Release 12.2 |
|||||
---|---|---|---|---|---|---|
SXE |
SXF |
SRA1 |
SRB, SRC, SRD |
SXH |
SXI |
|
IPsec tunnels using software crypto |
N |
N |
N |
N |
N |
N |
Enhanced GRE takeover (if the supervisor engine cannot process) |
Y |
Y |
Y |
Y |
Y |
Y |
Multicast over GRE |
N |
Y |
Y |
Y |
Y |
Y |
Multicast over multipoint GRE (mGRE) / DMVPN |
N |
N |
N |
N |
N |
N |
Multicast Scalability Enhancement (single SPA mode) |
N |
Y |
Y |
Y |
Y |
N |
Advanced Encryption Standard (AES) |
Y |
Y |
Y |
Y |
Y |
Y |
ISAKMP keyring |
Y |
Y |
Y |
Y |
Y |
Y |
SafeNet Client support |
Y |
Y |
Y |
Y |
Y |
N |
Peer filtering (SafeNet Client support) |
N |
N |
N |
N |
N |
N |
Certificate to ISAKMP profile mapping |
Y |
Y |
Y |
Y |
Y |
Y |
Encrypted preshared key |
Y |
Y |
Y |
Y |
Y |
Y |
IKE Aggressive Mode Initiation |
N |
N |
N |
N |
N |
N |
Call Admission Control (CAC) for IKE |
N |
N |
Y |
Y |
Y |
Y |
Dead Peer Detection (DPD) on-demand |
Y |
Y |
Y |
Y |
Y |
Y |
DPD periodic message option |
N |
N |
Y |
Y |
Y |
Y |
IPsec prefragmentation |
Y |
Y |
Y |
Y |
Y |
Y |
Reverse Route Injection (RRI) |
Y |
Y |
Y |
Y |
Y |
Y |
Reverse route with optional parameters |
N |
N |
N |
N |
N |
N |
Adjustable IPsec anti-replay window size |
N |
Y |
Y |
Y |
Y |
Y |
IPsec preferred peer |
Y |
Y |
Y |
Y |
Y |
Y |
Per-crypto map (and global) IPsec security association (SA) idle timers |
Y |
Y |
Y |
Y |
Y |
Y |
Distinguished name-based crypto maps |
Y |
Y |
Y |
Y |
Y |
Y |
Sequenced access control lists (ACLs) (crypto ACLs) |
Y |
Y |
Y |
Y |
Y |
Y |
Deny policy configuration enhancements (drop, jump, clear) |
Y |
Y |
Y |
Y |
Y |
Y |
Disable volume lifetime per interface |
N |
N |
N |
N |
N |
Y |
IPsec VPN SPA quality of service (QoS) queueing |
Y |
Y |
Y |
Y |
Y |
Y |
Multiple RSA key pair support |
N |
N |
Y |
Y |
Y |
Y |
Protected private key storage |
N |
N |
Y |
Y |
Y |
Y |
Trustpoint CLI |
N |
N |
Y |
Y |
Y |
Y |
Query mode per trustpoint |
N |
N |
N |
N |
N |
Y |
Local certificate storage location |
N |
N |
Y |
Y |
Y |
Y |
Direct HTTP enroll with CA servers |
Y |
Y |
Y |
Y |
Y |
Y |
Manual certificate enrollment |
N |
N |
Y |
Y |
Y |
Y |
Certificate autoenrollment |
N |
N |
Y |
Y |
Y |
Y |
Key rollover for Certificate Authority (CA) renewal |
N |
N |
N |
N |
N |
Y |
Public-key infrastructure (PKI) query multiple servers |
N |
N |
N |
N |
N |
Y |
Online Certificate Status Protocol (OCSP) |
N |
N |
N |
N |
N |
Y |
Optional OCSP nonces |
N |
N |
N |
N |
N |
Y |
Certificate security attribute-based access control |
N |
N |
N |
N |
N |
Y |
PKI AAA authorization using entire subject name |
N |
N |
N |
N |
N |
Y |
PKI local authentication using subject name |
N |
N |
Y |
Y |
Y |
Y |
Source interface selection for outgoing traffic with certificate authority |
N |
N |
N |
N |
N |
Y |
Persistent self-signed certificates as Cisco IOS CA server |
N |
N |
N |
N |
N |
N |
Certificate chain verification |
N |
N |
N |
N |
N |
N |
Multi-tier certificate support |
Y |
Y |
Y |
Y |
Y |
Y |
Easy VPN Server enhanced features |
N |
N |
N |
N |
N |
N |
Easy VPN Server basic features |
Y |
Y |
Y |
Y |
Y |
Y |
Interoperate with Easy VPN Remote using preshared key |
Y |
Y |
Y |
Y |
Y |
Y |
Interoperate with Easy VPN Remote using RSA signature |
N |
N |
Y |
Y |
Y |
Y |
Central Policy Push (CPP) |
N |
N |
Y |
Y |
N |
N |
Stateless failover using the Hot Standby Router Protocol (HSRP) |
Y |
Y |
Y |
Y |
Y |
Y |
Chassis-to-chassis stateful failover using HSRP and SSP in site-to-site IPsec using preshared keys with crypto maps |
Y |
Y |
N |
N |
N |
N |
Chassis-to-chassis failover (IPsec stateful failover) with DMVPN, GRE/TP, VTI, Easy VPN, or PKI |
N |
N |
N |
N |
N |
N |
Blade-to-Blade stateful failover |
Y |
Y |
Y |
Y |
Y |
Y |
IPsec VPN Monitoring (IPsec Flow MIB) |
Y |
Y |
Y |
Y |
Y |
Y |
IPsec VPN Accounting (start / stop / interim records) |
Y |
Y |
Y |
Y |
Y |
Y |
Crypto Conditional Debug support |
N |
Y |
Y |
Y |
Y |
Y |
show crypto engine accelerator statistic command |
N |
N |
Y |
Y |
Y |
Y |
Other show crypto engine commands |
N |
N |
N |
N |
N |
N |
clear crypto engine accelerator counter command |
N |
N |
Y |
Y |
Y |
Y |
Crypto commands applied to a loopback interface |
N |
N |
N |
N |
N |
N |
Asymmetric routing (different outside interfaces for encrypted and decrypted traffic of the same tunnel) |
N |
N |
N |
N |
N |
N |
Policy Based Routing (PBR) |
N |
N |
N |
N |
N |
N |
ACL on tunnel interface |
N |
N |
N |
N |
N |
Y |
MQC QoS on tunnel interface (service policy) |
N |
N |
N |
N |
N |
Y |
mls qos command on all tunnel interfaces: IPsec, GRE, mGRE |
N |
N |
N |
N |
N |
N |
QoS pre-classify CLI |
N |
N |
N |
N |
N |
N |
NAT on crypto VLAN or crypto protected tunnel interface |
N |
N |
N |
N |
N |
N |
16 K tunnels (IKE and IPsec tunnels) |
N |
N |
Y |
Y |
Y |
Y |
Switching between VRF and crypto-connect modes requires reboot |
Y |
Y |
Y |
Y |
Y |
Y |
GRE keepalives on tunnel protection (TP) tunnels |
N |
N |
N |
N |
N |
N |
GRE keepalives on mGRE/DMVPN tunnels |
N |
N |
N |
N |
N |
N |
IPsec Network Address Translation Transparency (NAT-T) |
Y |
Y |
Y |
Y |
Y |
Y |
Dynamic Multipoint VPN Phase 2 (DMVPN) (mGRE; TP & NHRP) |
Y |
Y |
Y |
Y |
Y |
Y |
DMVPN Phase 3 |
N |
N |
N |
N |
N |
N |
DMVPN hub router behind a NAT gateway—tunnel mode |
N |
N |
N |
N |
N |
N |
DMVPN hub router behind a NAT gateway—transport mode |
N |
N |
N |
N |
Y |
Y |
DMVPN spoke router behind a NAT gateway—tunnel mode |
N |
N |
N |
N |
N |
N |
DMVPN spoke router behind a NAT gateway—transport mode |
Y |
Y |
Y |
Y |
Y |
Y |
Multicast transit traffic over DMVPN tunnels |
N |
N |
N |
N |
N |
N |
Non-IP traffic over TP (DMVPN, point-to-point GRE, sVTI) tunnels |
N |
N |
N |
N |
N |
N |
Support for the VPNSM |
Y |
Y |
N |
N |
N |
N |
All serial PPP interfaces with crypto-connect mode must have ip unnumber null 0 command |
N |
N |
N |
Y |
Y |
Y |
Manual key |
N |
Y |
N |
N |
N |
N |
Tunnel Endpoint Discovery |
Y |
Y |
N |
N |
N |
N |
Transport adjacency and nested tunnels |
N |
N |
N |
N |
N |
N |
Transit IPsec packets |
N |
Y |
N |
N |
Y |
Y |
IPsec VPN SPA supported with virtual switching system (VSS) |
N |
N |
N |
N |
N |
N |
IP header options through IPsec tunnels |
N |
N |
N |
N |
N |
N |
Invalid SPI recovery |
N |
N |
Y |
Y |
Y |
Y |
IPsec compression |
N |
N |
N |
N |
N |
N |
Group Encrypted Transport VPN (GETVPN) |
N |
N |
N |
N |
N |
N |
IPsec Passive Mode |
N |
N |
N |
N |
N |
N |
Multilink PPP (MLPPP) |
Y |
Y |
Y |
Y |
Y |
Y |
Multilink or dialer interfaces |
N |
N |
N |
N |
N |
N |
Point-to-point frame relay |
Y |
Y |
Y |
Y |
Y |
Y |
Multipoint frame relay |
N |
N |
N |
N |
N |
N |
ATM PVC bundle |
N |
N |
N |
N |
N |
N |
1 The SR software releases are for the Cisco 7600 series router. These releases do not apply to the Catalyst 6500 series switches. |
IPsec Features in Crypto-Connect Mode
Table 20-2 lists the supported and unsupported IPsec features in crypto-connect mode.
|
Cisco IOS Software Release 12.2 |
|||||
---|---|---|---|---|---|---|
SXE |
SXF |
SRA1 |
SRB, SRC, SRD |
SXH |
SXI |
|
Point-to-point GRE with tunnel protection and VTI |
N |
N |
N |
N |
N |
N |
Path MTU discovery (PMTUD) |
N |
N |
Y |
Y |
Y |
Y |
PMTUD with NAT-T |
N |
N |
N |
N |
N |
N |
IPsec static virtual tunnel interface (sVTI) |
N |
N |
N |
N |
N |
N |
The use of VRFs in conjunction with crypto features |
N |
N |
N |
N |
N |
N |
IPX and Appletalk over point-to-point GRE |
Y |
Y |
Y |
Y |
Y |
Y |
ip tcp adjust-mss command in GRE when taken over |
N |
N |
N |
N |
N |
Y |
1 The SR software releases are for the Cisco 7600 series router. These releases do not apply to the Catalyst 6500 series switches. |
IPsec Features in VRF Mode
Table 20-3 lists the supported and unsupported IPsec features in VRF mode.
|
Cisco IOS Software Release 12.2 |
|||||
---|---|---|---|---|---|---|
SXE |
SXF |
SRA1 |
SRB, SRC, SRD |
SXH |
SXI |
|
Global VRF |
Y |
Y |
Y |
Y |
Y |
Y |
Front-door VRF (FVRF) |
N |
N |
Y |
Y |
Y |
Y |
FVRF on an mGRE tunnel configured on a DMVPN hub |
N |
N |
Y |
Y |
Y |
Y |
FVRF on an mGRE tunnel configured on a DMVPN spoke |
N |
N |
N |
N |
N |
N |
Overlapping IP address space in VRFs |
Y |
Y |
Y |
Y |
Y |
Y |
Secondary IP addresses on interfaces |
N |
N |
N |
N |
N |
N |
MPLS over GRE/IPsec (tag switching on tunnel interfaces) |
N |
N |
N |
N |
N |
N |
PE-PE encryption (IPsec only) over MPLS |
N |
N |
N |
N |
N |
N |
PE-PE encryption (tunnel protection) over MPLS |
N |
N |
N |
N |
N |
N |
MPLS PE-CE encryption (Tag2IP) with GRE/TP |
N |
N |
N |
Y |
Y |
Y |
MPLS PE-CE encryption (Tag2IP) with sVTI |
N |
N |
N |
N |
N |
Y |
MPLS PE-CE encryption (Tag2IP) with crypto map |
N |
N |
N |
N |
N |
N |
Crypto maps in VRF-lite |
Y |
Y |
Y |
Y |
Y |
Y |
Per-VRF AAA with RADIUS |
N |
N |
N |
Y |
Y |
Y |
Per-VRF AAA with TACACS |
N |
N |
N |
Y |
N |
N |
IPsec static virtual tunnel interface (sVTI) |
N |
N |
Y |
Y |
Y |
Y |
Multicast over sVTI |
N |
N |
N |
N |
N |
Y |
ip tcp adjust-mss command on sVTI or GRE |
N |
N |
N |
N |
N |
Y |
Ingress and egress features (ACL, QOS) on sVTI, GRE/TP, and mGRE tunnel |
N |
N |
N |
N |
N |
Y |
Ingress features (ACL, PBR, inbound service policy) on the outside interface |
N |
N |
N |
N |
N |
N |
Outbound service policy on the outside interface |
Y |
Y |
Y |
Y |
Y |
Y |
TP support in the global context |
N |
N |
Y |
Y |
Y |
Y |
IPsec SA using crypto map created in transport mode |
N |
N |
N |
N |
N |
N |
Path MTU discovery (PMTUD) |
N |
N |
N |
N |
N |
Y |
Non-IP version 4 traffic over TP tunnels |
N |
N |
N |
N |
N |
N |
IPv6 IPsec sVTI IPv6-in-IPv6 |
N |
N |
N |
N |
N |
N |
1 The SR software releases are for the Cisco 7600 series router. These releases do not apply to the Catalyst 6500 series switches. |
Software Requirements
The VSPA requires that one of the following crypto images is running on your switch:
•Supervisor Engine 720 (including 10G)
–s72033-adventerprisek9_wan-mz
–s72033-advipservicesk9_wan-mz
–s72033-adventerprisek9_wan-vz
–s72033-advipservicesk9_wan-vz
•Supervisor Engine 32 (including 10G)
–s3223-adventerprisek9_wan-mz
–s3223-advipservicesk9_wan-mz
–s3223-adventerprisek9_wan-vz
–s3223-advipservicesk9_wan-vz
Note The images ending in "-vz" require Cisco IOS Release 12.2(33)SXH or a later release.
Interoperability
The supervisor engine support varies based on the release. Table 20-4 lists the supervisor engine support for each release.
The IPsec VPN SPA supports the following interoperability features:
•You may have an IPsec VPN SPA in the same chassis with the following service modules:
–Firewall Services Module (WS-SVC-FWM-1-K9)
–Network Analysis Module 2 (WS-SVC-NAM-2)
Table 20-5 lists SIP and SSC support.
|
|
|
|||
---|---|---|---|---|---|
|
|
|
|
||
IPsec VPN SPA |
SPA-IPSEC-2G |
No |
No |
No |
Yes |
For more information about the introduction of support for the IPsec VPN SPA, see the "Release History" section.
The following notes apply to the SIP, SSC, and SPA compatibility table:
•Note1—Supported in 12.2SXE and SXF. Support removed in 12.2(33)SXH. Support restored in 12.2(33)SXI.
•Note2—Support added in 12.2(33)SXH.
•Note3—Supported in 12.2SXF. Support removed in 12.2(33)SXH.
•Note4—Support added in 12.2(18)SXF10.
•Note5—Support added in 12.2(33)SXI.
•Note6—Support added in 12.2(33)SXI2.
The line card module support varies based on the release. Table 20-6 lists the Ethernet line card and module support for each release.
|
|
||
---|---|---|---|
|
|
|
|
SPA-1X10GE |
N |
N |
SIP-600 |
SPA-10X1GE1 |
N |
N |
SIP-600 |
SPA-2X1GE |
SIP-400 |
SIP-400 |
SIP-400 |
SPA-2X1GE-V2 |
N |
N |
SIP-400 |
SPA-2XT3/E3 |
N |
N |
N |
SPA-4X1FE-TX-V2 |
N |
N |
N |
SPA-5X1GE1 |
N |
N |
SIP-600 |
SPA-5X1GE-V2 |
N |
N |
N |
SPA-8X1FE-TX-V2 |
N |
N |
N |
WS-X6148-GE-TX |
Y |
Y |
Y |
WS-X6148-RJ-21 |
Y |
Y |
Y |
WS-X6148-RJ-21V |
Y |
Y |
Y |
WS-X6148-RJ-45 |
Y |
Y |
Y |
WS-X6148-RJ-45V |
Y |
Y |
Y |
WS-X6408A-GBIC |
Y |
Y |
Y |
WS-X6416-GBIC |
Y |
Y |
Y |
WS-X6502-10GE |
Y |
Y |
Y |
WS-X6516-GBIC |
Y |
Y |
Y |
WS-X6516-GE-TX |
Y |
Y |
Y |
WS-X6516A-GBIC |
Y |
Y |
Y |
WS-X6548-GE-TX |
Y |
Y |
Y |
WS-X6548-RJ-45 |
Y |
Y |
Y |
WS-X6704-10GE |
Y |
Y |
Y |
WS-X6708-10GE |
N |
Y |
Y |
WS-X6716-10GE |
N |
Y |
Y |
WS-X6724-SFP |
Y |
Y |
Y |
WS-X6748-GE-TX |
Y |
Y |
Y |
WS-X6748-SFP |
Y |
Y |
Y |
1 Subinterfaces on SPA-5X1GE and SPA-10X1GE are not supported in any release. |
Table 20-7 lists the ATM line card and module support for each release.
Table 20-8 lists the POS line card and module support for each release.
Table 20-9 lists the serial line cards and module support for each release.
|
|
||
---|---|---|---|
|
|
|
|
SPA-2XCT3/DS0 |
N |
SIP-200 |
SIP-200 |
SPA-2XT3/E3 |
N |
N |
N |
SPA-4XCT3/DS0 |
N |
N |
N |
SPA-4XT3/E3 |
N |
N |
N |
SPA-8XCHT1/E1 |
N |
N |
N |
WS-6182-2PA |
Y |
N |
N |
WS-6802-2PA |
N |
N |
N |
WS-X6582-2PA PA-A3-OC3MM |
Y |
Y |
Y |
1 Subinterfaces on PA-1FE-TX and PA-2FE-TX are supported only in Cisco IOS Release 12.2(18)SXF17, Cisco IOS Release 12.2(33)SXH6, and Cisco IOS Release 12.2(33)SXI2 and later releases. |
Table 20-10 lists the service module support for each release.
|
|
||
---|---|---|---|
|
|
|
|
WS-SVC-FWSM-1 |
Y |
Y |
Y |
WS-SVC-IDSM2 |
N |
N |
N |
WS-SVC-NAM2 |
N |
N |
Y |
Table 20-11 lists the OSM line card support for each release.
Note Cisco IOS Release 12.2(33)SXH and later releases do not support OSM modules.
Restrictions
Note For other SSC-specific features and restrictions see also Chapter 3 "Overview of the SIPs and SSC"in this guide.
The IPsec VPN SPA is subject to the following restrictions:
•The IPsec VPN SPA requires Cisco IOS Release 12.2(18)SXE2 or later releases.
•The IPsec VPN SPA is supported only on the Cisco 7600 SSC-400.
•A Supervisor Engine 720 (MSFC3 and PFC3) requires a minimum of 512 MB memory to operate with the IPsec VPN SPA.
Note The IPsec VPN SPA MSFC DRAM requirements are as follows:
- Up to 8,000 tunnels with 512-MB DRAM
- Up to 16,000 tunnels with 1-GB DRAM
These numbers are chosen to leave some memory available for routing protocols and other applications. However, your particular use of the MSFC may demand more memory than the quantities that are listed above. In an extreme case, you could have one tunnel but still require 512-MB DRAM for other protocols and applications running on the MSFC.
•A maximum of 10 IPsec VPN SPAs per chassis are supported.
•IPsec VPN SPA state information is not maintained between the active and standby supervisor engine during normal operation. During a supervisor engine switchover in an SSO environment, the IPsec VPN SPA will reboot.
•GRE keepalives are not supported if crypto engine gre vpnblade is configured.
•Resource Reservation Protocol (RSVP) over VTI is not supported on the IPSEC VPN SPA.
•RSVP over GRE/IPSEC is supported when the GRE encapsulation is done by the supervisor and not the IPSEC VPN SPA.
Note In Cisco IOS Release 12.2(18)SXF2 and later releases, the crypto engine subslot command used in previous releases has been replaced with the crypto engine slot command (of the form crypto engine slot slot/subslot {inside | outside}). The crypto engine subslot command is no longer supported. In Cisco IOS Release 12.2(33)SXI and later releases, the slot slot/subslot is not specified when the outside keyword is used.
When upgrading, ensure that this command has been modified in your start-up configuration to avoid extended maintenance time.
Supported MIBs
The following MIB is supported in Cisco IOS Release 12.2(18)SXE2 for the Cisco 7600 SSC-400 and the IPsec VPN SPA on a Catalyst 6500 Series switch:
•CISCO-IPSEC-FLOW-MONITOR-MIB
Note Gigabit Ethernet port SNMP statistics (for example, ifHCOutOctets and ifHCInOctets) are not provided for the internal IPsec VPN SPA trunk ports because these ports are not externally operational ports and are used only for configuration.
For more information about MIB support on a Catalyst 6500 Series switch, refer to the Cisco 7600 Series Router MIB Specifications Guide, at the following URL:
To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL:
http://tools.cisco.com/ITDIT/MIBS/servlet/index
If Cisco MIB Locator does not support the MIB information that you need, you can also obtain a list of supported MIBs and download MIBs from the Cisco MIBs page at the following URL:
http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml
To access Cisco MIB Locator, you must have an account on Cisco.com. If you have forgotten or lost your account information, send a blank e-mail to cco-locksmith@cisco.com. An automatic check will verify that your e-mail address is registered with Cisco.com. If the check is successful, account details with a new random password will be e-mailed to you. Qualified users can establish an account on Cisco.com by following the directions found at this URL:
http://tools.cisco.com/RPF/register/register.do
IPsec VPN SPA Hardware Configuration Guidelines
The configuration guidelines for IPsec VPN SPA hardware are as follows:
•For information about managing your system images and configuration files, refer to the Cisco IOS Configuration Fundamentals Configuration Guide, Release 12.2 and Cisco IOS Configuration Fundamentals Command Reference, Release 12.2 publications.
•Some CLI commands require you to specify the inside and outside ports of the VSPA in the format slot/subslot/port. Although the VSPA ports are not actual Gigabit Ethernet ports, and do not share all properties of external Gigabit Ethernet interfaces, they can be addressed for configuration as Gigabit Ethernet trunk ports, using port numbers as follows:
–Port 1—Inside port, attached to interface VLAN
–Port 2—Outside port, attached to port VLAN
For example, to configure the outside port of a VSPA in the first subslot (subslot 0) of an Cisco 7600 SSC-400 in slot 6 of a Catalyst 6500 Series switch, enter the following command:
Router(config)# interface GigabitEthernet6/0/2
•The show crypto engine configuration command does not show the IPsec VPN SPA subslot number when there is no crypto connection even if the adapter is installed in the chassis.
•When you remove an IPsec VPN SPA that has some ports participating in crypto connections, the crypto configuration remains intact. When you reinsert the same type of IPsec VPN SPA into the same slot, the crypto connections will be reestablished. To move the IPsec VPN SPA to a different slot, you must first manually remove the crypto connections before removing the IPsec VPN SPA. You can enter the no crypto connect vlan command from any interface when the associated physical port is removed.
•When you reboot an IPsec VPN SPA that has crypto connections, the existing crypto configuration remains intact. The crypto connections will be reestablished after the IPsec VPN SPA reboots. When a crypto connection exists but the associated interface VLAN is missing from the IPsec VPN SPA inside port, the crypto connection is removed after the IPsec VPN SPA reboots.
•When you remove a port VLAN or an interface VLAN with the no interface vlan command, the associated crypto connection is also removed.
Displaying the SPA Hardware Type
There are several commands on the Catalyst 6500 Series switch that provide IPsec VPN SPA hardware information.
•To verify the SPA hardware type that is installed in your switch, use the show module command.
•To display hardware information for the IPsec VPN SPA, use the show crypto eli command.
For more information about these commands, see the Catalyst 6500 Series Cisco IOS Command Reference, Release 12.2SX.
Example of the show module Command
The following example shows output from the show module command on a Catalyst 6500 Series switch with an IPsec VPN SPA installed in subslot 0 of a Cisco 7600 SSC-400 that is installed in slot 4:
Router# show module 4
Mod Ports Card Type Model Serial No.
--- ----- -------------------------------------- ------------------ -----------
4 0 2-subslot Services SPA Carrier-400 7600-SSC-400 JAB1104013N
Mod MAC addresses Hw Fw Sw Status
--- ---------------------------------- ------ ------------ ------------ -------
4 001a.a1aa.95f0 to 001a.a1aa.962f 2.0 12.2(33)SXH 12.2(33)SXH Ok
Mod Sub-Module Model Serial Hw Status
---- --------------------------- ------------------ ----------- ------- -------
4/0 2 Gbps IPSec SPA SPA-IPSEC-2G JAB1048075L 1.0 Ok
Mod Online Diag Status
---- -------------------
4 Pass
4/0 Pass
Example of the show crypto eli Command
The following example shows output from the show crypto eli command on a Catalyst 6500 Series switch with IPsec VPN SPAs installed in subslots 0 and 1 of a Cisco 7600 SSC-400 that is installed in slot 3. The output displays how many IKE-SAs and IPsec sessions are active and how many Diffie-Hellman keys are in use for each IPsec VPN SPA.
Router# show crypto eli
Hardware Encryption : ACTIVE
Number of hardware crypto engines = 2
CryptoEngine SPA-IPSEC-2G[3/0] details: state = Active
Capability :
IPSEC: DES, 3DES, AES, RSA
IKE-Session : 0 active, 16383 max, 0 failed
DH : 0 active, 9999 max, 0 failed
IPSec-Session : 0 active, 65534 max, 0 failed
CryptoEngine SPA-IPSEC-2G[3/1] details: state = Active
Capability :
IPSEC: DES, 3DES, AES, RSA
IKE-Session : 1 active, 16383 max, 0 failed
DH : 0 active, 9999 max, 0 failed
IPSec-Session : 2 active, 65534 max, 0 failed