danny at danysek
Jun 2, 2012, 12:03 AM
Post #25 of 28
(541 views)
Permalink
|
|
Re: HE.net BGP origin attribute rewriting
[In reply to]
|
|
On 06/02/2012 02:42 AM, Richard A Steenbergen wrote:
> On Fri, Jun 01, 2012 at 08:03:50PM +0200, Daniel Suchy wrote:
>> By overwriting origin field, there's no warranty that someone improves
>> performance at all - it's just imagination. In extreme cases,
>> performance can be degraded when someone in the middle plays with
>> origin field and doesn't know reasons, why originating network uses
>> something else than IGP origin. In RFC 2119 words, full implications
>> were not understanded - when this overwriting is done generally.
>
> Uh, what part of "to prevent remote networks from improperly forcing a
> cold potato routing behavior on you" sounds imaginary?
It depends, not everything looking as proper from single network
operator in the middle can be proper in end-to-end user experience,
where multiple networks are traversed.
>> Also, there must be some historical reason, why origin should not be
>> rewritten (this changed in January 2006). For internal reasons within
>> the network operator still haves enough knobs to enforce own policy
>> (by setting localpref, med on his network).
>
> Not really, no. Not every RFC is 100% correct, and they're often written
> by people who are not operators (because operators are too busy running
> real networks :P). Besides, "SHOULD NOT" means "you probably don't want
> to do this, unless you have a really good reason", and enforcing such an
> important point in a peering policy is a pretty good reason.
If someone comes with some implementation overwriting ASPATH (even it
may not) and excuses this by RFC incorrectness from his perspective,
you'll understand it? Probably not. It's relative.
> You also clearly don't understand the practical use of localpref. When
> you're trying to implement a simple and relatively common policy like
> "closest exit routing to a peer with multiple exits", you set the
> localprefs the same (localpref is usually used to determine WHICH peer
> you'll be sending to), you set the MEDs the same (if you don't want to
> artifically select which EXIT to use), AS-PATH lengths are obviously the
> same if you have multiple exits, and then the next one down is origin
> code. If you can't reset origin code, you run the risk of a remote
> network being able to force your network to do something you probably
> don't want to do (or at least probably wouldn't want to do, if you had
> any idea what you were doing :P).
Well, this matches situatios, where two networks have more than single
interconnection and still for prefixes originated from that particular
network. But when there's only one interconnection, there's no such
reason. Intermediate networks, even having multiple peers will probably
see similar origin on all their peers.
> Please see the previous commentary from Joe Provo, Saku Ytti, etc, they
> are quite correct.
I don't think they admits all consequences. When some knob (origin) is
not disabled by policy for single prefix visible at multiple points,
some "creative" operators should come with other methods to achieve what
they wants. Prefix deagregation is first thing, that comes to mind. Even
they'll also slightly violate RFC (having not single policy - well, they
assume RFC is not correct), they simply start to announce deagregated
prefixes next to aggregate one. But deaggregated prefixes are announced
only to specific peers - and yes, this works. Then, you can have any
policy, have everything normalized at all peers - but most specific
prefix in your table visible over particular path simply wins over
everything. And this is not a imaginary case - this is clearly visible
in real routing table - 41% of address space (in IPv4) is deaggreated,
in my experience mainly due to "traffic engineering" purposes - smaller
end networks are simply enforced to do this, and some people here
confirmed this in this discussion...
- Daniel
|
1
