Question 360 A tunnel interface stays up while the underlying ISP path fails, leaving the hub with a stale spoke route until a much longer routing timer expires. Which lasting design or operational safeguard best prevents this particular issue from recurring? Enforce uniform overlay encryption policy and automated tunnel-profile compliance checks. Align routing next-hop policy with the deployed DMVPN phase and topology. Standardize tunnel type for the approved DMVPN phase and shortcut behavior. Include overlay transport-loss detection and timer tests in resilience reviews. ExplanationCorrect Answer D:Include overlay transport-loss detection and timer tests in resilience reviews. This addresses the recurring cause: Logical mGRE tunnel state need not reflect loss of a particular remote NBMA path. A targeted acceptance check is: Fail the ISP path and observe neighbor loss, route withdrawal and recovery over the backup path. Other Answers A:Enforce uniform overlay encryption policy and automated tunnel-profile compliance checks. Logical mGRE tunnel state need not reflect loss of a particular remote NBMA path. B:Align routing next-hop policy with the deployed DMVPN phase and topology. Logical mGRE tunnel state need not reflect loss of a particular remote NBMA path. C:Standardize tunnel type for the approved DMVPN phase and shortcut behavior. Logical mGRE tunnel state need not reflect loss of a particular remote NBMA path.
Question 361 A hub sees duplicate NHRP registrations for one tunnel address from two newly cloned spokes. Which corrective action most directly resolves the documented failure without suppressing unrelated safeguards? Assign each spoke a unique overlay tunnel IP and correct the cloned identity. Align the tunnel and NHRP identity parameters with the hub's registered network design. Correct the NHRP NHS tunnel address and its associated NBMA mapping. Refresh the spoke's registration and correct NAT or mapping behavior for its current NBMA endpoint. ExplanationCorrect Answer A:Assign each spoke a unique overlay tunnel IP and correct the cloned identity. NHRP registers a tunnel-to-NBMA mapping; duplicate tunnel addresses cause conflicting mappings and unpredictable forwarding. Check the hub cache for distinct tunnel addresses and stable unique NBMA resolutions. Other Answers B:Align the tunnel and NHRP identity parameters with the hub's registered network design. NHRP registers a tunnel-to-NBMA mapping; duplicate tunnel addresses cause conflicting mappings and unpredictable forwarding. C:Correct the NHRP NHS tunnel address and its associated NBMA mapping. NHRP registers a tunnel-to-NBMA mapping; duplicate tunnel addresses cause conflicting mappings and unpredictable forwarding. D:Refresh the spoke's registration and correct NAT or mapping behavior for its current NBMA endpoint. NHRP registers a tunnel-to-NBMA mapping; duplicate tunnel addresses cause conflicting mappings and unpredictable forwarding.
Question 362 A hub sees duplicate NHRP registrations for one tunnel address from two newly cloned spokes. Which technical mechanism best explains the behavior observed in this scenario? NHRP authentication and policy can refuse resolution even when basic hub registration exists. NHRP registers a tunnel-to-NBMA mapping; duplicate tunnel addresses cause conflicting mappings and unpredictable forwarding. Spoke-to-spoke shortcuts need both NBMA resolution and routing next-hop semantics compatible with direct forwarding. NHRP registration requires compatible tunnel identity and reachability to the configured Next Hop Server. ExplanationCorrect Answer B:NHRP registers a tunnel-to-NBMA mapping; duplicate tunnel addresses cause conflicting mappings and unpredictable forwarding. This explains why the initial condition produces the observed failure. The direct repair is: Assign each spoke a unique overlay tunnel IP and correct the cloned identity. Validate through: Check the hub cache for distinct tunnel addresses and stable unique NBMA resolutions. Other Answers A:NHRP authentication and policy can refuse resolution even when basic hub registration exists. NHRP registers a tunnel-to-NBMA mapping; duplicate tunnel addresses cause conflicting mappings and unpredictable forwarding. C:Spoke-to-spoke shortcuts need both NBMA resolution and routing next-hop semantics compatible with direct forwarding. NHRP registers a tunnel-to-NBMA mapping; duplicate tunnel addresses cause conflicting mappings and unpredictable forwarding. D:NHRP registration requires compatible tunnel identity and reachability to the configured Next Hop Server. NHRP registers a tunnel-to-NBMA mapping; duplicate tunnel addresses cause conflicting mappings and unpredictable forwarding.
Question 363 A hub sees duplicate NHRP registrations for one tunnel address from two newly cloned spokes. After applying the correction, which verification evidence most directly demonstrates that this issue is resolved? Test DF-sized packets and representative TCP application transfers after the MTU/MSS correction. Confirm accepted NHRP mapping replies and successful targeted spoke-to-spoke data exchange. Check the hub cache for distinct tunnel addresses and stable unique NBMA resolutions. Inspect the route's next hop plus NHRP shortcut entry and capture direct spoke-to-spoke packets. ExplanationCorrect Answer C:Check the hub cache for distinct tunnel addresses and stable unique NBMA resolutions. This checks the affected traffic or control-plane behavior, not merely a generic up/down indicator. The underlying mechanism is: NHRP registers a tunnel-to-NBMA mapping; duplicate tunnel addresses cause conflicting mappings and unpredictable forwarding. Other Answers A:Test DF-sized packets and representative TCP application transfers after the MTU/MSS correction. NHRP registers a tunnel-to-NBMA mapping; duplicate tunnel addresses cause conflicting mappings and unpredictable forwarding. B:Confirm accepted NHRP mapping replies and successful targeted spoke-to-spoke data exchange. NHRP registers a tunnel-to-NBMA mapping; duplicate tunnel addresses cause conflicting mappings and unpredictable forwarding. D:Inspect the route's next hop plus NHRP shortcut entry and capture direct spoke-to-spoke packets. NHRP registers a tunnel-to-NBMA mapping; duplicate tunnel addresses cause conflicting mappings and unpredictable forwarding.
Question 364 A hub sees duplicate NHRP registrations for one tunnel address from two newly cloned spokes. Which lasting design or operational safeguard best prevents this particular issue from recurring? Maintain approved interoperable cryptographic policy across hub and spoke firmware versions. Validate both tunnel and underlay address roles during spoke provisioning. Enforce uniform overlay encryption policy and automated tunnel-profile compliance checks. Prevent duplicated tunnel identity fields in automated branch provisioning. ExplanationCorrect Answer D:Prevent duplicated tunnel identity fields in automated branch provisioning. This addresses the recurring cause: NHRP registers a tunnel-to-NBMA mapping; duplicate tunnel addresses cause conflicting mappings and unpredictable forwarding. A targeted acceptance check is: Check the hub cache for distinct tunnel addresses and stable unique NBMA resolutions. Other Answers A:Maintain approved interoperable cryptographic policy across hub and spoke firmware versions. NHRP registers a tunnel-to-NBMA mapping; duplicate tunnel addresses cause conflicting mappings and unpredictable forwarding. B:Validate both tunnel and underlay address roles during spoke provisioning. NHRP registers a tunnel-to-NBMA mapping; duplicate tunnel addresses cause conflicting mappings and unpredictable forwarding. C:Enforce uniform overlay encryption policy and automated tunnel-profile compliance checks. NHRP registers a tunnel-to-NBMA mapping; duplicate tunnel addresses cause conflicting mappings and unpredictable forwarding.
Question 365 A direct spoke-to-spoke packet reaches a peer's public IP, but the IKE responder uses a profile that matches only the hub identity. Which corrective action most directly resolves the documented failure without suppressing unrelated safeguards? Extend approved dynamic peer/profile matching to authorized spoke identities while keeping authentication restrictive. Align the tunnel and NHRP identity parameters with the hub's registered network design. Correct overlay route origination or route selection for the affected private prefixes. Review split-horizon behavior on the hub's multipoint tunnel and correct it for the overlay routing design. ExplanationCorrect Answer A:Extend approved dynamic peer/profile matching to authorized spoke identities while keeping authentication restrictive. Direct DMVPN peers must establish suitable security associations, not just resolve each other's NBMA endpoints. Observe the expected spoke-to-spoke IKE/IPsec SA with the correct negotiated authentication identity. Other Answers B:Align the tunnel and NHRP identity parameters with the hub's registered network design. Direct DMVPN peers must establish suitable security associations, not just resolve each other's NBMA endpoints. C:Correct overlay route origination or route selection for the affected private prefixes. Direct DMVPN peers must establish suitable security associations, not just resolve each other's NBMA endpoints. D:Review split-horizon behavior on the hub's multipoint tunnel and correct it for the overlay routing design. Direct DMVPN peers must establish suitable security associations, not just resolve each other's NBMA endpoints.
Question 366 A direct spoke-to-spoke packet reaches a peer's public IP, but the IKE responder uses a profile that matches only the hub identity. Which technical mechanism best explains the behavior observed in this scenario? NHRP authentication and policy can refuse resolution even when basic hub registration exists. Direct DMVPN peers must establish suitable security associations, not just resolve each other's NBMA endpoints. Spoke-to-spoke shortcuts need both NBMA resolution and routing next-hop semantics compatible with direct forwarding. DMVPN provides overlay reachability; dynamic route exchange is still governed by the separate routing protocol configuration. ExplanationCorrect Answer B:Direct DMVPN peers must establish suitable security associations, not just resolve each other's NBMA endpoints. This explains why the initial condition produces the observed failure. The direct repair is: Extend approved dynamic peer/profile matching to authorized spoke identities while keeping authentication restrictive. Validate through: Observe the expected spoke-to-spoke IKE/IPsec SA with the correct negotiated authentication identity. Other Answers A:NHRP authentication and policy can refuse resolution even when basic hub registration exists. Direct DMVPN peers must establish suitable security associations, not just resolve each other's NBMA endpoints. C:Spoke-to-spoke shortcuts need both NBMA resolution and routing next-hop semantics compatible with direct forwarding. Direct DMVPN peers must establish suitable security associations, not just resolve each other's NBMA endpoints. D:DMVPN provides overlay reachability; dynamic route exchange is still governed by the separate routing protocol configuration. Direct DMVPN peers must establish suitable security associations, not just resolve each other's NBMA endpoints.
Question 367 A direct spoke-to-spoke packet reaches a peer's public IP, but the IKE responder uses a profile that matches only the hub identity. After applying the correction, which verification evidence most directly demonstrates that this issue is resolved? Confirm registration to the approved active NHS and traffic forwarding after the old hub goes away. Inspect the route's next hop plus NHRP shortcut entry and capture direct spoke-to-spoke packets. Observe the expected spoke-to-spoke IKE/IPsec SA with the correct negotiated authentication identity. Inspect private-prefix routes and observe packets encapsulated into the tunnel rather than sent directly to WAN. ExplanationCorrect Answer C:Observe the expected spoke-to-spoke IKE/IPsec SA with the correct negotiated authentication identity. This checks the affected traffic or control-plane behavior, not merely a generic up/down indicator. The underlying mechanism is: Direct DMVPN peers must establish suitable security associations, not just resolve each other's NBMA endpoints. Other Answers A:Confirm registration to the approved active NHS and traffic forwarding after the old hub goes away. Direct DMVPN peers must establish suitable security associations, not just resolve each other's NBMA endpoints. B:Inspect the route's next hop plus NHRP shortcut entry and capture direct spoke-to-spoke packets. Direct DMVPN peers must establish suitable security associations, not just resolve each other's NBMA endpoints. D:Inspect private-prefix routes and observe packets encapsulated into the tunnel rather than sent directly to WAN. Direct DMVPN peers must establish suitable security associations, not just resolve each other's NBMA endpoints.
Question 368 A direct spoke-to-spoke packet reaches a peer's public IP, but the IKE responder uses a profile that matches only the hub identity. Which lasting design or operational safeguard best prevents this particular issue from recurring? Validate both tunnel and underlay address roles during spoke provisioning. Enforce uniform overlay encryption policy and automated tunnel-profile compliance checks. Maintain approved interoperable cryptographic policy across hub and spoke firmware versions. Test hub and dynamic spoke peer coverage in cryptographic profile changes. ExplanationCorrect Answer D:Test hub and dynamic spoke peer coverage in cryptographic profile changes. This addresses the recurring cause: Direct DMVPN peers must establish suitable security associations, not just resolve each other's NBMA endpoints. A targeted acceptance check is: Observe the expected spoke-to-spoke IKE/IPsec SA with the correct negotiated authentication identity. Other Answers A:Validate both tunnel and underlay address roles during spoke provisioning. Direct DMVPN peers must establish suitable security associations, not just resolve each other's NBMA endpoints. B:Enforce uniform overlay encryption policy and automated tunnel-profile compliance checks. Direct DMVPN peers must establish suitable security associations, not just resolve each other's NBMA endpoints. C:Maintain approved interoperable cryptographic policy across hub and spoke firmware versions. Direct DMVPN peers must establish suitable security associations, not just resolve each other's NBMA endpoints.
Question 369 The hub has routes for a spoke prefix but a newly deployed spoke cannot advertise its LAN because the routing protocol is disabled on the tunnel interface. Which corrective action most directly resolves the documented failure without suppressing unrelated safeguards? Enable the intended routing process or address-family interface participation on that spoke tunnel. Validate NAT traversal and peer identity handling in the IKE/IPsec design, then correct supported settings. Use compatible routing failure detection and verify underlay-to-overlay withdrawal rather than trusting logical tunnel state. Repair the tunnel MTU and TCP MSS/path-MTU handling based on actual encapsulation overhead. ExplanationCorrect Answer A:Enable the intended routing process or address-family interface participation on that spoke tunnel. DMVPN provides overlay reachability; dynamic route exchange is still governed by the separate routing protocol configuration. Verify tunnel neighbor establishment and advertisement of the spoke's LAN prefix. Other Answers B:Validate NAT traversal and peer identity handling in the IKE/IPsec design, then correct supported settings. DMVPN provides overlay reachability; dynamic route exchange is still governed by the separate routing protocol configuration. C:Use compatible routing failure detection and verify underlay-to-overlay withdrawal rather than trusting logical tunnel state. DMVPN provides overlay reachability; dynamic route exchange is still governed by the separate routing protocol configuration. D:Repair the tunnel MTU and TCP MSS/path-MTU handling based on actual encapsulation overhead. DMVPN provides overlay reachability; dynamic route exchange is still governed by the separate routing protocol configuration.
Question 370 The hub has routes for a spoke prefix but a newly deployed spoke cannot advertise its LAN because the routing protocol is disabled on the tunnel interface. Which technical mechanism best explains the behavior observed in this scenario? Logical mGRE tunnel state need not reflect loss of a particular remote NBMA path. DMVPN provides overlay reachability; dynamic route exchange is still governed by the separate routing protocol configuration. NHRP registration targets explicitly configured NHS resources; unused server mappings do not migrate automatically. GRE/NHRP mapping can succeed while IPsec protection fails because cryptographic proposal negotiation is a separate step. ExplanationCorrect Answer B:DMVPN provides overlay reachability; dynamic route exchange is still governed by the separate routing protocol configuration. This explains why the initial condition produces the observed failure. The direct repair is: Enable the intended routing process or address-family interface participation on that spoke tunnel. Validate through: Verify tunnel neighbor establishment and advertisement of the spoke's LAN prefix. Other Answers A:Logical mGRE tunnel state need not reflect loss of a particular remote NBMA path. DMVPN provides overlay reachability; dynamic route exchange is still governed by the separate routing protocol configuration. C:NHRP registration targets explicitly configured NHS resources; unused server mappings do not migrate automatically. DMVPN provides overlay reachability; dynamic route exchange is still governed by the separate routing protocol configuration. D:GRE/NHRP mapping can succeed while IPsec protection fails because cryptographic proposal negotiation is a separate step. DMVPN provides overlay reachability; dynamic route exchange is still governed by the separate routing protocol configuration.
