Revision as of 10:36, 13 September 2010

This section introduces the basic concepts, methodology, and general troubleshooting guidelines for problems that may occur when configuring IPsec and using the Cisco MDS 9000 Family of multilayer directors and fabric switches.

Troubleshooting IPsec

This section describes how to troubleshoot IP security (IPsec) and Internet Key Exchange (IKE) encryption in the Cisco MDS 9000 Family. It includes the following sections:

Overview

Initial Troubleshooting Checklist

IPsec Issues

Overview

The IPsec protocol is a framework of open standards that provides data confidentiality, data integrity, and data authentication between participating peers. It was developed by the Internet Engineering Task Force (IETF). IPsec provides security services at the IP layer, including protecting one or more data flows between a pair of hosts, between a pair of security gateways, or between a security gateway and a host. IPsec is supported for iSCSI and FCIP using IKE and Encapsulated Security Protocol (ESP) in tunnel mode.

IPsec Compatibility

Cisco MDS 9216i Switch with the MPS-14/2 capability in the integrated supervisor module. Refer to the Cisco MDS 9200 Series Hardware Installation Guide for more information on the Cisco MDS 9216i Switch.

The IPsec feature is not supported on the management interface.

Note:

IPsec and IKE are not supported by the Cisco Fabric Switch HP c-Class BladeSystem and the Cisco Fabric Switch for IBM BladeCenter.

The following features are not supported in the Cisco SAN-OS implementation of the IPsec feature:

Authentication Header (AH)

Transport mode

Security association bundling

Manually configuring security associations

Per host security association option in a crypto map

Security association idle timeout

Dynamic crypto maps

IPv6

Note:

Any reference to crypto maps in this document only refers to static crypto maps.

For IPsec to interoperate effectively with Microsoft iSCSI initiators, specify the TCP protocol and the local iSCSI TCP port number (default 3260) in the IPv4-ACL. This configuration ensures the speedy recovery of encrypted iSCSI sessions following disruptions such as Gigabit Ethernet interfaces shutdowns, VRRP switchovers, and port failures. The following example of a IPv4-ACL entry shows that the MDS switch IPv4 address is 10.10.10.50 and remote Microsoft host running encrypted iSCSI sessions is 10.10.10.16:

2. Ensure that at least one matching policy that has the same encryption algorithm, hash algorithm, and Diffie-Hellman (DH) group is configured on each switch. Issue the show crypto ike domain ipsec policycommandon both switches'. 'Example command outputs for the configuration shown in Figure 22-1 follow:

Verifying Interface Status Using Fabric Manager

To verify the status of the interfaces using Fabric Manager, follow these steps:

1. Choose Switches > Interfaces > GigabitEthernet to verify that the interfaces are up and their IP addresses are correct.

2. Choose ISLs > FCIP and select the Tunnels tab. Verify that each interface is using the correct profile, the peer internet addresses are configured correctly, and the FCIP tunnels are compatible.

Verifying Interface Status Using the CLI

To verify the status of the interfaces using the CLI, follow these steps:

1. Issue the show interface gigabitethernet command on both switches. Verify that the interfaces are up and their IP addresses are correct. Issue the no shutdown command if necessary. The command outputs follow:

2. Issue the show interface fcip command on both switches. Verify that each interface is using the correct profile, the peer internet addresses are configured correctly, and the FCIP tunnels are compatible. Issue the no shutdown command if necessary. The command outputs follow:

2. The SA index can be used to look at the SA in the crypto-accelerator. Issue the show ipsec internal crypto-accelerator interface gigabitethernetslot/portsad [inbound | outbound] sa-index command to display the inbound or outbound SA information. The hard limit bytes and soft limit bytes fields display the lifetime in bytes. The hard limit expiry secs and the soft limit expiry secs fields display the lifetime in seconds.

Note:

To issue commands with the internal keyword, you must have an account that is a member of the network-admin group.

Security Associations Do Not Re-Key

A lifetime counter (in seconds and bytes) is maintained as soon as an SA is created. When the time limit expires, the SA is no longer operational and is automatically renegotiated (re-keyed) if traffic is present. If there is no traffic, the SA will not be re-keyed and the tunnel will go down.

The re-key operation starts when the soft lifetime expires. That happens approximately 20 to 30 seconds before the time-based lifetime expires, or when approximately 10 to 20 percent of the bytes are remaining in the bytes-based lifetime.