← All challenges
hardbgp~75 min

A multi-homed edge keeps choosing the wrong upstream

You have two upstreams advertising the same destination. Make your router prefer one of them outbound, and steer inbound traffic the same way.

Scenario

R1 (AS 65001) is multi-homed: it peers with two upstreams, R2 (AS 65002) and R3 (AS 65003). Both upstreams advertise the same destination, 203.0.113.0/24. You want R2 to be primary: R1 should send traffic toward 203.0.113.0/24 via R2, and you'd like return traffic to come back via R2 too.

Right now best-path selection is picking an upstream on a tiebreaker you don't control, and inbound traffic is split.

Topology

  • R1: AS 65001, advertising 10.0.1.0/24; links 10.0.12.1/30 (to R2) and 10.0.13.1/30 (to R3)
  • R2: AS 65002, advertising 203.0.113.0/24
  • R3: AS 65003, advertising 203.0.113.0/24

Your job

  • Outbound: make R1 prefer R2 for 203.0.113.0/24 using local-preference.
  • Inbound: make R3's path to your 10.0.1.0/24 look worse by prepending your AS on the advertisement to R3, so the outside world prefers reaching you via R2.

Don't change R2 or R3.

What "done" looks like

R1's route to 203.0.113.0/24 is via R2, and R1's advertisement of 10.0.1.0/24 toward R3 carries a prepended AS-path.

Teaches: the two levers that actually steer multi-homed traffic: local-preference for your own outbound choice, and AS-path prepending to influence what the other side picks.

What gets checked

Your solution is verified against each of these:

  • Both eBGP sessions (to R2 and R3) are Established
  • R1's chosen route to 203.0.113.0/24 leaves through R2, even though both upstreams advertise it
  • Inbound traffic for 10.0.1.0/24 returns through R2 as well, because R3 sees R1's path as the less attractive one

Solve it in the browser lab

No setup, no install. Open a live lab: configure each device in the editor or its Cisco IOS terminal, run show/ping/traceroute (or test from the hosts), and watch the network react. The in-house engine grades your fix instantly and issues your proof the moment every check passes.

Open the lab →

Prefer your own lab?

  1. Build the fix locally. New to the tooling? See setting up your lab.
  2. Push your topology file, device configs, and any playbooks to a public repo (GitHub or GitLab).
  3. Submit the repo link. We review it by hand, confirm it works, and issue your proof page.
Submit your solution →