Question 170 An OSPF route unexpectedly favors an intra-area path over a lower-cost external path to the same prefix. 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 intra-area routes are preferred over interarea and external routes for the same prefix by OSPF path-type hierarchy. BGP weight influences local BGP path choice, not which OSPF default LSA an area accepts from an ABR. OSPF interarea routing relies on a connected backbone design; virtual links can restore logical backbone continuity in supported cases. ExplanationCorrect Answer B:OSPF intra-area routes are preferred over interarea and external routes for the same prefix by OSPF path-type hierarchy. This explains why the initial condition produces the observed failure. The direct repair is: Verify OSPF route-type preference before changing interface costs. Validate through: Compare route types and selected path with correct test prefixes after remediation. Other Answers A:OSPF SPF cost, including manually set interface cost, determines equal-cost installation within the same route type. OSPF intra-area routes are preferred over interarea and external routes for the same prefix by OSPF path-type hierarchy. C:BGP weight influences local BGP path choice, not which OSPF default LSA an area accepts from an ABR. OSPF intra-area routes are preferred over interarea and external routes for the same prefix by OSPF path-type hierarchy. D:OSPF interarea routing relies on a connected backbone design; virtual links can restore logical backbone continuity in supported cases. OSPF intra-area routes are preferred over interarea and external routes for the same prefix by OSPF path-type hierarchy.
Question 171 An OSPF route unexpectedly favors an intra-area path over a lower-cost external path to the same prefix. 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. Check the area's LSDB and confirm expected default and no unwanted detailed interarea routes. Compare route types and selected path with correct test prefixes after remediation. Verify backbone adjacency and restored interarea prefixes on the separated ABR. ExplanationCorrect Answer C:Compare route types and selected path with correct test prefixes after remediation. This checks the affected traffic or control-plane behavior, not merely a generic up/down indicator. The underlying mechanism is: OSPF intra-area routes are preferred over interarea and external routes for the same prefix by OSPF path-type hierarchy. Other Answers A:Trace the default route's OSPF source/type and validate the intended origination point. OSPF intra-area routes are preferred over interarea and external routes for the same prefix by OSPF path-type hierarchy. B:Check the area's LSDB and confirm expected default and no unwanted detailed interarea routes. OSPF intra-area routes are preferred over interarea and external routes for the same prefix by OSPF path-type hierarchy. D:Verify backbone adjacency and restored interarea prefixes on the separated ABR. OSPF intra-area routes are preferred over interarea and external routes for the same prefix by OSPF path-type hierarchy.
Question 172 An OSPF route unexpectedly favors an intra-area path over a lower-cost external path to the same prefix. Which lasting design or operational safeguard best prevents this particular issue from recurring? Perform separate OSPFv3 interface and AF coverage checks in dual-stack upgrades. Assign unique stable router IDs in the deployment inventory. Include bidirectional hello and multicast delivery tests in OSPF interface acceptance. Teach path-type hierarchy alongside cost tuning in OSPF policy review. ExplanationCorrect Answer D:Teach path-type hierarchy alongside cost tuning in OSPF policy review. This addresses the recurring cause: OSPF intra-area routes are preferred over interarea and external routes for the same prefix by OSPF path-type hierarchy. A targeted acceptance check is: Compare route types and selected path with correct test prefixes after remediation. Other Answers A:Perform separate OSPFv3 interface and AF coverage checks in dual-stack upgrades. OSPF intra-area routes are preferred over interarea and external routes for the same prefix by OSPF path-type hierarchy. B:Assign unique stable router IDs in the deployment inventory. OSPF intra-area routes are preferred over interarea and external routes for the same prefix by OSPF path-type hierarchy. C:Include bidirectional hello and multicast delivery tests in OSPF interface acceptance. OSPF intra-area routes are preferred over interarea and external routes for the same prefix by OSPF path-type hierarchy.
Question 173 A multiaccess OSPF router changes its Router ID after a reload and peers retain stale adjacency assumptions during troubleshooting. Which corrective action most directly resolves the documented failure without suppressing unrelated safeguards? Set a stable unique router ID and plan an OSPF process restart where necessary for it to take effect. Verify OSPF route-type preference before changing interface costs. Correct the interface or path MTU mismatch rather than using mtu-ignore as the default workaround. Enable the appropriate OSPFv3 IPv6 address-family/interface participation on that interface. ExplanationCorrect Answer A:Set a stable unique router ID and plan an OSPF process restart where necessary for it to take effect. OSPF identifies routers by 32-bit router IDs; duplicate or unexpected IDs disrupt LSDB and adjacency assumptions. Confirm unique IDs and clean neighbor/LSDB convergence following an approved restart. Other Answers B:Verify OSPF route-type preference before changing interface costs. OSPF identifies routers by 32-bit router IDs; duplicate or unexpected IDs disrupt LSDB and adjacency assumptions. C:Correct the interface or path MTU mismatch rather than using mtu-ignore as the default workaround. OSPF identifies routers by 32-bit router IDs; duplicate or unexpected IDs disrupt LSDB and adjacency assumptions. D:Enable the appropriate OSPFv3 IPv6 address-family/interface participation on that interface. OSPF identifies routers by 32-bit router IDs; duplicate or unexpected IDs disrupt LSDB and adjacency assumptions.
Question 174 A multiaccess OSPF router changes its Router ID after a reload and peers retain stale adjacency assumptions during troubleshooting. Which technical mechanism best explains the behavior observed in this scenario? A totally stubby area suppresses ordinary interarea summary LSAs beyond the default-route behavior. OSPF identifies routers by 32-bit router IDs; duplicate or unexpected IDs disrupt LSDB and adjacency assumptions. BGP weight influences local BGP path choice, not which OSPF default LSA an area accepts from an ABR. OSPF intra-area routes are preferred over interarea and external routes for the same prefix by OSPF path-type hierarchy. ExplanationCorrect Answer B:OSPF identifies routers by 32-bit router IDs; duplicate or unexpected IDs disrupt LSDB and adjacency assumptions. This explains why the initial condition produces the observed failure. The direct repair is: Set a stable unique router ID and plan an OSPF process restart where necessary for it to take effect. Validate through: Confirm unique IDs and clean neighbor/LSDB convergence following an approved restart. Other Answers A:A totally stubby area suppresses ordinary interarea summary LSAs beyond the default-route behavior. OSPF identifies routers by 32-bit router IDs; duplicate or unexpected IDs disrupt LSDB and adjacency assumptions. C: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. D:OSPF intra-area routes are preferred over interarea and external routes for the same prefix by OSPF path-type hierarchy. OSPF identifies routers by 32-bit router IDs; duplicate or unexpected IDs disrupt LSDB and adjacency assumptions.
Question 175 A multiaccess OSPF router changes its Router ID after a reload and peers retain stale adjacency assumptions during troubleshooting. 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. Compare interface MTUs and observe EXSTART progressing through EXCHANGE to FULL after alignment. Confirm unique IDs and clean neighbor/LSDB convergence following an approved restart. Verify backbone adjacency and restored interarea prefixes on the separated ABR. ExplanationCorrect Answer C:Confirm unique IDs and clean neighbor/LSDB convergence following an approved restart. This checks the affected traffic or control-plane behavior, not merely a generic up/down indicator. The underlying mechanism is: OSPF identifies routers by 32-bit router IDs; duplicate or unexpected IDs disrupt LSDB and adjacency assumptions. Other Answers A:Trace the default route's OSPF source/type and validate the intended origination point. OSPF identifies routers by 32-bit router IDs; duplicate or unexpected IDs disrupt LSDB and adjacency assumptions. B:Compare interface MTUs and observe EXSTART progressing through EXCHANGE to FULL after alignment. OSPF identifies routers by 32-bit router IDs; duplicate or unexpected IDs disrupt LSDB and adjacency assumptions. D:Verify backbone adjacency and restored interarea prefixes on the separated ABR. OSPF identifies routers by 32-bit router IDs; duplicate or unexpected IDs disrupt LSDB and adjacency assumptions.
Question 176 A multiaccess OSPF router changes its Router ID after a reload and peers retain stale adjacency assumptions during troubleshooting. Which lasting design or operational safeguard best prevents this particular issue from recurring? Keep ABR area-type policy consistent under redundancy changes. Deploy per-link OSPF timer templates as a paired change. Teach path-type hierarchy alongside cost tuning in OSPF policy review. Assign unique stable router IDs in the deployment inventory. ExplanationCorrect Answer D:Assign unique stable router IDs in the deployment inventory. This addresses the recurring cause: OSPF identifies routers by 32-bit router IDs; duplicate or unexpected IDs disrupt LSDB and adjacency assumptions. A targeted acceptance check is: Confirm unique IDs and clean neighbor/LSDB convergence following an approved restart. Other Answers A:Keep ABR area-type policy consistent under redundancy changes. OSPF identifies routers by 32-bit router IDs; duplicate or unexpected IDs disrupt LSDB and adjacency assumptions. B:Deploy per-link OSPF timer templates as a paired change. OSPF identifies routers by 32-bit router IDs; duplicate or unexpected IDs disrupt LSDB and adjacency assumptions. C:Teach path-type hierarchy alongside cost tuning in OSPF policy review. OSPF identifies routers by 32-bit router IDs; duplicate or unexpected IDs disrupt LSDB and adjacency assumptions.
Question 177 OSPFv3 IPv6 routes stop updating across a link that is administratively up because the IPv6 interface is missing the proper OSPFv3 instance attachment. Which corrective action most directly resolves the documented failure without suppressing unrelated safeguards? Enable the appropriate OSPFv3 IPv6 address-family/interface participation on that interface. Make both sides' area-type settings consistent with the approved stub-area design. Confirm the DR/BDR election and leave valid DROTHER-to-DROTHER 2-WAY relationships intact. Set a stable unique router ID and plan an OSPF process restart where necessary for it to take effect. ExplanationCorrect Answer A:Enable the appropriate OSPFv3 IPv6 address-family/interface participation on that interface. OSPFv3 adjacencies and route exchange follow their configured interface instances and address families rather than IPv4 process network statements. Verify OSPFv3 neighbors and the expected IPv6 prefix in the routing table. Other Answers B:Make both sides' area-type settings consistent with the approved stub-area design. OSPFv3 adjacencies and route exchange follow their configured interface instances and address families rather than IPv4 process network statements. C:Confirm the DR/BDR election and leave valid DROTHER-to-DROTHER 2-WAY relationships intact. OSPFv3 adjacencies and route exchange follow their configured interface instances and address families rather than IPv4 process network statements. D:Set a stable unique router ID and plan an OSPF process restart where necessary for it to take effect. OSPFv3 adjacencies and route exchange follow their configured interface instances and address families rather than IPv4 process network statements.
Question 178 OSPFv3 IPv6 routes stop updating across a link that is administratively up because the IPv6 interface is missing the proper OSPFv3 instance attachment. 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. OSPFv3 adjacencies and route exchange follow their configured interface instances and address families rather than IPv4 process network statements. OSPF database-description packet MTU checks can block database exchange when one peer cannot accept the advertised size. A totally stubby area suppresses ordinary interarea summary LSAs beyond the default-route behavior. ExplanationCorrect Answer B:OSPFv3 adjacencies and route exchange follow their configured interface instances and address families rather than IPv4 process network statements. This explains why the initial condition produces the observed failure. The direct repair is: Enable the appropriate OSPFv3 IPv6 address-family/interface participation on that interface. Validate through: Verify OSPFv3 neighbors and the expected IPv6 prefix in the routing table. Other Answers A:BGP weight influences local BGP path choice, not which OSPF default LSA an area accepts from an ABR. OSPFv3 adjacencies and route exchange follow their configured interface instances and address families rather than IPv4 process network statements. C:OSPF database-description packet MTU checks can block database exchange when one peer cannot accept the advertised size. OSPFv3 adjacencies and route exchange follow their configured interface instances and address families rather than IPv4 process network statements. D:A totally stubby area suppresses ordinary interarea summary LSAs beyond the default-route behavior. OSPFv3 adjacencies and route exchange follow their configured interface instances and address families rather than IPv4 process network statements.
Question 179 OSPFv3 IPv6 routes stop updating across a link that is administratively up because the IPv6 interface is missing the proper OSPFv3 instance attachment. After applying the correction, which verification evidence most directly demonstrates that this issue is resolved? Confirm both router IDs appear in received hellos and the adjacency progresses to FULL. Confirm unique IDs and clean neighbor/LSDB convergence following an approved restart. Verify OSPFv3 neighbors and the expected IPv6 prefix in the routing table. Inspect both interface timer values and confirm a stable FULL neighbor state after correction. ExplanationCorrect Answer C:Verify OSPFv3 neighbors and the expected IPv6 prefix in the routing table. This checks the affected traffic or control-plane behavior, not merely a generic up/down indicator. The underlying mechanism is: OSPFv3 adjacencies and route exchange follow their configured interface instances and address families rather than IPv4 process network statements. Other Answers A:Confirm both router IDs appear in received hellos and the adjacency progresses to FULL. OSPFv3 adjacencies and route exchange follow their configured interface instances and address families rather than IPv4 process network statements. B:Confirm unique IDs and clean neighbor/LSDB convergence following an approved restart. OSPFv3 adjacencies and route exchange follow their configured interface instances and address families rather than IPv4 process network statements. D:Inspect both interface timer values and confirm a stable FULL neighbor state after correction. OSPFv3 adjacencies and route exchange follow their configured interface instances and address families rather than IPv4 process network statements.
Question 180 OSPFv3 IPv6 routes stop updating across a link that is administratively up because the IPv6 interface is missing the proper OSPFv3 instance attachment. Which lasting design or operational safeguard best prevents this particular issue from recurring? Keep ABR area-type policy consistent under redundancy changes. Teach path-type hierarchy alongside cost tuning in OSPF policy review. Design durable Area 0 continuity rather than relying permanently on virtual-link workarounds. Perform separate OSPFv3 interface and AF coverage checks in dual-stack upgrades. ExplanationCorrect Answer D:Perform separate OSPFv3 interface and AF coverage checks in dual-stack upgrades. This addresses the recurring cause: OSPFv3 adjacencies and route exchange follow their configured interface instances and address families rather than IPv4 process network statements. A targeted acceptance check is: Verify OSPFv3 neighbors and the expected IPv6 prefix in the routing table. Other Answers A:Keep ABR area-type policy consistent under redundancy changes. OSPFv3 adjacencies and route exchange follow their configured interface instances and address families rather than IPv4 process network statements. B:Teach path-type hierarchy alongside cost tuning in OSPF policy review. OSPFv3 adjacencies and route exchange follow their configured interface instances and address families rather than IPv4 process network statements. C:Design durable Area 0 continuity rather than relying permanently on virtual-link workarounds. OSPFv3 adjacencies and route exchange follow their configured interface instances and address families rather than IPv4 process network statements.
