Question 130 An EIGRP interface shows neighbors, but remote IPv6 routes are missing because the network is in a separate VRF while IPv6 AF is attached globally. Which technical mechanism best explains the behavior observed in this scenario? DUAL waits for replies before completing an active diffusing computation; missing replies can trigger SIA handling. EIGRP VRF address families maintain separated route exchanges and forwarding contexts from the global table. Authentication failure causes otherwise correctly addressed EIGRP hello packets to be rejected rather than forming a neighbor. Named EIGRP uses address-family and AF-interface configuration scopes; global IPv4 activation does not imply IPv6 neighborship. ExplanationCorrect Answer B:EIGRP VRF address families maintain separated route exchanges and forwarding contexts from the global table. This explains why the initial condition produces the observed failure. The direct repair is: Bind the intended EIGRP IPv6 address family to the correct VRF context and verify interface membership. Validate through: Display expected IPv6 routes in the tenant VRF and none leaked into the global table. Other Answers A:DUAL waits for replies before completing an active diffusing computation; missing replies can trigger SIA handling. EIGRP VRF address families maintain separated route exchanges and forwarding contexts from the global table. C:Authentication failure causes otherwise correctly addressed EIGRP hello packets to be rejected rather than forming a neighbor. EIGRP VRF address families maintain separated route exchanges and forwarding contexts from the global table. D:Named EIGRP uses address-family and AF-interface configuration scopes; global IPv4 activation does not imply IPv6 neighborship. EIGRP VRF address families maintain separated route exchanges and forwarding contexts from the global table.
Question 131 An EIGRP interface shows neighbors, but remote IPv6 routes are missing because the network is in a separate VRF while IPv6 AF is attached globally. After applying the correction, which verification evidence most directly demonstrates that this issue is resolved? Inspect both installed EIGRP next hops and controlled flow distribution after changing supported settings. Inspect the topology table and show the alternative is not labeled feasible despite its reachable-looking metric. Display expected IPv6 routes in the tenant VRF and none leaked into the global table. Restore a stable uplink neighbor and verify the summarized branch route is received. ExplanationCorrect Answer C:Display expected IPv6 routes in the tenant VRF and none leaked into the global table. This checks the affected traffic or control-plane behavior, not merely a generic up/down indicator. The underlying mechanism is: EIGRP VRF address families maintain separated route exchanges and forwarding contexts from the global table. Other Answers A:Inspect both installed EIGRP next hops and controlled flow distribution after changing supported settings. EIGRP VRF address families maintain separated route exchanges and forwarding contexts from the global table. B:Inspect the topology table and show the alternative is not labeled feasible despite its reachable-looking metric. EIGRP VRF address families maintain separated route exchanges and forwarding contexts from the global table. D:Restore a stable uplink neighbor and verify the summarized branch route is received. EIGRP VRF address families maintain separated route exchanges and forwarding contexts from the global table.
Question 132 An EIGRP interface shows neighbors, but remote IPv6 routes are missing because the network is in a separate VRF while IPv6 AF is attached globally. Which lasting design or operational safeguard best prevents this particular issue from recurring? Validate routing process and address-family identity in the circuit turn-up checklist. Test IPv4 and IPv6 address families independently during named-mode migration. Review summary and distribution policies jointly when adding backup path capacity. Match all EIGRP AFs and VRF bindings to documented tenant routing boundaries. ExplanationCorrect Answer D:Match all EIGRP AFs and VRF bindings to documented tenant routing boundaries. This addresses the recurring cause: EIGRP VRF address families maintain separated route exchanges and forwarding contexts from the global table. A targeted acceptance check is: Display expected IPv6 routes in the tenant VRF and none leaked into the global table. Other Answers A:Validate routing process and address-family identity in the circuit turn-up checklist. EIGRP VRF address families maintain separated route exchanges and forwarding contexts from the global table. B:Test IPv4 and IPv6 address families independently during named-mode migration. EIGRP VRF address families maintain separated route exchanges and forwarding contexts from the global table. C:Review summary and distribution policies jointly when adding backup path capacity. EIGRP VRF address families maintain separated route exchanges and forwarding contexts from the global table.
Question 133 Two OSPF routers remain in INIT because one side's hello lists no neighbor router ID despite unidirectional reachability. Which corrective action most directly resolves the documented failure without suppressing unrelated safeguards? Find and correct one-way hello receipt, multicast filtering or layer-two delivery on the affected segment. Verify default-route reachability instead of expecting Type-5 external LSAs inside the stub area. Use a network type and neighbor design appropriate for the nonbroadcast multipoint topology. Confirm the DR/BDR election and leave valid DROTHER-to-DROTHER 2-WAY relationships intact. ExplanationCorrect Answer A:Find and correct one-way hello receipt, multicast filtering or layer-two delivery on the affected segment. OSPF INIT means hellos are received but two-way recognition is not yet confirmed in the neighbor lists. Confirm both router IDs appear in received hellos and the adjacency progresses to FULL. Other Answers B:Verify default-route reachability instead of expecting Type-5 external LSAs inside the stub area. OSPF INIT means hellos are received but two-way recognition is not yet confirmed in the neighbor lists. C:Use a network type and neighbor design appropriate for the nonbroadcast multipoint topology. OSPF INIT means hellos are received but two-way recognition is not yet confirmed in the neighbor lists. D:Confirm the DR/BDR election and leave valid DROTHER-to-DROTHER 2-WAY relationships intact. OSPF INIT means hellos are received but two-way recognition is not yet confirmed in the neighbor lists.
Question 134 Two OSPF routers remain in INIT because one side's hello lists no neighbor router ID despite unidirectional reachability. Which technical mechanism best explains the behavior observed in this scenario? BGP weight influences local BGP path choice, not which OSPF default LSA an area accepts from an ABR. OSPF INIT means hellos are received but two-way recognition is not yet confirmed in the neighbor lists. OSPFv3 adjacencies and route exchange follow their configured interface instances and address families rather than IPv4 process network statements. A stub area's design suppresses Type-5 external advertisements while its ABR can provide a default route. ExplanationCorrect Answer B:OSPF INIT means hellos are received but two-way recognition is not yet confirmed in the neighbor lists. This explains why the initial condition produces the observed failure. The direct repair is: Find and correct one-way hello receipt, multicast filtering or layer-two delivery on the affected segment. Validate through: Confirm both router IDs appear in received hellos and the adjacency progresses to FULL. Other Answers A:BGP weight influences local BGP path choice, not which OSPF default LSA an area accepts from an ABR. OSPF INIT means hellos are received but two-way recognition is not yet confirmed in the neighbor lists. C:OSPFv3 adjacencies and route exchange follow their configured interface instances and address families rather than IPv4 process network statements. OSPF INIT means hellos are received but two-way recognition is not yet confirmed in the neighbor lists. D:A stub area's design suppresses Type-5 external advertisements while its ABR can provide a default route. OSPF INIT means hellos are received but two-way recognition is not yet confirmed in the neighbor lists.
Question 135 Two OSPF routers remain in INIT because one side's hello lists no neighbor router ID despite unidirectional reachability. After applying the correction, which verification evidence most directly demonstrates that this issue is resolved? Inspect OSPF route costs and multiple installed next hops after correction. Verify the area flags and a FULL neighbor state after correction. Confirm both router IDs appear in received hellos and the adjacency progresses to FULL. Observe Type-7 inside the NSSA and matching Type-5 outside after correction. ExplanationCorrect Answer C:Confirm both router IDs appear in received hellos and the adjacency progresses to FULL. This checks the affected traffic or control-plane behavior, not merely a generic up/down indicator. The underlying mechanism is: OSPF INIT means hellos are received but two-way recognition is not yet confirmed in the neighbor lists. Other Answers A:Inspect OSPF route costs and multiple installed next hops after correction. OSPF INIT means hellos are received but two-way recognition is not yet confirmed in the neighbor lists. B:Verify the area flags and a FULL neighbor state after correction. OSPF INIT means hellos are received but two-way recognition is not yet confirmed in the neighbor lists. D:Observe Type-7 inside the NSSA and matching Type-5 outside after correction. OSPF INIT means hellos are received but two-way recognition is not yet confirmed in the neighbor lists.
Question 136 Two OSPF routers remain in INIT because one side's hello lists no neighbor router ID despite unidirectional reachability. Which lasting design or operational safeguard best prevents this particular issue from recurring? Define NSSA translator responsibilities and validate them in failover tests. Validate consistent stub/NSSA/normal area settings for all routers in an area. Educate monitoring rules on expected OSPF states for each network type. Include bidirectional hello and multicast delivery tests in OSPF interface acceptance. ExplanationCorrect Answer D:Include bidirectional hello and multicast delivery tests in OSPF interface acceptance. This addresses the recurring cause: OSPF INIT means hellos are received but two-way recognition is not yet confirmed in the neighbor lists. A targeted acceptance check is: Confirm both router IDs appear in received hellos and the adjacency progresses to FULL. Other Answers A:Define NSSA translator responsibilities and validate them in failover tests. OSPF INIT means hellos are received but two-way recognition is not yet confirmed in the neighbor lists. B:Validate consistent stub/NSSA/normal area settings for all routers in an area. OSPF INIT means hellos are received but two-way recognition is not yet confirmed in the neighbor lists. C:Educate monitoring rules on expected OSPF states for each network type. OSPF INIT means hellos are received but two-way recognition is not yet confirmed in the neighbor lists.
Question 137 An OSPF adjacency stalls in EXSTART after a path change; one device advertises a larger interface MTU in DBD packets. Which corrective action most directly resolves the documented failure without suppressing unrelated safeguards? Correct the interface or path MTU mismatch rather than using mtu-ignore as the default workaround. Restore the correct no-summary behavior on all relevant ABRs while preserving an appropriate default route. Set compatible hello and dead timers on both ends of the same OSPF adjacency. Make both sides' area-type settings consistent with the approved stub-area design. ExplanationCorrect Answer A:Correct the interface or path MTU mismatch rather than using mtu-ignore as the default workaround. OSPF database-description packet MTU checks can block database exchange when one peer cannot accept the advertised size. Compare interface MTUs and observe EXSTART progressing through EXCHANGE to FULL after alignment. Other Answers B:Restore the correct no-summary behavior on all relevant ABRs while preserving an appropriate default route. OSPF database-description packet MTU checks can block database exchange when one peer cannot accept the advertised size. C:Set compatible hello and dead timers on both ends of the same OSPF adjacency. OSPF database-description packet MTU checks can block database exchange when one peer cannot accept the advertised size. D:Make both sides' area-type settings consistent with the approved stub-area design. OSPF database-description packet MTU checks can block database exchange when one peer cannot accept the advertised size.
Question 138 An OSPF adjacency stalls in EXSTART after a path change; one device advertises a larger interface MTU in DBD packets. Which technical mechanism best explains the behavior observed in this scenario? OSPF SPF cost, including manually set interface cost, determines equal-cost installation within the same route type. OSPF database-description packet MTU checks can block database exchange when one peer cannot accept the advertised size. BGP weight influences local BGP path choice, not which OSPF default LSA an area accepts from an ABR. OSPF identifies routers by 32-bit router IDs; duplicate or unexpected IDs disrupt LSDB and adjacency assumptions. ExplanationCorrect Answer B:OSPF database-description packet MTU checks can block database exchange when one peer cannot accept the advertised size. This explains why the initial condition produces the observed failure. The direct repair is: Correct the interface or path MTU mismatch rather than using mtu-ignore as the default workaround. Validate through: Compare interface MTUs and observe EXSTART progressing through EXCHANGE to FULL after alignment. Other Answers A:OSPF SPF cost, including manually set interface cost, determines equal-cost installation within the same route type. OSPF database-description packet MTU checks can block database exchange when one peer cannot accept the advertised size. C:BGP weight influences local BGP path choice, not which OSPF default LSA an area accepts from an ABR. OSPF database-description packet MTU checks can block database exchange when one peer cannot accept the advertised size. D:OSPF identifies routers by 32-bit router IDs; duplicate or unexpected IDs disrupt LSDB and adjacency assumptions. OSPF database-description packet MTU checks can block database exchange when one peer cannot accept the advertised size.
Question 139 An OSPF adjacency stalls in EXSTART after a path change; one device advertises a larger interface MTU in DBD packets. After applying the correction, which verification evidence most directly demonstrates that this issue is resolved? Trace the default route's OSPF source/type and validate the intended origination point. Inspect OSPF route costs and multiple installed next hops after correction. Compare interface MTUs and observe EXSTART progressing through EXCHANGE to FULL after alignment. Verify backbone adjacency and restored interarea prefixes on the separated ABR. ExplanationCorrect Answer C:Compare interface MTUs and observe EXSTART progressing through EXCHANGE to FULL after alignment. This checks the affected traffic or control-plane behavior, not merely a generic up/down indicator. The underlying mechanism is: OSPF database-description packet MTU checks can block database exchange when one peer cannot accept the advertised size. Other Answers A:Trace the default route's OSPF source/type and validate the intended origination point. OSPF database-description packet MTU checks can block database exchange when one peer cannot accept the advertised size. B:Inspect OSPF route costs and multiple installed next hops after correction. OSPF database-description packet MTU checks can block database exchange when one peer cannot accept the advertised size. D:Verify backbone adjacency and restored interarea prefixes on the separated ABR. OSPF database-description packet MTU checks can block database exchange when one peer cannot accept the advertised size.
Question 140 An OSPF adjacency stalls in EXSTART after a path change; one device advertises a larger interface MTU in DBD packets. Which lasting design or operational safeguard best prevents this particular issue from recurring? Validate consistent stub/NSSA/normal area settings for all routers in an area. Specify OSPF network type and DR eligibility explicitly for hub-spoke media. Define NSSA translator responsibilities and validate them in failover tests. Add OSPF MTU consistency checks to routed-circuit change validation. ExplanationCorrect Answer D:Add OSPF MTU consistency checks to routed-circuit change validation. This addresses the recurring cause: OSPF database-description packet MTU checks can block database exchange when one peer cannot accept the advertised size. A targeted acceptance check is: Compare interface MTUs and observe EXSTART progressing through EXCHANGE to FULL after alignment. Other Answers A:Validate consistent stub/NSSA/normal area settings for all routers in an area. OSPF database-description packet MTU checks can block database exchange when one peer cannot accept the advertised size. B:Specify OSPF network type and DR eligibility explicitly for hub-spoke media. OSPF database-description packet MTU checks can block database exchange when one peer cannot accept the advertised size. C:Define NSSA translator responsibilities and validate them in failover tests. OSPF database-description packet MTU checks can block database exchange when one peer cannot accept the advertised size.
