Refer to the exhibit. The service provider operations team was alerted that hub site traffic from BGP AS 65101 to AS 65201 uses a non-primary path via the R5-R6 link. IBGP peering between R1 and R2…

Question

Exhibits

Options

• AAdd metric 5 with BGP neighbor 10.10.10.6 on R5 for receiving routes.
• BChange the metric attribute to 20 with neighbor 10.10.10.5 on R1.
• CSet the local-preference to the default value with BGP neighbor 10.10.10.3 on R2 for receiving
• DChange the local-preference attribute to 50 with neighbor 10.10.10.5 on R1.

• A
  11% (4)
• B
  5% (2)
• C
  22% (8)
• D
  62% (23)

Explanation

Option D is correct because the R5-R6 alternate path is being selected over R1-R2-R3-R4 due to a local preference conflict within AS 65101. By setting local preference to 50 on R1 for routes received from neighbor 10.10.10.5 (R5), those routes become less preferred than the primary path, which retains the BGP default local preference of 100 - so the R1-R2-R3-R4 path wins.

Option A is wrong because adding a MED (metric) on R5 for routes from R6 addresses the wrong router and the wrong attribute - MED is ranked below local preference in BGP's decision process, so it cannot override a local preference mismatch.

Option B is wrong for the same reason: changing the metric/MED on R1 for neighbor 10.10.10.5 is irrelevant when local preference is the governing factor; BGP evaluates local preference before MED.

Option C is wrong because setting local preference to default (100) on R2 for routes from R3 keeps the primary path at the same priority as the alternate - it creates a tie rather than making the preferred path win.

Memory tip: Think "LP beats MED" - Local Preference (higher wins, default 100) is evaluated before MED in BGP's decision order. Whenever an internal AS is taking the wrong exit, look at local preference first, and lower it on the bad path rather than trying to fix MED.

No community discussion yet for this question.