BGP Deep Dive Part 9: Traffic Engineering, or Why Outbound Is Easy and Inbound Never Fully Is

Every tool used in this post has already been introduced somewhere earlier in this series. That’s deliberate: traffic engineering isn’t a separate BGP feature, it’s Part 3’s attributes and Part 8’s filtering mechanisms, applied with specific intent once an AS has more than one path to the outside world.

Multihoming creates the problem this post solves

An AS is multihomed the moment it connects to more than one upstream provider, or peers with more than one AS, for redundancy, performance, or both. The instant there’s more than one viable path, something has to decide how traffic actually splits across them, and that decision is traffic engineering. It splits cleanly into two directions that are not equally easy to influence, and understanding why is more useful than memorizing the mechanisms individually.

Outbound: a solved problem

Controlling how an AS’s own traffic leaves it is genuinely straightforward, because Part 4’s best path algorithm runs locally, on the AS’s own routers, using attributes the AS fully controls. LOCAL_PREF, from Part 3, is the entire mechanism: apply a higher value to routes received from the preferred provider, and Part 4’s algorithm settles it at step 2, before AS_PATH length, MED, or anything else even gets evaluated. There’s no ambiguity and no dependency on any other network’s cooperation. This is why outbound TE gets a short section in this post: it’s not that it’s unimportant, it’s that it’s already been fully explained, twice, by the time this series gets here.

Inbound: the harder problem, honestly stated

Influencing how traffic from other autonomous systems reaches this one is a fundamentally different kind of problem, and it’s worth being direct about why: Part 4’s best path algorithm runs on the sending network’s routers, not this AS’s own, using that network’s own locally configured policy. Nothing this AS does can force a specific outcome on equipment it doesn’t operate. Every inbound TE technique available is really a way of trying to influence someone else’s decision, with no guarantee they’ll respond the way intended, or at all.

AS-path prepending: making a path look worse, not demanding a specific one

Prepending, previewed back in Part 4, means announcing a route toward the less-preferred provider with the local AS number repeated in AS_PATH multiple times, artificially inflating the path length that step counts. It works because AS_PATH length sits high in the decision chain, ahead of MED and origin. But it’s a blunt instrument in two specific ways worth being honest about: it can only make a path look worse, there’s no equivalent move that makes a path look definitively better than reality; and its actual effect depends entirely on how every third-party AS evaluating both paths happens to apply its own policy. If a nearer AS has already set a strong LOCAL_PREF preference for the prepended path for its own unrelated reasons, that preference gets evaluated before AS_PATH length ever comes into play per Part 4’s ordering, and the prepending accomplishes nothing for that particular AS’s traffic. Prepending is a request expressed as an unattractive number, not an instruction.

MED: useful, but only toward one specific neighbor

MED, from Part 3 and Part 4, only has any effect on how one directly connected neighboring AS chooses between multiple entry points into this AS. It says nothing to, and has no effect on, any AS further upstream, and per Part 4’s step 6 it’s only compared by default among routes from that one same AS in the first place. MED is a real, useful tool for exactly one specific relationship, immediate neighbors with more than one interconnection point, and not a general inbound TE mechanism beyond that scope.

Selective announcement: the one lever that doesn’t need anyone’s cooperation

The most reliable inbound TE tool in this list isn’t a BGP attribute at all, it’s simply choosing what to announce, and to whom. Withholding a prefix from one provider entirely, or announcing only an aggregate to one provider while announcing the more specific covered prefixes to the preferred one, works because of something below BGP’s own best path algorithm: longest-prefix-match at the forwarding level. Part 8 covered why more-specific prefixes generally get filtered past /24 or /48, but within that limit, a more specific route wins a forwarding lookup regardless of any BGP attribute whatsoever, since longest match is evaluated before BGP’s own tie-breaking would even apply. That makes selective de-aggregation the one inbound TE technique that doesn’t depend on any other AS’s policy cooperating, it depends only on how forwarding tables fundamentally work, which is why it’s often the most dependable option available even though it’s the least attribute-driven one on this list.

Communities: asking directly, rather than hoping a side effect lands

Part 7 already covered the mechanism; this is where it gets used. Many transit providers publish a documented set of community values a customer can attach to a route specifically to request handling at that provider’s own edge: don’t announce this prefix to a particular peer, prepend a specific number of times only in a specific direction, apply a particular local-preference tier. This is, in practice, the most granular and most commonly used real-world inbound TE tool, precisely because it’s a direct request to the one AS that will actually act on it, rather than an indirect signal, prepending or MED, whose effect depends on how several other independent networks’ unrelated policies happen to interact with it.

The honest summary

Outbound TE is deterministic because the AS doing it also runs the algorithm that decides the outcome. Inbound TE is probabilistic, at best, because every technique available is a signal sent outward into networks that owe this AS nothing beyond what’s already been contracted or agreed, and each of them can simply choose not to respond to it. That asymmetry isn’t a limitation of any particular tool, it’s the direct consequence of Part 1’s opening thesis: BGP negotiates policy between independently operated networks, it doesn’t compute one objectively correct answer everyone is bound to honor. Two common multihoming designs fall directly out of this: active/active, where both providers genuinely carry live traffic and the AS accepts the extra tuning work MED, LOCAL_PREF, and selective announcement require to actually balance load rather than just failover, and active/backup, where LOCAL_PREF cleanly prefers one provider and the other only sees traffic once the preferred path is fully withdrawn. Both are valid; which one an AS should run is a question this series’ answer has been consistent since Part 1, it depends entirely on what that AS’s own policy actually needs.

Part 10 moves to a different kind of extension entirely: multiprotocol BGP, and how the same session type that’s carried IPv4 unicast through this whole series can carry IPv6, MPLS L3VPN, and EVPN over the exact same TCP connection.