Strange BGP announcement

patrick@ianai.net wrote:

>> > thank you for this nice code, which caused our gated to crash...
>> > Where may i send my bill to :-)))
>>
>> I suggest the bill be sent to the guy/vendor that injected the
>> bad path :slight_smile:
>
>Hmm. If the upstream had been running code that did what the RFC says
>then Winfried wouldn't have a bill to send to anybody...
>It isn't like this was the first time we've seen this problem, either.

You really want all backbone routers to ignore AS-Path length in the BGP
route selection process? I think I like it better the way it is now - at
least for the near future.

I don't recall saying that, or anything about route selection.
I don't want all backbone routers (or any of them, for that matter)
ignoring Update messages (or worse, propagating the announcements) with
malformed AS_PATH attributes when they should be returning a NOTIFY and
closing the BGP session.

Regards,
Andrew

I don't recall saying that, or anything about route selection.
I don't want all backbone routers (or any of them, for that matter)
ignoring Update messages (or worse, propagating the announcements) with
malformed AS_PATH attributes when they should be returning a NOTIFY and
closing the BGP session.

You said you wanted routers that followed the RFC. The RFC does not
mention list AS_PATH length as a route selection criteria. I have been
told that the draft for the next rev specifically prohibits using AS_PATH
length as a route selection criteria.

I kinda like using AS_PATH length. It's not perfect - and I'm definitely
open to suggestions - but for now it's working. And changing that in
today's environment would be ... monumental to say the least.

OTOH, I completely agree that the routers should have *not* passed on
malformed announcements, and behaving improperly to certain errors.

Andrew Bangs, Network Engineering Manager, Demon Internet Ltd

TTFN,
patrick

I Am Not An Isp
www.ianai.net
"Think of it as evolution in action." - Niven & Pournelle

patrick@ianai.net (I Am Not An Isp) writes:

You said you wanted routers that followed the RFC. The RFC does not
mention list AS_PATH length as a route selection criteria. I have been
told that the draft for the next rev specifically prohibits using AS_PATH
length as a route selection criteria.

Patently false. In particular, the spec allows an implementation to invoke
local policy when computing the local preference of a route. An
implementation can reasonably incorporate the AS path length in its local
preference calculations as part of its policy.

Tony

patrick@ianai.net (I Am Not An Isp) writes:

You said you wanted routers that followed the RFC. The RFC does not
mention list AS_PATH length as a route selection criteria. I have been
told that the draft for the next rev specifically prohibits using AS_PATH
length as a route selection criteria.

Patently false. In particular, the spec allows an implementation to invoke
local policy when computing the local preference of a route. An
implementation can reasonably incorporate the AS path length in its local
preference calculations as part of its policy.

Guess that answers the question. So the draft for the next version of BGP
does not list as-path length as a necessary criteria, but does leave the
door open for vendor implementations (much like the current standard).

This, of course, leads to many, many other questions (such as the
possibility routing loops caused by different local policies as was seen
with implementations of BGP4), but few of which are of a truly operational
issue. So I will apologize for starting a thread based on mis-information
and go back to my cave.

Tony

TTFN,
patrick

I Am Not An Isp
www.ianai.net
"Think of it as evolution in action." - Niven & Pournelle

This, of course, leads to many, many other questions (such as the
possibility routing loops caused by different local policies as was seen
with implementations of BGP4), but few of which are of a truly operational
issue. So I will apologize for starting a thread based on mis-information
and go back to my cave.

Different local policies should all be reflected in the LOCAL_PREF, which
should be distributed to all nodes within the domain. This should lead to
consistent decisions within the domain and thus should avoid stable
forwarding loops.

Tony

The key to this is that the administrative preference in question has domain
scope. Assuming you are correctly implementing iBGP, whether with a full
mesh, reflectors, or confederations, and assuming consistent announcements
from external route originators, then you can't make a loop because the
same policy is in effect for all the routers in the AS.

Incomplete iBGP implementations and router-local administrative preferences
can easily be used to create loops, but that is certainly not a problem
with BGP.

Ben