Question 190 A BGP ASBR redistributes a default route into OSPF, but a remote area sees the default through an ABR instead and the operator tries to raise BGP weight. 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. 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 interarea routing relies on a connected backbone design; virtual links can restore logical backbone continuity in supported cases. ExplanationCorrect Answer B:BGP weight influences local BGP path choice, not which OSPF default LSA an area accepts from an ABR. This explains why the initial condition produces the observed failure. The direct repair is: Identify the OSPF external/default origination and area behavior before altering an unrelated BGP attribute. Validate through: Trace the default route's OSPF source/type and validate the intended origination point. Other Answers A:OSPF SPF cost, including manually set interface cost, determines equal-cost installation within the same route type. BGP weight influences local BGP path choice, not which OSPF default LSA an area accepts from an ABR. C:OSPFv3 adjacencies and route exchange follow their configured interface instances and address families rather than IPv4 process network statements. BGP weight influences local BGP path choice, not which OSPF default LSA an area accepts from an ABR. D:OSPF interarea routing relies on a connected backbone design; virtual links can restore logical backbone continuity in supported cases. BGP weight influences local BGP path choice, not which OSPF default LSA an area accepts from an ABR.
Question 191 A BGP ASBR redistributes a default route into OSPF, but a remote area sees the default through an ABR instead and the operator tries to raise BGP weight. After applying the correction, which verification evidence most directly demonstrates that this issue is resolved? Confirm unique IDs and clean neighbor/LSDB convergence following an approved restart. Check the stub router's default route and successful forwarding to an external test prefix. Trace the default route's OSPF source/type and validate the intended origination point. Verify backbone adjacency and restored interarea prefixes on the separated ABR. ExplanationCorrect Answer C:Trace the default route's OSPF source/type and validate the intended origination point. This checks the affected traffic or control-plane behavior, not merely a generic up/down indicator. The underlying mechanism is: BGP weight influences local BGP path choice, not which OSPF default LSA an area accepts from an ABR. Other Answers A:Confirm unique IDs and clean neighbor/LSDB convergence following an approved restart. BGP weight influences local BGP path choice, not which OSPF default LSA an area accepts from an ABR. B:Check the stub router's default route and successful forwarding to an external test prefix. BGP weight influences local BGP path choice, not which OSPF default LSA an area accepts from an ABR. D:Verify backbone adjacency and restored interarea prefixes on the separated ABR. BGP weight influences local BGP path choice, not which OSPF default LSA an area accepts from an ABR.
Question 192 A BGP ASBR redistributes a default route into OSPF, but a remote area sees the default through an ABR instead and the operator tries to raise BGP weight. Which lasting design or operational safeguard best prevents this particular issue from recurring? Add OSPF MTU consistency checks to routed-circuit change validation. Deploy per-link OSPF timer templates as a paired change. Assign unique stable router IDs in the deployment inventory. Keep default-route policy separated by routing protocol and area role. ExplanationCorrect Answer D:Keep default-route policy separated by routing protocol and area role. This addresses the recurring cause: BGP weight influences local BGP path choice, not which OSPF default LSA an area accepts from an ABR. A targeted acceptance check is: Trace the default route's OSPF source/type and validate the intended origination point. Other Answers A:Add OSPF MTU consistency checks to routed-circuit change validation. BGP weight influences local BGP path choice, not which OSPF default LSA an area accepts from an ABR. B:Deploy per-link OSPF timer templates as a paired change. BGP weight influences local BGP path choice, not which OSPF default LSA an area accepts from an ABR. C:Assign unique stable router IDs in the deployment inventory. BGP weight influences local BGP path choice, not which OSPF default LSA an area accepts from an ABR.
Question 193 A new iBGP neighbor forms Established and receives prefixes, but none is usable because their external next hop is unreachable in the internal IGP. Which corrective action most directly resolves the documented failure without suppressing unrelated safeguards? Configure appropriate `next-hop-self` policy on the advertising boundary or distribute valid next-hop reachability. Do not force a MED comparison across different neighboring ASes without an explicit, supported design decision. Correct the overriding policy before assuming AS-path length will select the path. Validate route-reflector client configuration and outbound policy for the missing prefix. ExplanationCorrect Answer A:Configure appropriate `next-hop-self` policy on the advertising boundary or distribute valid next-hop reachability. BGP next-hop resolution is a prerequisite for installing an otherwise valid received path into the RIB. Inspect next-hop reachability and confirm a formerly inaccessible BGP prefix becomes valid and installed. Other Answers B:Do not force a MED comparison across different neighboring ASes without an explicit, supported design decision. BGP next-hop resolution is a prerequisite for installing an otherwise valid received path into the RIB. C:Correct the overriding policy before assuming AS-path length will select the path. BGP next-hop resolution is a prerequisite for installing an otherwise valid received path into the RIB. D:Validate route-reflector client configuration and outbound policy for the missing prefix. BGP next-hop resolution is a prerequisite for installing an otherwise valid received path into the RIB.
Question 194 A new iBGP neighbor forms Established and receives prefixes, but none is usable because their external next hop is unreachable in the internal IGP. Which technical mechanism best explains the behavior observed in this scenario? BGP evaluates local preference before AS-path length when other earlier conditions are equal. BGP next-hop resolution is a prerequisite for installing an otherwise valid received path into the RIB. BGP's AS-path loop-prevention check rejects routes that include the receiving router's own AS by default. Multihop eBGP peering over loopbacks requires packet reachability and TTL/configuration beyond a directly connected peer assumption. ExplanationCorrect Answer B:BGP next-hop resolution is a prerequisite for installing an otherwise valid received path into the RIB. This explains why the initial condition produces the observed failure. The direct repair is: Configure appropriate `next-hop-self` policy on the advertising boundary or distribute valid next-hop reachability. Validate through: Inspect next-hop reachability and confirm a formerly inaccessible BGP prefix becomes valid and installed. Other Answers A:BGP evaluates local preference before AS-path length when other earlier conditions are equal. BGP next-hop resolution is a prerequisite for installing an otherwise valid received path into the RIB. C:BGP's AS-path loop-prevention check rejects routes that include the receiving router's own AS by default. BGP next-hop resolution is a prerequisite for installing an otherwise valid received path into the RIB. D:Multihop eBGP peering over loopbacks requires packet reachability and TTL/configuration beyond a directly connected peer assumption. BGP next-hop resolution is a prerequisite for installing an otherwise valid received path into the RIB.
Question 195 A new iBGP neighbor forms Established and receives prefixes, but none is usable because their external next hop is unreachable in the internal IGP. After applying the correction, which verification evidence most directly demonstrates that this issue is resolved? Check BGP advertised-routes toward the missing client and the corresponding route-reflector state. Inspect neighboring AS values and compare the selected path under the approved MED policy. Inspect next-hop reachability and confirm a formerly inaccessible BGP prefix becomes valid and installed. Compare outbound advertised AS paths and observed remote selection where visibility exists. ExplanationCorrect Answer C:Inspect next-hop reachability and confirm a formerly inaccessible BGP prefix becomes valid and installed. This checks the affected traffic or control-plane behavior, not merely a generic up/down indicator. The underlying mechanism is: BGP next-hop resolution is a prerequisite for installing an otherwise valid received path into the RIB. Other Answers A:Check BGP advertised-routes toward the missing client and the corresponding route-reflector state. BGP next-hop resolution is a prerequisite for installing an otherwise valid received path into the RIB. B:Inspect neighboring AS values and compare the selected path under the approved MED policy. BGP next-hop resolution is a prerequisite for installing an otherwise valid received path into the RIB. D:Compare outbound advertised AS paths and observed remote selection where visibility exists. BGP next-hop resolution is a prerequisite for installing an otherwise valid received path into the RIB.
Question 196 A new iBGP neighbor forms Established and receives prefixes, but none is usable because their external next hop is unreachable in the internal IGP. Which lasting design or operational safeguard best prevents this particular issue from recurring? Maintain explicit route-reflector topology and client inventory. Include underlay reachability, TTL and update-source in loopback-peering templates. Standardize stable loopback-sourced peering and test during failover. Include end-to-end BGP next-hop reachability tests during iBGP rollouts. ExplanationCorrect Answer D:Include end-to-end BGP next-hop reachability tests during iBGP rollouts. This addresses the recurring cause: BGP next-hop resolution is a prerequisite for installing an otherwise valid received path into the RIB. A targeted acceptance check is: Inspect next-hop reachability and confirm a formerly inaccessible BGP prefix becomes valid and installed. Other Answers A:Maintain explicit route-reflector topology and client inventory. BGP next-hop resolution is a prerequisite for installing an otherwise valid received path into the RIB. B:Include underlay reachability, TTL and update-source in loopback-peering templates. BGP next-hop resolution is a prerequisite for installing an otherwise valid received path into the RIB. C:Standardize stable loopback-sourced peering and test during failover. BGP next-hop resolution is a prerequisite for installing an otherwise valid received path into the RIB.
Question 197 Two eBGP exit routers learn the same prefix with different local preferences; traffic exits through the backup despite a shorter AS path on the primary. Which corrective action most directly resolves the documented failure without suppressing unrelated safeguards? Set the intended local preference consistently for the preferred egress route. Configure appropriate `next-hop-self` policy on the advertising boundary or distribute valid next-hop reachability. Validate AS-path prepending from external peers and treat it as a remote-inbound influence rather than a guaranteed local choice. Validate route-reflector client configuration and outbound policy for the missing prefix. ExplanationCorrect Answer A:Set the intended local preference consistently for the preferred egress route. BGP evaluates local preference before AS-path length when other earlier conditions are equal. Check local-pref values and the selected best path on internal BGP speakers. Other Answers B:Configure appropriate `next-hop-self` policy on the advertising boundary or distribute valid next-hop reachability. BGP evaluates local preference before AS-path length when other earlier conditions are equal. C:Validate AS-path prepending from external peers and treat it as a remote-inbound influence rather than a guaranteed local choice. BGP evaluates local preference before AS-path length when other earlier conditions are equal. D:Validate route-reflector client configuration and outbound policy for the missing prefix. BGP evaluates local preference before AS-path length when other earlier conditions are equal.
Question 198 Two eBGP exit routers learn the same prefix with different local preferences; traffic exits through the backup despite a shorter AS path on the primary. Which technical mechanism best explains the behavior observed in this scenario? BGP transport reachability does not by itself activate exchange for every multiprotocol address family. BGP evaluates local preference before AS-path length when other earlier conditions are equal. Cisco BGP ordinarily compares MED only among paths received from the same neighboring AS, subject to configuration exceptions. Cisco weight affects only the local BGP decision and is not advertised to other routers. ExplanationCorrect Answer B:BGP evaluates local preference before AS-path length when other earlier conditions are equal. This explains why the initial condition produces the observed failure. The direct repair is: Set the intended local preference consistently for the preferred egress route. Validate through: Check local-pref values and the selected best path on internal BGP speakers. Other Answers A:BGP transport reachability does not by itself activate exchange for every multiprotocol address family. BGP evaluates local preference before AS-path length when other earlier conditions are equal. C:Cisco BGP ordinarily compares MED only among paths received from the same neighboring AS, subject to configuration exceptions. BGP evaluates local preference before AS-path length when other earlier conditions are equal. D:Cisco weight affects only the local BGP decision and is not advertised to other routers. BGP evaluates local preference before AS-path length when other earlier conditions are equal.
Question 199 Two eBGP exit routers learn the same prefix with different local preferences; traffic exits through the backup despite a shorter AS path on the primary. After applying the correction, which verification evidence most directly demonstrates that this issue is resolved? Inspect next-hop reachability and confirm a formerly inaccessible BGP prefix becomes valid and installed. Compare the full path attributes, then demonstrate the expected winner after removing the unintended override. Check local-pref values and the selected best path on internal BGP speakers. Inspect neighboring AS values and compare the selected path under the approved MED policy. ExplanationCorrect Answer C:Check local-pref values and the selected best path on internal BGP speakers. This checks the affected traffic or control-plane behavior, not merely a generic up/down indicator. The underlying mechanism is: BGP evaluates local preference before AS-path length when other earlier conditions are equal. Other Answers A:Inspect next-hop reachability and confirm a formerly inaccessible BGP prefix becomes valid and installed. BGP evaluates local preference before AS-path length when other earlier conditions are equal. B:Compare the full path attributes, then demonstrate the expected winner after removing the unintended override. BGP evaluates local preference before AS-path length when other earlier conditions are equal. D:Inspect neighboring AS values and compare the selected path under the approved MED policy. BGP evaluates local preference before AS-path length when other earlier conditions are equal.
Question 200 Two eBGP exit routers learn the same prefix with different local preferences; traffic exits through the backup despite a shorter AS path on the primary. Which lasting design or operational safeguard best prevents this particular issue from recurring? Include end-to-end BGP next-hop reachability tests during iBGP rollouts. Plan nondisruptive BGP policy refresh procedures for routine filters. Include underlay reachability, TTL and update-source in loopback-peering templates. Centralize egress local-preference policy and test best-path order when adding peers. ExplanationCorrect Answer D:Centralize egress local-preference policy and test best-path order when adding peers. This addresses the recurring cause: BGP evaluates local preference before AS-path length when other earlier conditions are equal. A targeted acceptance check is: Check local-pref values and the selected best path on internal BGP speakers. Other Answers A:Include end-to-end BGP next-hop reachability tests during iBGP rollouts. BGP evaluates local preference before AS-path length when other earlier conditions are equal. B:Plan nondisruptive BGP policy refresh procedures for routine filters. BGP evaluates local preference before AS-path length when other earlier conditions are equal. C:Include underlay reachability, TTL and update-source in loopback-peering templates. BGP evaluates local preference before AS-path length when other earlier conditions are equal.
