- “Do I Know This Already?” Quiz
- Foundation Topics
- DMVPN Overview
- DVMPN Network Components
- DMVPN Design Considerations
- DMVPN Phase 1 Hub-and-Spoke Implementation
- DMVPN Phase 2 Spoke-to-Spoke Implementation
- DMVPN Phase 3 Spoke-to-Spoke Implementation
- DMVPN Troubleshooting
- Summary
- References
- Exam Preparation Tasks
- Review All Key Topics
- Complete Tables and Lists from Memory
- Define Key Terms
This chapter is from the book
This chapter is from the book
This chapter is from the book
DMVPN Troubleshooting
This final section of the chapter discusses troubleshooting DMVPN in terms of the same four steps used to configure DMVPN earlier in this chapter. You are expected to not only be able to build DMVPNs but also identify why a DMVPN is not working, which is why we stress how important it is for you to understand troubleshooting. We concluded Chapter 4, “Group Encrypted Transport VPN (GETVPN),” with steps to validate whether the VPN deployment is running, but in this chapter we skip validation and move right into troubleshooting because there are many overlapping steps with validation and troubleshooting. Know that the process used in this section is similar to validating or troubleshooting other site-to-site VPN deployments.
You can break troubleshooting into four parts that mirror the four configuration parts covered earlier in this chapter:
Troubleshooting the crypto IPsec policy configuration
Troubleshooting the GRE tunnel configuration
Troubleshooting the NHRP hub-and-spoke configuration
Troubleshoot the routing configuration
Troubleshooting the Crypto IPsec Policy Configuration
There are some key commands you can use to determine whether the crypto configuration is functioning correctly. To see whether IKE Phase 1 or IKE Phase 2 of the ISAKMP process is working, you issue the command show crypto isakmp sa on the hub router, as shown in Figure 5-12. This command determines whether IKE Phase 1 of the IPsec tunnel is up.
)
Figure 5-12 Output of the Command show crypto isakmp sa
The output QM_IDLE indicates that the VPN peers are authenticated, and the policy between the two devices has been accepted. This indicates that there is a match. If you see MM_Active, IKE Phase 1 failed, and you must validate your IKE policy on both sides of the link.
Troubleshooting IKE Phase 2
To troubleshoot IKE Phase 2, use these two commands:
show crypto ipsec sa
show crypto session detail
Figure 5-13 demonstrates the use of the first command, show crypto ipsec sa, to learn some important information, such as the crypto endpoints of both sides of the tunnel configuration. Data encapsulating (encaps) but not returning (decaps) indicates that you have a one-way tunnel, which typically means an ACL or NAT on either side of the tunnel is misconfigured.
)
Figure 5-13 Output of the Command show crypto ipsec sa
With each of the commands shown in Figure 5-12 and Figure 5-13, if you add the word detail at the end, the output shows more detailed counters. (For more troubleshooting commands and techniques, see the IPsec troubleshooting documentation listed at the end of the chapter.)
Troubleshooting the GRE Tunnel Configuration
The configuration of a tunnel in a DMVPN solution is somewhat different from the configuration of a tunnel used to repair a discontinuous OSPF area. In DMVPN tunnel configuration on the hub, you only have a tunnel source and not a tunnel destination. This is because the tunnel is configured to support NHRP configuration. The hub is dynamic, so it is waiting for inbound registrations and does not need a tunnel destination. The spokes have the destination of the tunnel endpoint mapped to the public IP address in the nhrp command in Example 5-12 for IPv4 and Example 5-13 for IPv6.
Validating the Tunnel
You must validate that the tunnel state is up/up after you apply the tunnel source command and enable the tunnel interface. You need to make sure you have selected the correct tunnel source interface. In Example 5-11, it is the outside IP address. (This is a common mistake in configuring tunnel interfaces.) In addition, you need to make sure you have the tunnel configured as an mGRE tunnel, especially on the hub side. If you’re using a tunnel key, both sides need to be the same.
Figure 5-14 shows the command show ip interface brief executed on the Spoke1 router. This validates that the Tunnel1 interface is in the up/up state.
)
Figure 5-14 Output of the Command show ip interface brief on an IPv4 Interface
Troubleshooting the NHRP Hub-and-Spoke Configuration
NHRP troubleshooting starts with issuing two basic commands on the spoke router. First, you need to determine if the VPN tunnel is up and functioning correctly. If it isn’t, you need to determine whether IKE Phase 1 or IKE Phase 2 is failing. If the tunnel is up when you issue show crypto isakmp sa, you should see QM_IDLE. If you see only encapsulations and not decapsulations, you know you have either a crypto IKE Phase 2 problem or an NHRP registration issue.
NHRP Registration
You must determine whether the NHRP spoke is registering. The command show ip nhrp nhs detail, shown in Figure 5-15, tells you whether you have both sent and received packets from the NHRP NHS. If you see that the request has been sent (req-sent) but no replies have been received (repl-recv) and the request failed (req-failed) count is increasing, then you know you have an NHRP spoke that is unable to register with the NHS.
)
Figure 5-15 Output of the Command show ip nhrp nhs detail
Tunnel Configuration
It is important to validate that the configuration of the tunnel interface is correct. Take a look at Figure 5-15, and make sure you have the correct information on the NHS, which in this example is the IP address of the tunnel interface of the hub router. This is the first area that might be misconfigured. Check your documentation and make sure this address is correct. Then verify that the command ip nhrp map references the tunnel address first, followed by the outside IP address (NBMA) of the hub router.
Figure 5-16 shows the command show ipv6 nhrp nhs detail executed on the Spoke1 router. The output provides information on the IPv6 address of the tunnel interface for the NHRP server. It validates that the NHRP configuration information on the spoke is valid.
)
Figure 5-16 Output of the Command show ipv6 nhrp nhs detail
Debugging
If you determine that so far everything is correct, you can turn on debugging for NHRP packets on the hub router to see if they are being received by the NHS and why the NHS cannot respond. You can force a registration attempt by shutting down the tunnel interface on the spoke router and then reenabling it. If you have debugging enabled on the hub router, you should see an inbound registration request.
Figure 5-17 shows the command debug nhrp packet executed on the NHRP server router. This also validates that the spoke router is attempting to register with the NHRP server. If you do not see inbound registration requests, then there is probably a misconfiguration of the NHRP server parameters on the spoke router.
)
Figure 5-17 Output of the Command debug nhrp packet
In the debug screen shown in Figure 5-17, you can see that the inbound registration request comes via the tunnel interface and includes the source NBMA IP address (the outside address) and the source protocol IP address (the tunnel address). In addition, it includes the destination protocol addresses. Each of these fields provides a good indication about whether the configuration on the host side is aligned with the hub router configuration.
Troubleshoot the Routing Configuration
Troubleshooting the routing protocol part of the DMVPN tunnel is not very complex. The challenge is whether you are able to see routes of other remote sites in the routing table. The first command to issue is show ip protocol. This command shows what IP blocks are being advertised. You should compare the spoke side to what the hub side is seeing in the routing table. If you execute show ip route and do not see the route in the table, then you should verify both the EIGRP autonomous system number and whether you have any security on the route exchanges. In addition, you should check to see if the hub router is summarizing the routes into a larger block. Finally, you should check to see what EIGRP neighbors the hub router identifies.
DMVPN Troubleshooting Summary
Table 5-3 consolidates some of the key commands covered so far, as well as a few more that are valuable for troubleshooting. The commands are organized in this table in the same parts as the DMVPN implementation shown in this chapter. Even if you configure your solution correctly the first time, it is good to use these commands to understand what the Cisco routers are doing in each of the phases.
Table 5-3 DMVPN Troubleshooting Commands
Troubleshooting Part |
Commands |
|---|---|
Crypto configuration (ISAKMP/IPSEC) |
show crypto isakmp sa show crypto ipsec sa debug crypto isakmp debug crypto ipsec |
Tunnel configuration |
show ip interface tunnel interface_number show ipv6 interface tunnel interface_number |
NHRP configuration |
show ip nhrp nhs detail show ipv6 nhrp nhs detail debug nhrp |
Routing configuration |
show ip protocol show ip route debug ip eigrp debug ip ospf adj debug ip ospf hello debug ip ospf packet |
That wraps up troubleshooting DMVPN troubleshooting fundamentals. Keep in mind thattroubleshooting makes up a major part of the SVPN exam.