HE.net BGP origin attribute rewriting

Thu May 31 16:27:16 UTC 2012

On 31/05/2012 16:46, David Barak wrote:
> On what precisely do you base the idea that a mandatory transitive
> attribute of a BGP prefix is a "purely advisory flag which has no real
> meaning"?

Let's say network A uses cisco kit and injects prefixes into their ibgp
tables using network statements.  The default for this is to set
origin=igp.  On the other hand, network B also uses cisco kit and uses
"redistribute" to inject static routes from their route reflectors.  By
default, these prefixes will have origin=incomplete.  Network C uses
juniper kit, which sets origin=igp for all injected prefixes, regardless of
whether it's via an IGP or some other means.

So, the default origin policy is that unless the originator of an prefix
manually tweaks the origin to be consistent with something that is actually
consistent (with what, I don't know - because there is no good definition
of the difference between, say, igp and incomplete), then different
_syntactic_ network configurations will set the parameter differently, even
if there is no _semantic_ difference in those configs.

This is a pretty random mess.  I do not wish to operate the networks which
I manage on the basis of a parameter which is basically arbitrary and which
can be tuned by an upstream connectivity provider to their advantage based
on their whims.

> I encourage you to reconsider that opinion - it's actually a
> useful attribute, much the way that MED is a useful attribute.  Many
> providers re-write MED, and apparently some re-write ORIGIN.  Neither of
> those is "network abuse" - it's more accurately described as "network
> routing policy."

med is useful in an inter-asn context if you have multiple links into a
specific asn and wish to discriminate between them on the basis of what
that ASN suggests.  Same for origin if you trust that the other ASN has
configured origin in a sensible manner.

MED can be trusted in situations where you have a prescribed policy for
trusting med, preferably backed by a contract which defines the MEDs.
Otherwise, thanks but no thanks.

> As has been stated here before: your network, your rules.

yep, definitely! :-)

Nick