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.
Question 371 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. 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. Inspect the negotiated peer identity, NAT detection and successful protected tunnel packets. Verify tunnel neighbor establishment and advertisement of the spoke's LAN prefix. Observe the expected spoke-to-spoke IKE/IPsec SA with the correct negotiated authentication identity. ExplanationCorrect Answer C:Verify tunnel neighbor establishment and advertisement of the spoke's LAN prefix. This checks the affected traffic or control-plane behavior, not merely a generic up/down indicator. The underlying mechanism is: DMVPN provides overlay reachability; dynamic route exchange is still governed by the separate routing protocol configuration. Other Answers A:Test DF-sized packets and representative TCP application transfers after the MTU/MSS correction. DMVPN provides overlay reachability; dynamic route exchange is still governed by the separate routing protocol configuration. B:Inspect the negotiated peer identity, NAT detection and successful protected tunnel packets. DMVPN provides overlay reachability; dynamic route exchange is still governed by the separate routing protocol configuration. D:Observe the expected spoke-to-spoke IKE/IPsec SA with the correct negotiated authentication identity. DMVPN provides overlay reachability; dynamic route exchange is still governed by the separate routing protocol configuration.
Question 372 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 lasting design or operational safeguard best prevents this particular issue from recurring? Include encapsulation overhead and path-MTU tests in overlay design baselines. Enforce uniform overlay encryption policy and automated tunnel-profile compliance checks. Keep NHRP registration and resolution authorization aligned with the branch inventory. Validate overlay registration and routing-protocol adjacency as separate acceptance gates. ExplanationCorrect Answer D:Validate overlay registration and routing-protocol adjacency as separate acceptance gates. This addresses the recurring cause: DMVPN provides overlay reachability; dynamic route exchange is still governed by the separate routing protocol configuration. A targeted acceptance check is: Verify tunnel neighbor establishment and advertisement of the spoke's LAN prefix. Other Answers A:Include encapsulation overhead and path-MTU tests in overlay design baselines. DMVPN provides overlay reachability; dynamic route exchange is still governed by the separate routing protocol configuration. B:Enforce uniform overlay encryption policy and automated tunnel-profile compliance checks. DMVPN provides overlay reachability; dynamic route exchange is still governed by the separate routing protocol configuration. C:Keep NHRP registration and resolution authorization aligned with the branch inventory. DMVPN provides overlay reachability; dynamic route exchange is still governed by the separate routing protocol configuration.
Question 373 A spoke receives other branch prefixes, but direct shortcuts remain absent because its NHRP redirect/shortcut settings do not match the network's approved phase. Which corrective action most directly resolves the documented failure without suppressing unrelated safeguards? Configure the NHRP shortcut and redirect roles compatible with the actual DMVPN phase and software support. Correct overlay route origination or route selection for the affected private prefixes. Use compatible routing failure detection and verify underlay-to-overlay withdrawal rather than trusting logical tunnel state. Update the spoke's NHRP server mapping and routing policy to match the approved single-hub active design. ExplanationCorrect Answer A:Configure the NHRP shortcut and redirect roles compatible with the actual DMVPN phase and software support. NHRP shortcut establishment depends on the deployed phase's redirect and resolution behavior. Inspect hub redirects and spoke shortcut cache entries after generating branch-to-branch traffic. Other Answers B:Correct overlay route origination or route selection for the affected private prefixes. NHRP shortcut establishment depends on the deployed phase's redirect and resolution behavior. C:Use compatible routing failure detection and verify underlay-to-overlay withdrawal rather than trusting logical tunnel state. NHRP shortcut establishment depends on the deployed phase's redirect and resolution behavior. D:Update the spoke's NHRP server mapping and routing policy to match the approved single-hub active design. NHRP shortcut establishment depends on the deployed phase's redirect and resolution behavior.
Question 374 A spoke receives other branch prefixes, but direct shortcuts remain absent because its NHRP redirect/shortcut settings do not match the network's approved phase. Which technical mechanism best explains the behavior observed in this scenario? NHRP direct forwarding does not imply IPsec protection unless the relevant tunnel-protection design covers it. NHRP shortcut establishment depends on the deployed phase's redirect and resolution behavior. Split horizon may prevent a hub from advertising one spoke's route back onto the same multipoint interface. NHRP registers a tunnel-to-NBMA mapping; duplicate tunnel addresses cause conflicting mappings and unpredictable forwarding. ExplanationCorrect Answer B:NHRP shortcut establishment depends on the deployed phase's redirect and resolution behavior. This explains why the initial condition produces the observed failure. The direct repair is: Configure the NHRP shortcut and redirect roles compatible with the actual DMVPN phase and software support. Validate through: Inspect hub redirects and spoke shortcut cache entries after generating branch-to-branch traffic. Other Answers A:NHRP direct forwarding does not imply IPsec protection unless the relevant tunnel-protection design covers it. NHRP shortcut establishment depends on the deployed phase's redirect and resolution behavior. C:Split horizon may prevent a hub from advertising one spoke's route back onto the same multipoint interface. NHRP shortcut establishment depends on the deployed phase's redirect and resolution behavior. D:NHRP registers a tunnel-to-NBMA mapping; duplicate tunnel addresses cause conflicting mappings and unpredictable forwarding. NHRP shortcut establishment depends on the deployed phase's redirect and resolution behavior.
Question 375 A spoke receives other branch prefixes, but direct shortcuts remain absent because its NHRP redirect/shortcut settings do not match the network's approved phase. After applying the correction, which verification evidence most directly demonstrates that this issue is resolved? Capture SA counters for both hub-spoke and direct spoke-spoke flows under the policy. Confirm registration to the approved active NHS and traffic forwarding after the old hub goes away. Inspect hub redirects and spoke shortcut cache entries after generating branch-to-branch traffic. Inspect dynamic NHRP resolution and direct spoke-to-spoke encapsulation after the change. ExplanationCorrect Answer C:Inspect hub redirects and spoke shortcut cache entries after generating branch-to-branch traffic. This checks the affected traffic or control-plane behavior, not merely a generic up/down indicator. The underlying mechanism is: NHRP shortcut establishment depends on the deployed phase's redirect and resolution behavior. Other Answers A:Capture SA counters for both hub-spoke and direct spoke-spoke flows under the policy. NHRP shortcut establishment depends on the deployed phase's redirect and resolution behavior. B:Confirm registration to the approved active NHS and traffic forwarding after the old hub goes away. NHRP shortcut establishment depends on the deployed phase's redirect and resolution behavior. D:Inspect dynamic NHRP resolution and direct spoke-to-spoke encapsulation after the change. NHRP shortcut establishment depends on the deployed phase's redirect and resolution behavior.
Question 376 A spoke receives other branch prefixes, but direct shortcuts remain absent because its NHRP redirect/shortcut settings do not match the network's approved phase. Which lasting design or operational safeguard best prevents this particular issue from recurring? Validate both tunnel and underlay address roles during spoke provisioning. Include hub interface routing policies in DMVPN baseline validation. Standardize tunnel type for the approved DMVPN phase and shortcut behavior. Choose one documented DMVPN phase and validate its NHRP features on all nodes. ExplanationCorrect Answer D:Choose one documented DMVPN phase and validate its NHRP features on all nodes. This addresses the recurring cause: NHRP shortcut establishment depends on the deployed phase's redirect and resolution behavior. A targeted acceptance check is: Inspect hub redirects and spoke shortcut cache entries after generating branch-to-branch traffic. Other Answers A:Validate both tunnel and underlay address roles during spoke provisioning. NHRP shortcut establishment depends on the deployed phase's redirect and resolution behavior. B:Include hub interface routing policies in DMVPN baseline validation. NHRP shortcut establishment depends on the deployed phase's redirect and resolution behavior. C:Standardize tunnel type for the approved DMVPN phase and shortcut behavior. NHRP shortcut establishment depends on the deployed phase's redirect and resolution behavior.
Question 377 A DMVPN tunnel encrypts traffic to the hub but new direct spoke traffic passes without the required encryption profile after a template update. Which corrective action most directly resolves the documented failure without suppressing unrelated safeguards? Apply consistent tunnel protection to eligible spoke-to-spoke flows and reject unsecured paths. Correct the NHRP authorization or authentication settings to admit the approved spokes. Correct overlay route origination or route selection for the affected private prefixes. Correct the NHRP NHS tunnel address and its associated NBMA mapping. ExplanationCorrect Answer A:Apply consistent tunnel protection to eligible spoke-to-spoke flows and reject unsecured paths. NHRP direct forwarding does not imply IPsec protection unless the relevant tunnel-protection design covers it. Capture SA counters for both hub-spoke and direct spoke-spoke flows under the policy. Other Answers B:Correct the NHRP authorization or authentication settings to admit the approved spokes. NHRP direct forwarding does not imply IPsec protection unless the relevant tunnel-protection design covers it. C:Correct overlay route origination or route selection for the affected private prefixes. NHRP direct forwarding does not imply IPsec protection unless the relevant tunnel-protection design covers it. D:Correct the NHRP NHS tunnel address and its associated NBMA mapping. NHRP direct forwarding does not imply IPsec protection unless the relevant tunnel-protection design covers it.
Question 378 A DMVPN tunnel encrypts traffic to the hub but new direct spoke traffic passes without the required encryption profile after a template update. Which technical mechanism best explains the behavior observed in this scenario? NHRP registration requires compatible tunnel identity and reachability to the configured Next Hop Server. NHRP direct forwarding does not imply IPsec protection unless the relevant tunnel-protection design covers it. NHRP authentication and policy can refuse resolution even when basic hub registration exists. GRE tunnel reachability alone does not install destination routes; forwarding follows the active RIB or policy. ExplanationCorrect Answer B:NHRP direct forwarding does not imply IPsec protection unless the relevant tunnel-protection design covers it. This explains why the initial condition produces the observed failure. The direct repair is: Apply consistent tunnel protection to eligible spoke-to-spoke flows and reject unsecured paths. Validate through: Capture SA counters for both hub-spoke and direct spoke-spoke flows under the policy. Other Answers A:NHRP registration requires compatible tunnel identity and reachability to the configured Next Hop Server. NHRP direct forwarding does not imply IPsec protection unless the relevant tunnel-protection design covers it. C:NHRP authentication and policy can refuse resolution even when basic hub registration exists. NHRP direct forwarding does not imply IPsec protection unless the relevant tunnel-protection design covers it. D:GRE tunnel reachability alone does not install destination routes; forwarding follows the active RIB or policy. NHRP direct forwarding does not imply IPsec protection unless the relevant tunnel-protection design covers it.
Question 379 A DMVPN tunnel encrypts traffic to the hub but new direct spoke traffic passes without the required encryption profile after a template update. 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. Check the hub cache for distinct tunnel addresses and stable unique NBMA resolutions. Capture SA counters for both hub-spoke and direct spoke-spoke flows under the policy. Inspect dynamic NHRP resolution and direct spoke-to-spoke encapsulation after the change. ExplanationCorrect Answer C:Capture SA counters for both hub-spoke and direct spoke-spoke flows under the policy. This checks the affected traffic or control-plane behavior, not merely a generic up/down indicator. The underlying mechanism is: NHRP direct forwarding does not imply IPsec protection unless the relevant tunnel-protection design covers it. Other Answers A:Confirm registration to the approved active NHS and traffic forwarding after the old hub goes away. NHRP direct forwarding does not imply IPsec protection unless the relevant tunnel-protection design covers it. B:Check the hub cache for distinct tunnel addresses and stable unique NBMA resolutions. NHRP direct forwarding does not imply IPsec protection unless the relevant tunnel-protection design covers it. D:Inspect dynamic NHRP resolution and direct spoke-to-spoke encapsulation after the change. NHRP direct forwarding does not imply IPsec protection unless the relevant tunnel-protection design covers it.
Question 380 A DMVPN tunnel encrypts traffic to the hub but new direct spoke traffic passes without the required encryption profile after a template update. Which lasting design or operational safeguard best prevents this particular issue from recurring? Align routing next-hop policy with the deployed DMVPN phase and topology. Standardize tunnel type for the approved DMVPN phase and shortcut behavior. Include hub interface routing policies in DMVPN baseline validation. Enforce uniform overlay encryption policy and automated tunnel-profile compliance checks. ExplanationCorrect Answer D:Enforce uniform overlay encryption policy and automated tunnel-profile compliance checks. This addresses the recurring cause: NHRP direct forwarding does not imply IPsec protection unless the relevant tunnel-protection design covers it. A targeted acceptance check is: Capture SA counters for both hub-spoke and direct spoke-spoke flows under the policy. Other Answers A:Align routing next-hop policy with the deployed DMVPN phase and topology. NHRP direct forwarding does not imply IPsec protection unless the relevant tunnel-protection design covers it. B:Standardize tunnel type for the approved DMVPN phase and shortcut behavior. NHRP direct forwarding does not imply IPsec protection unless the relevant tunnel-protection design covers it. C:Include hub interface routing policies in DMVPN baseline validation. NHRP direct forwarding does not imply IPsec protection unless the relevant tunnel-protection design covers it.
