[28899] in North American Network Operators' Group
Re: That pesky AS path corruption bug...
daemon@ATHENA.MIT.EDU (Peter T. Whiting)
Tue May 23 13:38:30 2000
Date: Tue, 23 May 2000 12:35:16 -0500
From: "Peter T. Whiting" <pwhiting@fury.ittc.ukans.edu>
To: Blaine Christian <blaine@inbound.blaines.net>
Message-ID: <20000523123516.A11052@sprint.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.10.10005231234410.19459-100000@inbound.blaines.net>; from blaine@inbound.blaines.net on Tue, May 23, 2000 at 12:40:00PM -0400
Errors-To: owner-nanog-outgoing@merit.edu
looking for some more details about what the malformed aspath looks
like. I took a router in my lab and started sending it some bogus
as_paths. It seemed to accept everything I would send. Here is one
aspath which doesn't include the remote-as and loops all over the
place. It was happily accepted.
BGP routing table entry for 10.1.2.3/32, version 414648
Paths: (1 available, best #1)
Advertised to non peer-group peers:
10.254.254.1
1 2 3 4 3 2 1 2 3 4 3 2
129.237.125.185 from 129.237.125.185 (0.0.0.120)
Origin EGP, localpref 100, valid, external, best
Dampinfo: penalty 980, flapped 2 times in 00:00:57
pete
On Tue, May 23, 2000 at 12:40:00PM -0400, Blaine Christian wrote:
>
> Hello all,
>
> After observing a recent issue regarding a router that sent corrupted AS
> path (all names are witheld to protect the guilty). I took a look at the
> path information that was being received and have a possible solution.
> Since the corrupted AS-path does not include the AS that the route is
> coming from (at least in the corruption that I saw) it seems to me that a
> simple solution for all is to filter on AS i.e. only allow routes that
> have the AS of your EBGP neighbor prepended to them. I realize this does
> not cover all cases of wacky AS corruption problems but it may fix some of
> them. I would suggest that those of you running mixed vendor EBGP (again
> names witheld) should implement a version of this strategy for your own
> self protection. It can certainly be implemented as part of an overall
> customer access functionality. This may be obvious to some of you but I
> do not believe that everyone is at this level yet.
>
> Of course the tirade part of this email is for all vendors involved in
> this travesty. If you do not understand or dislike a route that you have
> received don't just CRASH. Anyone ever thought of checking the route and
> throwing it out with an error message if you don't like it? I, of course,
> have heard and seen that several vendors have fixed this in the more
> recent releases. This type of bug is something that everyone who writes
> software has to deal with. If you raise an exception for bad input it is
> bad form to crash or reset your application.
>
> BTW, I am sure all have heard this argument before. I just wanted to get
> this topic renewed.
>
> Regards,
>
> Blaine
>
>
