Steering traffic in a multihomed BGP network: the egress-vs-ingress asymmetry, outbound control with weight/local-preference, inbound influence with AS-path prepend, MED, communities, selective advertisement and more-specifics, propagation scope (NO_EXPORT/conditional/anycast), common multihoming recipes, and the gotchas.
Once you're multihomed, the real BGP work is steering traffic: which link carries what, and how you fail over. The single most important idea — and the one interviewers probe — is the asymmetry: you have near-total control over outbound (egress) traffic, but you can only hint at how the Internet sends you inbound (ingress) traffic. Everything else follows from that.
Egress = your decision. Your routers run the best-path algorithm, so local knobs win. Ingress = someone else's decision. You advertise, but every remote AS picks its own best path; you can only influence what you advertise and how it looks.
Outbound path selection is just the BGP best-path algorithm on your routers. Set these on inbound route-maps (as you receive routes) to choose which exit each prefix uses:
| Knob | Scope | Rule | Use |
|---|---|---|---|
| Weight (Cisco) | Local to one router | Highest wins | Per-router exit preference; never leaves the box. |
| Local Preference | AS-wide (iBGP) | Highest wins | The primary outbound tool — make the whole AS prefer provider A. |
| AS-path length | Global attribute | Shorter wins | Comes after local-pref; also what you manipulate for inbound. |
| Origin | Global | IGP < EGP < incomplete | Minor tie-breaker. |
| MED | To a neighbor AS | Lowest wins | Affects egress only when comparing paths from the same neighbor AS. |
Classic recipe: "send all outbound via provider A, fail to B" → set higher local-pref on routes learned from A. It's AS-wide and deterministic. Full best-path order in BGP Theory.
You can't set attributes on remote routers, so inbound control means shaping what you advertise. From weakest-to-strongest / least-to-most disruptive:
| Technique | How it works | Caveat |
|---|---|---|
| AS-path prepend | Repeat your ASN on the advertisement out the less-preferred link so that path looks longer. | Only helps once other ASes reach AS-path in their decision (after their own local-pref); an arms race. |
| MED | Tell a single upstream AS which of your entry points to prefer (lower = preferred). | Only compared between paths from the same AS; non-transitive; often reset/ignored by providers. |
| BGP communities | Tag routes with the provider's well-known communities to make them set local-pref, prepend, or not-advertise on your behalf. | The scalable, precise inbound tool — but provider-specific; read their community guide. |
| Selective advertisement | Advertise a prefix only out the link you want to receive it on (or use conditional advertisement for backup). | Loses redundancy for that prefix unless carefully paired. |
| More-specifics | Advertise a longer prefix (e.g. two /25s) out the preferred link; longest-prefix match beats everything. | The big hammer — pollutes the global table; may be filtered (min-length, max-prefix). |
Why local-pref doesn't help inbound: local-pref never leaves your AS, so it can't influence a remote AS's choice. That's the crux of the asymmetry.
NO_EXPORT — keep a route inside the neighboring AS (don't re-advertise to
its peers); handy for more-specifics you don't want the whole Internet to see.NO_ADVERTISE — don't advertise to any peer.| Goal | Outbound | Inbound |
|---|---|---|
| Prefer provider A, B as backup | Higher local-pref on A | AS-prepend on B (and/or a community lowering B's local-pref); optionally advertise only to A + conditional to B |
| Load-share across A and B | Local-pref per prefix group | Split announcements (different prefixes/more-specifics per link) — hard to do evenly |
| Primary/backup on one ISP (two links) | Weight/local-pref on the primary | MED (lower on primary), or prepend on backup |