Crypto Socket Creation Problem
Crypto socket is a bridge between the NHRP and the IPsec crypto tunnel. If the crypto socket creation fails, the NHRP also will fail. Example 6-35 shows successful crypto socket creation.
Example 6-35. Successful Crypto Socket Built Up
Hub1# show crypto socket |
If you experience a problem with crypto socket creation, the only remedy as of the writing of this book is to reboot the router, which frees the stuck crypto socket. There is no CLI command to unstick a crypto socket.
Crypto VPN problem
To find out if IPsec is causing the problem, simply remove the tunnel protection ipsec profile profile_name command from the tunnel interface and see if everything works well. After removing this command, NHRP will go over IP instead of IPsec. If this test reveals an IPsec issue, troubleshoot it just as discussed in the "LAN-to-LAN" troubleshooting section.
Dynamic Routing Protocol Problem
Following is a list of dynamic routing protocols you can configure in the DMVPN network:
-
Enhanced Interior Gateway Routing Protocol (EIGRP)
Be sure that the following line is configured for the hub and spoke deployment:
no ip split-horizon eigrp
no auto-summaryIf you have spoke-to-spoke deployment, configure the following command.
no ip next-hop-self eigrp
You must be running Cisco IOS Version 12.3(1) to run the this command.
-
Open Shortest Path First (OSPF)
To use OSPF in the DMVPN network, configure the following commands:
ip ospf network broadcast
ip ospf priority (2(hub)|0(spoke)) -
Border Gateway Protocol (BGP)
If you configure BGP, you must configure the hub as the route reflector.
-
Routing Information Protocol (RIP)
If RIP is configured on the DMVPN network, configure the following under the RIP routing process:
no ip split-horizon
no auto-summary
It is strongly recommended that you configure EIGRP on the DMVPN network.
If you have problems with neighbor relationships with the dynamic routing protocol, pay close attention on the following:
-
Make sure that on the hub router, you have the following command in the tunnel interface:
ip nhrp map multicast dynamic
-
You must avoid this configuration on the spoke; otherwise you might experience neighbor flaps. On the spoke you should have the following configured for the multicast:
ip nhrp map multicast NBMA_Address (Physical_Interface)_Of_Hub
This is because the spokes do not have to send any multicast to other spokes; they have to send multicast to the hub to build up the neighbor relationship.
-
On the spokes, you must not configure more than two multipoint GRE tunnels sharing the same source interface.
Passing Data Across an Established Tunnel Problem
If everything looks good, but you are unable to pass traffic, remember the following points:
-
When the hub is behind the PAT device, there are no restrictions.
-
If you are using IPsec Transport mode (highly recommended), two spokes may have the same pre-NAT (outside physical address) but must have unique post-NAT addresses. This means that two spoke routers behind the same NAT box must be translated to unique post-NAT IP addresses. Two spokes behind different NAT boxes may have the same pre-NAT IP address (of course they would have different post-NAT IP addresses).
-
If you are using IPsec Tunnel mode, all spokes must have unique pre-NAT IP addresses, but may have the same post-NAT IP addresses. This means that two spokes behind different NAT boxes must have unique pre-NAT IP addresses. Two spokes behind the same NAT device (of course will have unique pre-NAT IP addresses), may have the same post-NAT IP address.
-
You must turn on CEF switching.