300-410 DMVPN — 15 Questions

Question 1

A network engineer is troubleshooting a DMVPN phase 2 hub-and-spoke deployment. The hub router has mGRE and NHRP configured, and spokes register successfully. However, spoke-to-spoke traffic is not being encrypted, even though IPsec profiles are applied to the mGRE tunnel interface on both the hub and spokes. The engineer verifies that the crypto map is not applied to the tunnel interface. What is the most likely cause of this issue?

Accepted Answer

The IPsec profile is not applied to the mGRE tunnel interface on the hub and spokes.. In DMVPN phase 2, spoke-to-spoke dynamic tunnels require IPsec protection. The IPsec profile must be applied to the tunnel interface, not a crypto map. If the crypto map is missing or misapplied, IPsec will not be triggered for spoke-to-spoke traffic.

Answer

The NHRP authentication string does not match between the hub and spokes.

Answer

The tunnel key is not configured on the spokes.

Answer

The spokes have a static crypto map applied to their physical interface.

Question 2

An engineer is troubleshooting a DMVPN phase 3 network where spoke-to-spoke tunnels are not being established dynamically. The hub router has NHRP redirect enabled, and spokes have NHRP shortcut enabled. The engineer notices that when a spoke sends traffic to another spoke, the hub forwards the traffic but does not send an NHRP redirect. The hub's NHRP configuration includes the command 'ip nhrp redirect'. What is the most likely cause?

Accepted Answer

The hub router does not have a route to the spoke's LAN subnet.. In DMVPN phase 3, the hub must have 'ip nhrp redirect' enabled on the tunnel interface, and the spoke must have 'ip nhrp shortcut' enabled. Additionally, the hub must have a route to the spoke's subnet; otherwise, the hub will not send an NHRP redirect. The issue is that the hub does not have a route to the spoke's subnet.

Answer

The spoke does not have 'ip nhrp shortcut' enabled.

Answer

The tunnel interface on the hub has 'no ip nhrp redirect' configured.

Answer

The spoke's NHRP registration does not include the LAN subnet.

Question 3

A network engineer is troubleshooting a DMVPN phase 2 network where spoke-to-spoke tunnels are established, but traffic between spokes is intermittently dropped. The engineer captures packets and sees that IPsec packets are being fragmented. The tunnel interface MTU is set to 1400 bytes, and the physical interface MTU is 1500 bytes. The engineer also notices that the IPsec transform set uses ESP with AES-256 and SHA-256. What is the most likely cause of the intermittent drops?

Accepted Answer

The tunnel MTU is set too high for the IPsec overhead, causing fragmentation and potential drops.. IPsec adds overhead (ESP header, trailer, and authentication data). With AES-256 and SHA-256, the overhead can be around 50-60 bytes. If the tunnel MTU is set to 1400, the effective payload MTU is lower. Fragmentation can cause drops if the DF bit is set or if intermediate routers drop fragments. The issue is that the tunnel MTU is too high for the IPsec overhead, causing fragmentation.

Answer

The IPsec transform set uses AES-256, which requires more CPU and causes performance drops.

Answer

The physical interface MTU is set to 1500, which is too high for DMVPN.

Answer

The spokes have different IPsec transform sets configured.

Question 4

An engineer is troubleshooting a DMVPN phase 3 network where spokes are unable to reach the hub's LAN subnet. The hub router is running EIGRP over the DMVPN tunnel interface, and the spokes are learning the hub's LAN route. However, pings from a spoke to the hub's LAN IP fail. The engineer checks the hub's routing table and sees the spoke's LAN route. The hub's tunnel interface has 'ip nhrp redirect' and 'ip nhrp shortcut' enabled. What is the most likely cause?

Accepted Answer

The hub's EIGRP is not configured to advertise the LAN subnet.. In DMVPN phase 3, the hub's NHRP redirect and shortcut features can cause the hub to forward traffic to the spoke's LAN via the spoke's tunnel IP, but if the spoke's LAN subnet is not advertised via EIGRP, the hub may not have a route. However, the issue is that the hub's EIGRP is not advertising the hub's LAN subnet to the spokes, or the spokes are not receiving the route. The most common cause is that the hub's EIGRP network statement does not include the LAN subnet.

Answer

The spoke's tunnel interface has 'ip nhrp shortcut' disabled.

Answer

The hub's tunnel interface has 'no ip nhrp redirect' configured.

Answer

The spoke's NHRP registration is not reaching the hub.

Question 5

A network engineer is troubleshooting a DMVPN phase 2 network where the hub router is not forming an NHRP adjacency with a spoke. The spoke router is configured with 'ip nhrp nhs 10.0.0.1' and 'ip nhrp map 10.0.0.1 192.168.1.1'. The hub's tunnel interface IP is 10.0.0.1, and the physical interface IP is 192.168.1.1. The engineer pings the hub's tunnel IP from the spoke and it succeeds. However, 'show ip nhrp' on the spoke shows no NHRP entries. What is the most likely cause?

Accepted Answer

The hub router has 'ip nhrp authentication DMVPN' configured, but the spoke does not.. NHRP registration requires the spoke to send a Registration Request to the hub. If the hub does not respond, the spoke will not have NHRP entries. A common cause is that the hub's NHRP authentication is configured with a password, but the spoke's NHRP authentication is missing or mismatched.

Answer

The spoke's tunnel interface is in a different VRF than the hub's.

Answer

The hub's tunnel interface has 'no ip nhrp server-only' configured.

Answer

The spoke's NHRP map is incorrect; it should map the hub's tunnel IP to the hub's tunnel IP.

Question 6

An engineer is troubleshooting a DMVPN phase 3 network where spoke-to-spoke tunnels are established, but traffic between spokes is taking a suboptimal path through the hub. The engineer checks 'show ip nhrp shortcut' on the spoke and sees no shortcut entries. The hub has 'ip nhrp redirect' enabled, and the spoke has 'ip nhrp shortcut' enabled. The engineer also verifies that the spoke's routing table has a route to the remote spoke's LAN via the hub. What is the most likely cause?

Accepted Answer

The hub router does not have a route to the remote spoke's LAN subnet.. In DMVPN phase 3, for spoke-to-spoke shortcuts to be installed, the spoke must receive an NHRP redirect from the hub. If the hub does not send a redirect, the spoke will not create a shortcut. The hub sends a redirect only if it has a route to the destination subnet. If the hub does not have a route to the remote spoke's LAN, it will not send a redirect.

Answer

The spoke's 'ip nhrp shortcut' command is missing on the tunnel interface.

Answer

The spoke's routing table has a static route to the remote spoke's LAN via the hub.

Answer

The hub's tunnel interface has 'no ip nhrp redirect' configured.

Question 7

A network engineer is troubleshooting a DMVPN phase 2 network where the hub router is not learning the loopback interface routes from the spokes via EIGRP. The spokes have EIGRP configured on the tunnel interface and are advertising their loopback0 interface. The hub's EIGRP neighbor relationship with the spokes is established. However, the hub's routing table does not contain the loopback routes. The engineer checks the spoke's EIGRP configuration and sees that the loopback interface is not included in any network statement. What is the most likely cause?

Accepted Answer

The spoke's EIGRP network statement does not include the loopback subnet.. EIGRP only advertises networks that are included in a network statement or configured under the EIGRP process. If the loopback interface is not included in a network statement, EIGRP will not advertise it.

Answer

The hub's EIGRP is configured with a distribute-list that filters the loopback routes.

Answer

The tunnel interface on the spoke has 'no ip split-horizon' configured.

Answer

The loopback interface on the spoke is in a different VRF than the tunnel interface.

Question 8

An engineer is troubleshooting a DMVPN phase 2 network where the hub router is not forming an EIGRP neighbor relationship with a spoke. The spoke's tunnel interface is configured with 'ip nhrp nhs 10.0.0.1' and 'ip nhrp map 10.0.0.1 192.168.1.1'. The hub's tunnel interface IP is 10.0.0.1. The engineer pings the hub's tunnel IP from the spoke and it succeeds. The engineer checks 'show ip eigrp neighbors' on the hub and sees no neighbors. What is the most likely cause?

Accepted Answer

The spoke's tunnel interface is missing the 'ip nhrp map multicast dynamic' command.. EIGRP neighbor formation over a tunnel requires multicast support. In DMVPN, multicast traffic is sent via NHRP to the hub. If the spoke's tunnel interface does not have 'ip nhrp map multicast dynamic' or a static multicast map, the hub will not receive EIGRP hello packets from the spoke.

Answer

The hub's tunnel interface has 'no ip nhrp redirect' configured.

Answer

The spoke's EIGRP AS number does not match the hub's.

Answer

The hub's tunnel interface has 'ip nhrp authentication' configured but the spoke does not.

Question 9

A network engineer is troubleshooting a DMVPN phase 2 network where spoke-to-spoke tunnels are not being established. The hub router has 'ip nhrp redirect' enabled, and spokes have 'ip nhrp shortcut' enabled. The engineer notices that when a spoke sends traffic to another spoke, the hub forwards the traffic correctly, but the spoke does not initiate an NHRP resolution request to the destination spoke. The spoke's routing table shows the destination subnet via the hub. What is the most likely cause?

Accepted Answer

The spoke's tunnel interface does not have 'ip nhrp shortcut' enabled.. In DMVPN phase 2, spoke-to-spoke tunnels are triggered by the spoke sending an NHRP resolution request to the hub. The spoke will only send this request if it has a route to the destination subnet via the tunnel interface. If the spoke's routing table shows the route via the hub (next-hop is the hub's tunnel IP), the spoke should send a resolution request. However, if the spoke's 'ip nhrp shortcut' is not enabled, it will not attempt to create a shortcut. The issue is that 'ip nhrp shortcut' is missing on the spoke.

Answer

The hub's tunnel interface does not have 'ip nhrp redirect' enabled.

Answer

The spoke's routing table has a static route to the destination subnet via the hub.

Answer

The hub's NHRP authentication is configured but the spoke's is not.

Question 10

A network engineer runs the following command on Router R1:

R1# show dmvpn
Legend: Attrb -> S: Static, D: Dynamic, I: Incomplete
        N: NATed, L: Local, X: No Socket
        #Ent -> Number of NHRP entries with same NBMA peer
        NHS Status: E => Expecting Replies, R => Responding, W => Waiting
        UpDn Time -> Up or Down Time for a Tunnel
==========================================================================
Interface: Tunnel0, IPv4 NHRP Details
Type:Hub, NHRP Peers:2,

# Ent  Peer NBMA Addr Peer Tunnel Addr State  UpDn Tm Attrb
 ----- --------------- ---------------- ----- -------- -----
     1 10.1.1.2        172.16.0.2        UP    00:02:15 D
     1 10.1.1.3        172.16.0.3        UP    00:01:45 D

Based on this output, which statement is correct?

Accepted Answer

Router R1 is a hub with two dynamically registered spokes.. The show dmvpn command displays NHRP peers. The output shows two dynamic peers (D) with their NBMA and tunnel addresses. The hub has two spokes registered, both in UP state. The correct answer identifies the role and peer count.

Answer

Router R1 is a spoke with two hub peers.

Answer

The NHRP peers are static and not dynamic.

Answer

One spoke is experiencing a registration failure.

Question 11

A network engineer runs the following command on Router R1:

R1# show ip nhrp
192.168.1.0/24 via 172.16.0.2
   Tunnel0 created 00:00:15, expire 00:01:45
   Type: dynamic, Flags: unique
   NBMA address: 10.1.1.2
192.168.2.0/24 via 172.16.0.3
   Tunnel0 created 00:00:10, expire 00:01:50
   Type: dynamic, Flags: unique
   NBMA address: 10.1.1.3

Based on this output, what is the problem?

Accepted Answer

The NHRP holdtime is too short, causing frequent re-registrations.. The output shows NHRP cache entries for remote networks. The expire time is decreasing, indicating these are dynamic entries learned via NHRP. The problem is that the NHRP holdtime is set to 2 minutes (120 seconds), as seen from the expire time starting at 2 minutes. This is a short holdtime that may cause frequent re-registrations.

Answer

The NHRP entries are static and will not expire.

Answer

The tunnel interface is down.

Answer

The NBMA addresses are incorrect.

Question 12

A network engineer runs the following command on Router R1:

R1# show crypto isakmp sa
dst             src             state          conn-id slot status
10.1.1.2        10.1.1.1        MM_ACTIVE      1       0     ACTIVE
10.1.1.3        10.1.1.1        MM_ACTIVE      2       0     ACTIVE

Based on this output, which statement is correct?

Accepted Answer

IKE phase 1 is complete for both peers.. The show crypto isakmp sa command shows IKE phase 1 security associations. The state MM_ACTIVE indicates that IKE phase 1 is complete and active. The output shows two active SAs with the local router (10.1.1.1) and two remote peers (10.1.1.2 and 10.1.1.3).

Answer

IKE phase 2 is complete for both peers.

Answer

The IPsec tunnels are established.

Answer

The peers are not responding.

Question 13

A network engineer runs the following command on Router R1:

R1# show crypto ipsec sa
interface: Tunnel0
    Crypto map tag: DMVPN, local addr 10.1.1.1

protected vrf: (none)
   local  ident (addr/mask/prot/port): (172.16.0.0/255.255.255.0/47/0)
   remote ident (addr/mask/prot/port): (172.16.0.0/255.255.255.0/47/0)
   current_peer 10.1.1.2 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 150, #pkts encrypt: 150, #pkts digest: 150
    #pkts decaps: 145, #pkts decrypt: 145, #pkts verify: 145
    #send errors 0, #recv errors 0

local crypto endpt.: 10.1.1.1, remote crypto endpt.: 10.1.1.2
   path mtu 1500, ip mtu 1500, ip mtu idb Tunnel0
   current outbound spi: 0x12345678(305419896)
   PFS (Y/N): N, DH group: none

Based on this output, what is the problem?

Accepted Answer

There is packet loss on the IPsec tunnel.. The output shows IPsec SA details for a DMVPN tunnel. The protect identity uses GRE protocol (47) and the SA is between two spoke routers (172.16.0.0/24). The packet counts show 150 encapsulated but only 145 decapsulated, indicating packet loss on the tunnel. This could be due to MTU issues or routing problems.

Answer

The IPsec SA is using PFS.

Answer

The tunnel is not encrypting traffic.

Answer

The remote peer is 10.1.1.1.

Question 14

A network engineer runs the following command on Router R1:

R1# show ip route ospf
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       a - application route
       + - replicated route, % - next hop override

Gateway of last resort is not set

172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks
O        172.16.0.0/24 [110/100] via 172.16.0.2, 00:00:15, Tunnel0
O        172.16.0.0/24 [110/100] via 172.16.0.3, 00:00:10, Tunnel0

Based on this output, what is the problem?

Accepted Answer

OSPF is learning the same subnet from multiple spokes, indicating a misconfiguration.. The output shows OSPF routes for the same network 172.16.0.0/24 via two different next hops (172.16.0.2 and 172.16.0.3). This indicates that OSPF is seeing the same subnet from multiple spokes, which is incorrect because the tunnel network should be unique per spoke. This suggests a misconfiguration where the tunnel IP addresses are overlapping or OSPF is not properly filtering.

Answer

The OSPF cost is 100, which is high.

Answer

The routes are learned via EIGRP.

Answer

The tunnel interface is down.

Question 15

A network engineer runs the following command on Router R1:

R1# show dmvpn detail
Legend: Attrb -> S: Static, D: Dynamic, I: Incomplete
        N: NATed, L: Local, X: No Socket
        #Ent -> Number of NHRP entries with same NBMA peer
        NHS Status: E => Expecting Replies, R => Responding, W => Waiting
        UpDn Time -> Up or Down Time for a Tunnel
==========================================================================
Interface: Tunnel0, IPv4 NHRP Details
Type:Spoke, NHRP Peers:1,

# Ent  Peer NBMA Addr Peer Tunnel Addr State  UpDn Tm Attrb
 ----- --------------- ---------------- ----- -------- -----
     1 10.1.1.1        172.16.0.1        UP    00:10:00 S

Based on this output, what is the problem?

Accepted Answer

The spoke has a static NHRP mapping for the hub, which is correct for phase 1 DMVPN.. The output shows a spoke router with one NHRP peer (the hub) marked as static (S). The spoke is only seeing the hub, which is normal for a spoke. However, the problem is that the spoke is not seeing any other spokes, which is expected in a DMVPN phase 2 or 3 where spokes should see each other dynamically. But here the peer is static, indicating the spoke is configured with a static NHRP mapping for the hub, and no dynamic spoke-to-spoke tunnels are established.

Answer

The spoke has dynamically learned the hub.

Answer

The hub is not reachable.

Answer

The spoke is configured as a hub.