| show and debug commands are your friends for troubleshooting IPsec VPN issues on Cisco Router. You can diagnose any problem if you know how to use these commands and interpret their output correctly. This part of the chapter introduces and examines the show and debug commands in detail and tells you how to use them properly. show Commands show commands are used to determine the status of the tunnel and the activities relating to the tunnel. These commands display very short, concise information about the state of the tunnel. Most of the time, if interpreted properly, knowing the state of the tunnel helps you with first-hand analysis, and guides you in the right direction with your troubleshooting steps. For example, with the show crypto isakmp sa command (discussed next), if you realize that Phase I is not in the QM_IDLE state, then you need only to run the debug crypto isakmp command. show Command for Phase I To find the state information of Phase I of IPsec tunnel negotiation, use the following command: Router# show crypto isakmp sa [detail]
This command shows the Internet Security Association Management Protocol (ISAKMP) security associations built between peers. Example 6-1 shows ISAKMP SA between peer 20.1.1.1 and 30.1.1.1, which is in QM_IDLE state, which means that Main mode has been successfully completed. Example 6-1. Output for show crypto isakmp sa Command Router# show crypto isakmp sa dst src state conn-id slot 30.1.1.1 20.1.1.1 QM_IDLE 1 0
|
The ISAKMP SA can be in several; states, depending on which state of the negotiation is taking place. Knowing these states is important, because based on this state information, you can figure out in which state Phase I negotiation is occurring. Tables 6-1, 6-2, and 6-3 show the states displayed in the show crypto isakmp sa command when main mode, aggressive modes, and quick modes are being negotiated or have been negotiated. Table 6-1. States Displayed in the show crypto isakmp sa Command When Main Mode Is Being NegotiatedState | Descriptions |
|---|
OAK_MM_NO_STATE | This is the initial state of Phase I establishment life cycle. However, Phase I should be in this state momentarily and you might not be able to view this state during the normal Phase I buildup process. If you see Phase I in this state for a longer time, this is an indication that a failure of tunnel establishment for Phase I has occurred. | OAK_MM_SA_SETUP | The peers have agreed on parameters for the ISAKMP SA. Phase I will be in this state after packet 1 and packet 2 exchange of the Main Mode negotiation. | OAK_MM_KEY_EXCH | The peers have exchanged Diffie-Hellman public keys and have generated a shared secret. The ISAKMP SA remains unauthenticated. | OAK_MM_KEY_AUTH | The ISAKMP SA has been authenticated. If the router initiated this exchange, this state transitions immediately to OAK_QM_IDLE, and a quick mode exchange begins. |
Table 6-2. States Displayed in the show crypto isakmp sa Command When Aggressive Mode Is Being NegotiatedState | Description |
|---|
OAK_AG_NO_STATE | This is the initial state of Phase I establishment life cycle. However, Phase I should be in this state momentarily and you might not be able to view this state during the normal Phase I buildup process. If you see Phase I in this state for longer time, this is an indication that a failure of tunnel establishment for Phase I has occurred. | OAK_AG_INIT_EXCH | The peers have performed the first exchange in aggressive mode, but the SA is not authenticated. | OAK_AG_AUTH | The ISAKMP SA has been authenticated. If the router initiated this exchange, this state transitions immediately to OAK_QM_IDLE, and a quick mode exchange begins. |
Table 6-3. States Displayed in the show crypto isakmp sa Command When Quick Mode Is Being NegotiatedState | Description |
|---|
OAK_QM_IDLE | The ISAKMP SA is idle. It remains authenticated with its peer and may be used for subsequent quick mode exchanges. |
show Commands for Phase II There are several show commands that can be used to find the IPsec counters to see if the packet is being encrypted, encapsulated, and sent or received correctly: | | 1. | show crypto ipsec sa [peer address]
This command shows the output of IPsec SAs between two peers. The encrypted tunnel is built between 20.1.1.1 and 30.1.1.1 for traffic going between networks 10.1.1.0 and 10.1.2.0. You can see the two Encapsulating Security Payloads (ESPs) that SAs built inbound and outbound. The authentication header (AH) is not used because there are no AH SAs.
Example 6-2 shows the output of the show crypto ipsec sa command.
Example 6-2. Sample Output for the show crypto ipsec sa Command Router# show crypto ipsec sa interface: FastEthernet0 Crypto map tag: test, local addr. 20.1.1.1 local ident (addr/mask/prot/port): (10.1.1.0/255.255.255.0/0/0) remote ident (addr/mask/prot/port): (10.1.2.0/255.255.255.0/0/0) current_peer: 30.1.1.1 PERMIT, flags={origin_is_acl,} #pkts encaps: 7767918, #pkts encrypt: 7767918, #pkts digest 7767918 #pkts decaps: 7760382, #pkts decrypt: 7760382, #pkts verify 7760382 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0, #send errors 1, #recv errors 0 local crypto endpt.: 20.1.1.1, remote crypto endpt.: 30.1.1.1 path mtu 1500, media mtu 1500 current outbound spi: 3D3 inbound esp sas: spi: 0x136A010F(325714191) transform: esp-3des esp-md5-hmac , in use settings ={Tunnel, } slot: 0, conn id: 3442, flow_id: 1443, crypto map: test sa timing: remaining key lifetime (k/sec): (4608000/52) IV size: 8 bytes replay detection support: Y inbound ah sas: inbound pcp sas: inbound pcp sas: outbound esp sas: spi: 0x3D3(979) transform: esp-3des esp-md5-hmac , in use settings ={Tunnel, } slot: 0, conn id: 3443, flow_id: 1444, crypto map: test sa timing: remaining key lifetime (k/sec): (4608000/52) IV size: 8 bytes replay detection support: Y outbound ah sas: outbound pcp sas:
|
| 2. | show crypto engine connections active
This command shows current active IPsec VPN connections and allows you to quickly check the packets are being encrypted or decrypted. Example 6-3 shows the output of show crypto engine connection active.
Example 6-3. Output for the show crypto engine connection active Command Router# show crypto engine connection active ID Interface IP-Address State Algorithm Encrypt Decrypt 1 Ethernet0/3 209.165.200.227 set HMAC_SHA+3DES_56_C 0 0 ! The following two lines shows 19 packets encrypted and decrypted 2000 Ethernet0/3 209.165.200.227 set HMAC_MD5+3DES_56_C 0 19 2001 Ethernet0/3 209.165.200.227 set HMAC_MD5+3DES_56_C 19 0 Router#
|
| 3. | show crypto engine connections dropped-packet
This command is used to find the dropped packets of an established IPsec tunnel. This is very useful because you know if you have performance issues, or suspect that the tunnel is dropping the packets.
|
show Commands for Interface Counters In additiion to analyzing the counters of IPsec tunnel, you also need to analyze the counters of the interfaces to see if the packets are being forwarded or received on the interfaces, as shown in the following section: 1. | show ip access-lists <number>
The <number> should be the number of the access-list used in the crypto map. This ensures that the packet is included in the interesting traffic access-list.
| 2. | show interface <interface name> statistics
This command shows the number of packets that are processed and fast-switched.
| 3. | show interfaces <interface name>
This command shows dropped packets, and input and output queue sizes.
|
show Command for Verifying IPsec Configuration If you have a tunnel establishment problem, you can use the following commands to verify the configuration on both peers of an IPsec tunnel: Verifying Policy Configuration The following command shows the policy configured on the router. At least one of the policies must match between the two peers for a successful tunnel establishment: Router# show crypto isakmp policy Verifying transform set configuration If the transform set does not match between peers, Phase II of tunnel establishment will fail. The following command allows you to verify the transform set configuration: Router# show crypto ipsec transform-set Verifying if the crypto map is applied correctly If Phase II is failing, you must ensure that the crypto map is applied to the correct interface, and if the interesting traffic ACL includes the traffic to go through the tunnel. For this, execute the show crypto map command as shown in Example 6-4. This gives you the summary version of IPsec configuration for Phase II. To verify that the crypto map is applied to the proper interface, use the command shown in Example 6-4. Example 6-4. Showing the Output of the show crypto map Command Router# show crypto map Crypto Map "mymap" 10 ipsec-isakmp Peer = 172.16.171.33 Peer = 172.16.171.39 ! Following line shows the interesting traffic for the VPN Extended IP access list 101 access-list 101 permit ip 10.1.2.0 0.0.0.255 10.1.1.0 0.0.0.255 ! This shows the peer of the IPSec tunnel Current peer: 172.16.171.33 ! Shows the lifetime of the Security Association Security association lifetime: 4608000 kilobytes/3600 seconds PFS (Y/N): N ! The transform set applied to the crypto map is shown below Transform sets={ myset, } ! Crypto map is applied to the Ethernet 0 interface. Interfaces using crypto map mymap: Ethernet0 Router#
|
Certificate Verification To verify the certificate on the router, use the following commands: Router# show crypto key pubkey-chain Router# show crypto key mypubkey
Commands for Tearing Down Tunnel To tear down the SA for Phase II, you can use the following command on both sides: Router# clear crypto sa
Then clear ISAKMP SA with the following command, which will tear down the ISAKMP SA: Router# clear crypto isakmp
This should send out a "delete" message to the peer; however, this is an unacknowledged message, which could be lost. debug Commands After you identify the state of the tunnel with show commands, you may run the debug command to see why the tunnel is in a particular state. debug commands tell you precisely where the tunnel is broken. The three most important and mostly used debug commands are shown in Example 6-5. Example 6-5. Running the debug Commands for the IPsec Tunnel Buildup Process ! The following command shows phase I information of an IPSec tunnel negotiation process Router# debug crypto ISAKMP ! The following commands shows phase II debug information of IPSec tunnel negotiation Router# debug crypto ipsec ! The following debug command shows additional details of the tunnel build up process Router# debug crypto engine ! To see isakmp packets, look for UDP packets to and from port 500. This debug is useful ! to see if the ISAKMP packets are hitting the router. Router# debug ip udp
|
Most of the time, you have to run the first three commands as shown in Example 6-5. The fourth debug command in the example is used only if you are unable to receive any IKE packets, but want to verify that the UDP/500 packets are reaching the router. Configure millisecond timestamps to find the exact timing of the problem with the following commands: Router(config)# service timestamps debug datetime msec Router(config)# service timestamps log datetime msec
To find additional details of a particular packet, that is, if it has been forwarded or dropped, or if there is a crypto failure, run the following debug: Router# debug ip packet [detail] <access-list-number>
You need to specify the access-list to capture the traffic you want. Note Turn on Process switching to see the details with this debug command output.
Caution Be very careful when running the debug ip packet detail command in a busy system, as this command generates a lot of debug output. Be sure to restrict the amount of traffic with access-list.
|
