Typo in one part so sending to make it accurate.
The workaround is to implement CmdBold bgp maxas-limit X NoCmdBold on the
device that after prepending would need to send an update with over 255 AS
hops. Since IOS limits the inbound prepending value to 10 the most that
could be added iss 11
We are working on a document for Cisco.com but in the interim
here is the bug that will fix the issue of a Cisco IOS device
sending an incorrectly formatted BGP update when as a result
of prepending it goes over 255 AS hops.
Note: The Title and Release-note on bug toolkit may be a
bit different
.
-Original Message-
From: Paul Ferguson [mailto:fergdawgs...@gmail.com]
Sent: Tuesday, February 17, 2009 01:02 PM
To: nanog@nanog.org
Subject: Re: anyone else seeing very long AS paths?
On Mon, Feb 16, 2009 at 8:51 PM, Michael Ulitskiy mulits...@acedsl.com
wrote:
It hit my routers at 11
* Hank Nussbacher:
They will keep trying and until a vast majority of ISPs implement
maxas, this will keep happening.
Or enthusiastic prepending will be used more often to override local
preference. Hard to tell.
--
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH
On Tue, Feb 17, 2009 at 08:07:36AM +0200, Hank Nussbacher wrote:
A regular UN of attempts to do this previously:
24532 - PT. Inet Global Indo, Indonesia
43179 - Team Consulting AS, Bosnia and Herzegovina
48262 - Noblecom Ltd., Bulgaria
6488 - Arizona Macintosh Users Group, USA
39625 -
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
On Tue, Feb 17, 2009, Etaoin Shrdlu wrote:
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
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
On Tue, 17 Feb 2009, Jared Mauch wrote:
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
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)
German Martinez wrote:
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
On Tue Feb 17, 2009, Mike Lewinski wrote:
bgp max-as will NOT protect you from this exploit (but if you are not
vulnerable it should prevent you from propogating it).
Are you trying to say that the receiving bgp speaker will drop the session
no matter what but it won't forward the update?
German Martinez wrote:
On Tue Feb 17, 2009, Mike Lewinski wrote:
bgp max-as will NOT protect you from this exploit (but if you are not
vulnerable it should prevent you from propogating it).
Are you trying to say that the receiving bgp speaker will drop the session
no matter what but it won't
: German Martinez [mailto:gmart...@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
Ivan Pepelnjak wrote:
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
Jack Bates wrote:
Just to reconfirm. The issue arrives with sending an update, not
receiving? So if an ISP does not have a limit and their IOS cannot
handle this, they will send an invalid BGP UPDATE to the downstream
peers causing them to reset regardless of their max as-path settings?
...@brightok.net]
Sent: Tuesday, February 17, 2009 8:31 PM
To: Ivan Pepelnjak
Cc: nanog@nanog.org
Subject: Re: anyone else seeing very long AS paths?
Ivan Pepelnjak wrote:
Classic IOS (I did not test XE, XR or NX) can handle
inbound updates
with AS path lengths above 255, but fails miserably
We were dropping ALL prefixes and the eBGP session was still
resetting.
Upstream or downstream?
1) bgp maxas-limit 75 had no effect mitigating this problem
on the IOS we were using. That is: it was previously verified
to be working just fine to drop paths longer than 75, but
once we
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 17, 2009, at 1:50 PM, Ivan Pepelnjak wrote:
As far as I understand the issues :)
There are two limits: the first one @ 128 AS numbers (where BGP
switches to
the 'extended length' of BGP attribute), the other one @ 256 AS
numbers
On Tue Feb 17, 2009, Ivan Pepelnjak wrote:
According to publicly available bug toolkit, CSCee30718 did not touch the
maxas limit.
I will double check this with Cisco
pgpeuQs06hcKd.pgp
Description: PGP signature
Ivan,
It is confusing but from what I have tested you have it correct.
The confusing part comes from multiple issues.
a) The documentation about the default maxas limit being 75 appears to be
incorrect. I'll get that fixed.
b) Prior to CSCee30718 there was a hard limit of 255. After that
Steven Saner wrote:
What is not yet clear is, what are the definitions of Old IOS release
and New IOS release? There has been talk of a bug referred to as
CSCdr54230. I have seen statements on another list that this was fixed
in 12.1(4) and 12.0(10)S3, but yet this problem was experienced on
On Tue, 17 Feb 2009, Mike Lewinski wrote:
German Martinez wrote:
bgp max-as will NOT protect you from this exploit (but if you are not
vulnerable it should prevent you from propogating it).
I can confirm this statement...
(unfortunately)
L.
On Tue Feb 17, 2009, Rodney Dunn wrote:
Hello Rodney,
It will be great if you can share with us your findings. It seems
like we are hitting different bugs in different platforms.
Thanks
German
Ivan,
It is confusing but from what I have tested you have it correct.
The confusing part
If you want to take this offline send it unicast or we could
move it to cisco-nsp.
What scenarios are you seeing that appear broken other than
when a notification is sent when a 255 hop update is received?
That's the one I'm working on right now.
Rodney
On Tue, Feb 17, 2009 at 05:31:49PM
I am seeing them from 39625 and 47868.
-Matt
I'm seeing it too
Feb 16 16:44:36.065 GMT: BGP: x.x.x.x Bad attributes
Feb 16 16:45:43.389 GMT: %BGP-6-ASPATH: Long AS path 6461 1299 29113 47868
47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868
47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868
47868
500
John van Oppen
Spectrum Networks LLC
Direct: 206.973.8302
Main: 206.973.8300
Website: http://spectrumnetworks.us
-Original Message-
From: Matt Liotta [mailto:mlio...@r337.com]
Sent: Monday, February 16, 2009 8:55 AM
To: nanog@nanog.org
Subject: anyone else seeing very long
Hi,
Yep, we see them too. Nasty because there are lots of networks
flapping as the long as-paths are tickling old bug CSCdr54230, so even
networks not affected by the bug will be getting lots of extra updates.
Anyone with contacts at 47868 ? Any upstreams onlist that want to bin
them
Sprint has already expunged 47868 from their offerings but Paetec nee
McLeod is still bouncing sessions to us. It is Monday, isn't it?
On Mon, Feb 16, 2009 at 11:10 AM, Andy Davidson a...@nosignal.org wrote:
Hi,
Yep, we see them too. Nasty because there are lots of networks flapping as
, 2009 9:10 AM
To: John van Oppen
Cc: Matt Liotta; nanog@nanog.org
Subject: Re: anyone else seeing very long AS paths?
Hi,
Yep, we see them too. Nasty because there are lots of networks
flapping as the long as-paths are tickling old bug CSCdr54230, so even
networks not affected by the bug
: Monday, February 16, 2009 9:10 AM
To: John van Oppen
Cc: Matt Liotta; nanog@nanog.org
Subject: Re: anyone else seeing very long AS paths?
Hi,
Yep, we see them too. Nasty because there are lots of networks
flapping as the long as-paths are tickling old bug CSCdr54230, so even
networks not affected
On Mon, 16 Feb 2009, John van Oppen wrote:
Yep we saw the same, every customer with old IOS had their sessions die
to us at the same time... That always makes for an interesting time
when watching the NMS system...
Is there a reason you don't use something like bgp maxas-limit NN on
your
bgp maxas-limit has a default value of 75 if you don't include it
explicitly in the config so in this case it wouldn't have made much of a
difference.
L.
On Mon, 16 Feb 2009, Jon Lewis wrote:
On Mon, 16 Feb 2009, John van Oppen wrote:
Yep we saw the same, every customer with old IOS had
Why do you say that? I counted 78 instances of 47868 in this long
as-path, and our maxas-limit settings did trigger and reject these.
On Mon, 16 Feb 2009, Leland E. Vandervort wrote:
bgp maxas-limit has a default value of 75 if you don't include it
explicitly in the config so in this case
On Mon, 16 Feb 2009, John van Oppen wrote:
I am also a bit leery of setting it much lower than the defaults due to
the possibility of filtering something my customers will care about...
I am not sure what the best strategy is but what really bit a couple of
our customers was their old IOSes
On Feb 16, 2009, at 12:57 PM, John van Oppen wrote:
I am also a bit leery of setting it much lower than the defaults due
to
the possibility of filtering something my customers will care about...
I am not sure what the best strategy is but what really bit a couple
of
our customers was their
http://www.cisco.com/en/US/docs/ios/12_2/iproute/command/reference/1rfbgp1.html#wp1254976
Defaults
The default value in Cisco IOS software for the number argument is 75.
On Mon, 16 Feb 2009, Jon Lewis wrote:
Why do you say that? I counted 78 instances of 47868 in this long
as-path, and
Hi,
Anyone onlist knows the similar command (bgp maxas-limit NN) on Foundry XMR
platform ?
regards,
---
Nuno Vieira
nfsi telecom, lda.
nuno.vie...@nfsi.pt
Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301
http://www.nfsi.pt/
- Jon Lewis jle...@lewis.org wrote:
On Mon, 16 Feb 2009, John
Anyone have an estimate as to when these long announcements began? Seems
like the first reports appeared just before noon, UTC-05.
We noticed a significant dip in Internet traffic to AS11579 for a few
minutes last night (19:00 UTC-05) which we've been trying to hunt down the
cause of. At
It hit my routers at 11:26:40, EST.
Michael
On Monday 16 February 2009 07:26:23 pm Adam Greene wrote:
Anyone have an estimate as to when these long announcements began? Seems
like the first reports appeared just before noon, UTC-05.
We noticed a significant dip in Internet traffic to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, Feb 16, 2009 at 8:51 PM, Michael Ulitskiy mulits...@acedsl.com
wrote:
It hit my routers at 11:26:40, EST.
Michael
On Monday 16 February 2009 07:26:23 pm Adam Greene wrote:
Anyone have an estimate as to when these long announcements
I encountered it yesterday from AS47868.
-Original Message-
From: Paul Ferguson [mailto:fergdawgs...@gmail.com]
Sent: Tuesday, February 17, 2009 01:02 PM
To: nanog@nanog.org
Subject: Re: anyone else seeing very long AS paths?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, Feb 16
On Mon, 16 Feb 2009, Jon Lewis wrote:
Is there a reason you don't use something like bgp maxas-limit NN on your
transit sessions?
I've been using maxas=50 for years now (see the 2005 thread:
http://www.atm.tut.fi/list-archive/nanog-2005/msg04753.html)
I also knew this would happen one day and
44 matches
Mail list logo
