In a multihomed AS running BGP, why does LOCAL_PREF control traffic leaving the AS while MED and AS_PATH length only influence traffic entering it?
answer
- whose decision process decides?
- you own the outbound choice
- inbound is a neighbour's LOCAL_PREF
- MED stops at the neighbouring AS
basics
~20 sOutbound traffic follows your own routers' decision, where LOCAL_PREF is compared first. Inbound traffic follows other ASes' decisions: MED and a longer AS_PATH are hints they weigh only after their own LOCAL_PREF, and MED only among routes from your AS.
solid answer
~40 sEvery BGP speaker picks paths for traffic it *sends*. Your routers choose your exit, and `LOCAL_PREF` — the first criterion, carried to every router in the AS over iBGP — makes that choice consistently, so it fully controls outbound traffic. Inbound traffic is chosen by other ASes' decision processes. You can only change what they see: a `MULTI_EXIT_DISC` to an adjacent AS, or a longer `AS_PATH`. They compare those only after their own `LOCAL_PREF`, which you never see because it is not sent to external peers. MED is weaker still: it is compared only among routes from the same neighbouring AS and is not passed beyond it, so it can choose between two links to one provider, never between two providers. Outbound is control; inbound is a request.
go deeper
Recall the split: LOCAL_PREF decides how traffic leaves your network; MED and AS_PATH length only ask other networks how to send traffic in.
Explain why: LOCAL_PREF is compared first and stays inside the AS, while MED reaches only the adjacent AS and is compared only among routes from one neighbouring AS.
Show the production view: a backup provider ignoring your longer path because its own preference ranks customers first, asymmetric flows, and measuring inbound and outbound separately.
Weigh the levers for inbound control — more-specific announcements against routing-table growth, provider cooperation against independence — and set expectations that inbound balance is negotiated, not configured.
## Two directions, two decision processes A BGP speaker's decision process answers one question: **which path do I use to send packets toward this prefix?** That makes direction the key to traffic engineering: - **Outbound** traffic (leaving your AS) is placed by **your** routers' decisions about other networks' prefixes. - **Inbound** traffic (entering your AS) is placed by **other ASes'** decisions about **your** prefixes. You configure your own decision process. You can only influence someone else's by changing the attributes on the routes you announce to them. ## Outbound: LOCAL_PREF is a decision you make Take enterprise AS 64500, dual-homed to provider A (AS 64501, the primary) and provider B (AS 64502, the backup). Its border routers set `LOCAL_PREF 200` on routes learned from A and `LOCAL_PREF 100` on routes learned from B. 1. Degree of preference is the **first** comparison in RFC 4271's decision process, ahead of `AS_PATH` length. 2. `LOCAL_PREF` is carried in every iBGP update, so **every router in AS 64500** sees the same preference and agrees on the exit. 3. Result: all outbound traffic leaves through A for every prefix A offers, whatever the path lengths; B is used only for prefixes A does not offer or when A's routes are withdrawn. That is control: one decision, enforced everywhere in the AS. RFC 4271 §9.1.1 spells out the mechanics: for a route learned from an external peer, the border router computes a degree of preference from its own policy, and that value MUST be used as the `LOCAL_PREF` when it readvertises the route over iBGP. Routers deeper in the AS then take the received `LOCAL_PREF` as the route's preference. The whole AS ranks the two providers the same way, so no internal router hands traffic to the "wrong" border. ## Inbound: you can only ask For traffic toward AS 64500's own prefix `198.51.100.0/24`, the decision belongs to providers A and B and everyone beyond them. | Knob you set | Who evaluates it | Where it sits in their decision | How far it reaches | |---|---|---|---| | your `LOCAL_PREF` | nobody outside — never sent to external peers | — | your AS only | | `MULTI_EXIT_DISC` | the adjacent AS only | after their preference, `AS_PATH` length and `ORIGIN` | not passed beyond the neighbouring AS | | longer `AS_PATH` | every AS that hears the route | after their own preference | the whole internet | Each lever arrives **after** the remote AS's own degree of preference, which you cannot see or set. ## Why MED fails between two different providers RFC 4271 compares MED **only between routes learned from the same neighbouring AS**. Provider A sees one route from AS 64500 on one link; it has nothing from AS 64500 to compare that MED against. Provider B is in the same position. And a MED received from a neighbouring AS MUST NOT be propagated to other neighbouring ASes, so nobody beyond the providers sees it. MED is therefore useful only when you have **two or more links to the same provider**: it then asks that provider which of your entry points to prefer. ## What actually decides inbound - **The provider's own preference.** Many providers prefer routes learned from customers over routes from peers or transit, so a backup provider may send traffic straight to you however long the path looks. - **More-specific prefixes.** A longer prefix is a different destination, and forwarding tables choose it by longest-prefix match whatever BGP ranked for the shorter one; that is a routing-table rule rather than a step in this decision. - **What the neighbour agrees to honour.** Tagging routes so a provider lowers its own preference is a policy tool configured between the two networks. - **Making the path look longer** (adding your AS more than once) is the classic request, and it works only where the remote preferences tie. ## Consequences an operator must expect - **Asymmetry is normal.** Outbound leaves by the link you chose; inbound arrives by the link others chose. Stateful devices on one link only will see half-flows. - **Inbound balance is approximate.** You shape it by announcements and measure the result; you cannot dictate it. - **Monitor both directions separately**, because a change that fixes one does nothing for the other.
- Your backup provider still delivers inbound traffic despite the longer AS_PATH you announce to it — why?Path length is compared only after the remote AS's own degree of preference. A provider that ranks customer routes above other routes sends traffic for your prefix to you directly, whatever the length, and ASes hearing both paths may rank by their own preference too. Making a backup truly idle needs the provider to lower its own preference, which is a policy arrangement between the networks.
- When does MED actually work for inbound steering?When you have two or more links to the same neighbouring AS. That AS compares your MEDs among the routes it learned from you — lower wins — once its preference, AS_PATH length and ORIGIN have tied. It steers only that neighbour's choice of entry point, and only if the neighbour keeps your MED; RFC 4451 notes many operators reset MEDs on ingress.
- Why does LOCAL_PREF give every router in the AS the same exit, while a router-local weight does not?`LOCAL_PREF` travels in every iBGP update, so each router in the AS sees and compares the same value. A router-local weight is an implementation feature that stays on one router and is never advertised, so the other routers keep deciding by the attributes and may choose a different exit.
Leaving your house, you pick the door. Visitors pick the door they arrive by; you can put up signs, but each visitor follows their own habits first and may ignore them.
saying these in an interview costs you the question
- Setting LOCAL_PREF on routes controls how other ASes reach you.
- A lower MED sent to one of two providers attracts inbound traffic to it.
- A longer AS_PATH guarantees the backup link carries no inbound traffic.
- LOCAL_PREF is sent to eBGP peers so they honour your preference.
- Traffic into and out of a multihomed AS uses the same link.