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.