Strange BGP announcement

> Date: Fri, 13 Nov 1998 21:38:41 +0100
> From: "Winfried Haug" <haug@seicom.NET>
> To: "Enke Chen" <enkechen@cisco.com>, "Andrew Bangs" <andrewb@demon.net>
> CC: <nanog@merit.edu>

> > Yep, an invalid as-path attribute was injected from somewhere. Our as-path
> > sanity check code failed to catch this case.
>
> 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.

> > We have opened the following ddts:
> >
> > ======
> > Bug ID : CSCdk63586 Project: CSC.sys Status : O
> > 3 encls
> > Product : all Found : customer-use Care Update: N

"customer-use" ? *rofl*

Regards,
Andrew

> 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.

Hrmm.... Perhaps if the vendors covered the RFC error code type stuff at
least, then they could add kewl, new features like "as-path length" as a
step in the route selection process.

Andrew

TTFN,
patrick

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

You appear to have misunderstood the problem. The issue has nothing to do
with route selection, or are you talking about FastPath(TM, Pat Pending)
here?

The issue is that an invalid as-path attribute was injected from
somewhere. The cisco as-path sanity check code failed to pick it up.

Bug ID : CSCdk63586 Project: CSC.sys Status : O 3
encls
Product : all Found : customer-use Care Update: N
Versions : 11.1CC
Headline : BGP: Tighten as-path sanity check

                               -- Release-note --

When the total bytes (2*seglen) of an as-path segment is equal
to the as-path attribute length, the as-path sanity check would
fail and such a bad attribute would be accepted.

The workaround is to identify and get rid of the announcement
of prefixes with the bad attributes.

/vijay

You appear to have misunderstood the problem. The issue has nothing to do
with route selection, or are you talking about FastPath(TM, Pat Pending)
here?

Cute, Vijay. Really cute.

Of course, if everyone had only licenced it, we wouldn't have this problem
now, would we? :stuck_out_tongue:

The issue is that an invalid as-path attribute was injected from
somewhere. The cisco as-path sanity check code failed to pick it up.

[SNIP]

I have not misunderstood the problem, you have misunderstood my response.
Someone posted that the routers should follow the RFC. I was commenting
that you should be careful what you wish for. If we magically made all
routers strictly conform to the RFC instantly, it would have solved this
particular problem, but it would have caused *much* larger problems for the
'Net at large.

I was also hoping to start a debate by those more knowledgeable than I
about the ... wisdom of intentionally removing what is currently far and
away the most used metric for route selection from the next version of BGP;
namely: AS_PATH length. (At least I was under the impression that AS_PATH
length was the used more than all other metrics combined for route
selection in the backbone.) RFC1771 does not list AS_PATH length as a
selection criteria - but at least RFC1771 does not specifically forbid use
of AS_PATH length, as the draft for the next version does.

Or perhaps I'm just misinformed. I have not actually read the draft for
BGP 4+ (or whatever they're calling it now). This is second hand
information, but I consider it to be from a very reliable source (even if
he doesn't like ciscos ;). I am also not saying removal of this metric is
a gigantic mistake, but my thought process to date leads me to tentatively
believe it would be ... suboptimal. However, the people writing the spec
obviously know more about it than I do, perhaps I've overlooked something.

So, would anyone care to discuss (from an operational POV) what removing
AS_PATH length from the BGP route selection algorithm will do to the Internet?

/vijay

TTFN,
patrick

P.S. Before anyone goes off on me, I once again *agree* that the least
cisco could do is deal with malformed announcements and the errors they
generate properly. There are just other parts of the RFC with which I'm
not so sure I agree.

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

Cute, Vijay. Really cute.

Sorry. I tried. God knows, how I tried, but alas, the spirit was willing
but the flesh, it was weak.

Of course, if everyone had only licenced it, we wouldn't have this problem
now, would we? :stuck_out_tongue:

If we had a working draft to take a look at it, other than the marketspeak
on the web page, yeah...... And if we had some cheese, we could make a ham
and cheese sandwich, if we had some ham.

I have not misunderstood the problem, you have misunderstood my response.
Someone posted that the routers should follow the RFC. I was commenting
that you should be careful what you wish for. If we magically made all
routers strictly conform to the RFC instantly, it would have solved this
particular problem, but it would have caused *much* larger problems for the
'Net at large.

How so?

I was also hoping to start a debate by those more knowledgeable than I
about the ... wisdom of intentionally removing what is currently far and
away the most used metric for route selection from the next version of BGP;
namely: AS_PATH length. (At least I was under the impression that AS_PATH
length was the used more than all other metrics combined for route
selection in the backbone.) RFC1771 does not list AS_PATH length as a
selection criteria - but at least RFC1771 does not specifically forbid use
of AS_PATH length, as the draft for the next version does.

Exactly. The RFC says the following

   The selection process is formalized by defining a function that takes
   the attribute of a given route as an argument and returns a non-
   negative integer denoting the degree of preference for the route.
   The function that calculates the degree of preference for a given
   route shall not use as its inputs any of the following: the
   existence of other routes, the non-existence of other routes, or the
   path attributes of other routes. Route selection then consists of
   individual application of the degree of preference function to each
   feasible route, followed by the choice of the one with the highest
   degree of preference.

So, if a router conforms magically to the RFC, no big issue, it is
left up to the implementors to decide how to do the selection.

Or perhaps I'm just misinformed. I have not actually read the draft for
BGP 4+ (or whatever they're calling it now). This is second hand
information, but I consider it to be from a very reliable source (even if
he doesn't like ciscos ;). I am also not saying removal of this metric is
a gigantic mistake, but my thought process to date leads me to tentatively
believe it would be ... suboptimal. However, the people writing the spec
obviously know more about it than I do, perhaps I've overlooked something.

So, would anyone care to discuss (from an operational POV) what removing
AS_PATH length from the BGP route selection algorithm will do to the
Internet?

Are you talking about rfc2283 (multiprotocol extentions to bgp)?

/vijay

I Am Not An Isp <patrick@ianai.net> writes:

[wrt RFC 1771, A Border Gateway Protocol 4]

There are just other parts of the RFC with which I'm
not so sure I agree.

Oh do tell. Better still, tell the IDR WG.
There are open drafts which might be apropos
to your concerns, and certainly nobody would assert
that they are flawless.

  Sean.