BGP Local Preference: Leaving by the Wrong ISP
Production traffic is leaving by the cheap backup link because no attribute ever expressed the intent. Diagnose the local preference and fix it yourself, live, right below.
Symptom
Both sessions are up and both paths are valid, and all the production traffic is going out over the cheap backup circuit. Every earlier tiebreak is level, so the decision fell all the way to the bottom of the algorithm.
Your mission
Prove the cause, then fix it
Format
Guided CLI investigation
Investigate before you configure.
Use the CLI evidence to isolate the fault, make the smallest safe correction, then verify the network state changed.
Observe the symptom and link state.
Diagnose by comparing the protocol evidence.
Verify the expected device state and confirm the original symptom is resolved.
Console access: R1
This workspace stacks for portrait phones. Rotate to landscape for the full split-screen console.
Need a hint?
Reveal the root cause when you're ready.
Try the investigation first, then use this as your escape hatch, not a dead end.
Lab debrief
Turn the session into a repeatable troubleshooting pattern.
Use this reference after your attempt: first explain the symptom, then verify the evidence, then confirm the repair.
The problem
R1 is dual homed in AS 65001. ISP-A is the fast production circuit and ISP-B is a cheap backup, but all outbound traffic to 203.0.113.0/24 is leaving via ISP-B. Both sessions are established and both paths are valid.
What you'll practice
- Read the best-path marker and the LocPrf column in show ip bgp
- Work out which step of the best-path algorithm actually decided
- Set local preference with an inbound route-map
- Know why outbound application does nothing, and why a soft clear is required
1. Which step decided, and why it matters
With weight, local preference, AS path length, origin and MED all equal, BGP falls through to the lowest neighbour router ID, which is essentially arbitrary from a design point of view. You will learn to recognise when a path was chosen for a reason you never intended.
2. Inbound and outbound are not interchangeable
Local preference is advertised to iBGP peers and never to eBGP ones. Applying your route-map outbound sends it to the neighbouring AS, which discards it, and your own decision is unchanged. You will try it and watch nothing happen.
3. BGP does not re-decide on its own
Changing policy does not re-run best-path selection. Until you refresh the session the old choice stands, which is the most common reason people believe a correct route-map is broken.
The topology
R1 in AS 65001 peers with ISP-A (AS 65010) at 10.0.1.2 and ISP-B (AS 65020) at 10.0.2.2, both advertising 203.0.113.0/24.
Commands to run yourself
The real diagnostic commands for this lab, copy-paste ready. Run these in the same order to reproduce the investigation on your own session.
show ip bgpshow ip bgp 203.0.113.0show ip bgp summaryTopology diagram
Frequently asked
Both paths look identical, so how did BGP choose?
By working down the best-path algorithm until something differed. Weight, local preference, AS path length, origin and MED were all equal here, so it reached the final tiebreak and picked the neighbour with the lowest router ID. That is a perfectly deterministic choice and it has nothing to do with which circuit you wanted to use, which is exactly why you have to state a preference explicitly.
Why does applying the route-map outbound not work?
Because local preference is only ever advertised to iBGP peers inside your own AS. Sending it outbound means offering it to an eBGP neighbour, which discards the attribute, and your own router's best-path calculation never sees it. Local preference influences how you leave, so it has to be applied to routes as they arrive.
Why is a soft clear needed?
BGP does not re-evaluate best paths when policy changes; it applies policy as routes are received. Until you ask it to reapply inbound policy the previously chosen path stays best. clear ip bgp * soft in does that without tearing the sessions down, which matters on a production edge router where a hard clear would drop every prefix.
Ready to run this lab yourself?
No setup, no image sourcing. Book a session or ask for a live demo.