Elektrine lite

← Feed

@Jhaas@infosec.exchange

2026-08-01 16:40 UTC

ORIGIN, right below AS_PATH length, offers an "attractive nuisance" to bias traffic. As the various articles running around have noted, ORIGIN is a vestigial feature partially designed to help with the transition of ARPAnet/Internet routing from EGP to BGP. The primary motivation to move to BGP-4 was support of CIDR so we could get out of classful use of IP address space. I wasn't there, but talking with those that were, this transition was done very rapidly. As a result, migration mechanisms like ORIGIN to bias route selection and ATOMIC_AGGREGATE to try to avoid programmatic (de-)aggregation were largely non-issues. It's worth mentioning that even after a second round of moving from RFC 1771 which gave us our second (!) but well deployed version of BGP version 4 to RFC 4271 which cleaned up a lot of issues didn't fully clarify how ORIGIN is used. Probably the biggest lingering headache is "what is the ORIGIN of my static routes?" Some vendors do IGP, some do Incomplete. The result is that just for harmony in multi-vendor networks the ORIGIN is manually adjusted anyway - so tweaking things isn't exactly foreign to service providers. This hammer has been getting used further by providers, and its popularity is why we have the current kerfluffle: A service provider may choose to manipulate the ORIGIN at import time. This permits paths that are otherwise of similar length to stay that length, while providing some preference as to which ones you use throughout the AS. Some of you immediately say "well, why not use LOCAL_PREF?" The simple answer is that LOCAL_PREF is the biggest hammer in the toolbox. It stops caring about AS_PATH length or other tweaks unless you encode your entire AS-wide route selection policy and flatten it into an integer. Most providers say "yuck" and reach for the smaller hammers. Many providers as part of their policy will simply ignore received ORIGIN values anyway and reset them. This already means that even if the originating AS set it to one value that another may not respect that, expecting manipulation. Instead, they're violating the originating ASes intent. Which moves into the second part where this slightly smaller hammer is used: It's an attempt to put a lighter hand on incoming traffic load balancing. When it works, it's helpful. But it depends on downstream service providers themselves choosing to respect the upstream provider's desired intent. AS_PATH length thus is reasonably respected. ORIGIN might help, but is often ignored. The result is the toolbox has one solid tool available, and it is very clumsy.

Replies (1)

  • @Jhaas@infosec.exchange 2026-08-01 16:40

    MED tends to be in most people's BGP-101 toolkit. When supported by the receiving provider, it provides a good way to enable a solid "use this connection instead of that connection" feature. However, even when supported it's a big per-prefix hammer and really only helps in electing a single ingress. This is why many providers don't use the MED-as-specified feature. Rather, many use MED+IGP variants - that are not standardized in IETF! - to get the job done. MED is thus not even a good hammer many times, and may be a different tool (screwdriver?) depending on what the receiving provider is willing to do with it. And it only helps if supported by your adjacent AS - which might not be good enough if the traffic you're trying to bias is more than one AS hop away. As an aside, while the MED feature is beloved by operators, it is a massive PITA to implement. While these posts are about trying to "do something about" ORIGIN, if I had to take a feature to un-make, it'd be MED.

    Open ##5311552