RE: anyone else seeing very long AS paths?

["Ivan Pepelnjak" <ivan.pepelnjak () zaplana net>]

According to publicly available bug toolkit, CSCee30718 did not touch the
maxas limit.

The hard-coded maxas-limit in recent IOS releases is 254 (not 75 as
suggested in a previous e-mail).

Classic IOS (I did not test XE, XR or NX) can handle inbound updates with AS
path lengths above 255, but fails miserably when it has to send an oversized
update (producing invalid BGP UPDATE message), resulting in a flapping BGP
session (anyone who wants to test this behavior and report/fix this bug can
get all the files needed to reproduce it).

The hard-coded maxas-limit prevents this behavior (254 + my AS = 255), but
if you use AS-path prepending on outbound update, you're fried.

The __ONLY__ way to be on the safe side is to configure "bgp maxas-limit",
otherwise someone who knows you're doing AS-path prepending on major peering
sessions (and no inbound AS-path filtering) can selectively target your
peering points.

I've summarized everything I've discovered in various stress tests today
(well, not the targeted attack :) in this article:
http://wiki.nil.com/Limit_the_maximum_BGP_AS-path_length

Feel free to improve it:)
Ivan
http://blog.ioshints.info

> -----Original Message-----
> From: German Martinez [mailto:gmartine () ajax opentransit net]
> Sent: Tuesday, February 17, 2009 7:55 PM
> To: Michael Ulitskiy
> Cc: nanog () nanog org
> Subject: Re: anyone else seeing very long AS paths?
>
> On Tue Feb 17, 2009, Michael Ulitskiy wrote:
>
> Hello,
> CSCee30718 - it removes the default value of bgp max-as from the 
> router.
>
> The solution is introduced in CSCeh13489
>
> BGP shouldn't propogate an update w excessive AS Path > 255
> Symptoms: A router may reset its Border Gateway Protocol
> (BGP) session.
>
> Conditions: This symptom is observed when a Cisco router that peers 
> with other routers receives an Autonomous System (AS) path with a 
> length that is equal to or greater than 255.
>
> Workaround: Configure the bgp maxas limit command in such as way that 
> the maximum length of the AS path is a value below 255. When the 
> router receives an update with an excessive AS path value, the prefix 
> is rejected and recorded the event in the log.
>
> This workaround has been suggested previously by Hank.
>
> Anyone knows about any possible CPU impacts in case that you implement 
> bgp maxas?
>
> Thanks
> German
>
> > My bgp speaking devices are a couple of 7200s running 12.2(40). 
> > Not the newest IOS out there, but it's been doing the job
> just fine up until yesterday.
> > Yesterday, when that malformed announcement hit my routers
> they didn't
> > crash, but they did reset bgp sessions (even though I didn't accept 
> > the route) and they kept doing so until I got my upstream
> to filter it out.
> > According to cisco bug toolkit CSCdr54230 should be fixed
> in 12.2, so obviously it's not enough.
> > Does anybody know what IOS version has fix this problem,
> 'cause I couldn't find this info at CCO?
> > Thanks,
> >
> > Michael
> >
> > On Tuesday 17 February 2009 10:21:07 am Etaoin Shrdlu wrote:
> > > Jared Mauch wrote:
> > >
> > > > On Tue, Feb 17, 2009 at 08:07:36AM +0200, Hank Nussbacher wrote:
> > >
> > > > > "They" will keep trying and until a vast majority of ISPs 
> > > > > implement maxas, this will keep happening.
> > >
> > > >         Or until people who are still running
> multi-year old cisco code
> > > > actually upgrade?  This seems to primarily impact:
> > > >
> > > >         1) Old cisco code
> > > >         2) PC based bgp daemons
> > >
> > > > Both of which likely just need to be upgraded.  I
> actually suspect
> > > > that a lot of people who dropped their bgp sessions did
> not notice
> > > > something happened, and still will not upgrade their code....I 
> > > > suspect these people don't even know they have a bgp speaking 
> > > > device anymore.
> > >
> > > On the other hand, the fact that various entities have
> gone out of
> > > their way to advertise that they're running old
> hardware/out-of-date
> > > software has been noted elsewhere. I'd strongly suggest,
> if you're reading NANOG,
> > >   that you update, before someone less pleasant and friendly than 
> > > myself finds you. Please.