[c-nsp] Invalid Formatted BGP update with AS prepending update
Rodney Dunn
rodunn at cisco.com
Thu Feb 19 15:06:36 EST 2009
Here is the bug that the fix will be provided under:
CSCsx73770
Invalid BGP formatted update causes peer reset with AS prepending
*Note: The title may show up as:
BGP peer resets when receiving update with > 255 AS hops
since I just changed it to be more accurate.
I just updaed the Release-note:
Cisco IOS device that receives a BGP update message and as a result of AS
prepending needs to send an update downstream that would have over 255 AS hops
will send an invalid formatted update. This update when received by a
downstream BGP speaker triggers a NOTIFICATION back to the sender which results
in the BGP session being reset.
<B>Conditions:</B>
This problem is seen when a Cisco IOS device receives a BGP update and
due to a combination of either inbound, outbound, or both AS prepending it
needs to send an update downstream that has more than 255 AS hops.
<B>Workaround:</B>
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 AS hops (10 on ingress, 10 on egress, and 1 for normal
eBGP AS hop addition). Therefore, a conservative value to configure would be
200 to prevent this condition.
On Tue, Feb 17, 2009 at 03:15:20PM -0500, Rodney Dunn wrote:
> Here is my update to NANOG...
>
> I'll post again once I have a further update.
>
>
> Date: Tue, 17 Feb 2009 15:11:57 -0500
> From: Rodney Dunn <rodunn at cisco.com>
> To: Ivan Pepelnjak <ip at ioshints.info>
> Subject: Re: anyone else seeing very long AS paths?
> Cc: nanog at nanog.org
>
> 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 fix
> AS sets of more than 255 should work.
>
> c) CSCeh13489 implemented the maxas command to mark it as invalid and
> not send.
>
>
> There does appear to be an issue when you cross the 255 boundary
> and the next hop router sends a notification back.
>
> I've got it recreated in the lab and we are working to clearly understand
> why that is. I'll post an update once we have more.
>
> The way to prevent it is the upstream device that crosses the 255 boundary
> on sending needs to use the maxas limit command to keep it less than 255.
>
> It doesn't work on the device that receives the update with the AS path
> larger than 255.
>
> Rodney
>
>
> -=-
>
>
>
> On Mon, Feb 16, 2009 at 03:32:11PM -0500, Rodney Dunn wrote:
> > We are working on that. I'll let you know once I have more.
> >
> > Rodney
> >
> > On Tue, Feb 17, 2009 at 12:41:34AM +0500, M Usman Ashraf wrote:
> > > Hi List,
> > >
> > > We have just experience the same problem on SRC but with a different reason,
> > >
> > > %BGP-3-NOTIFICATION: sent to neighbor X.X.X.X 3/11 (invalid or corrupt AS path)
> > > 518 bytes 50020202 02009531 23012306 71B9BAFC BA
> > >
> > > 23w4d: BGP: X.X.X.X Bad attributes
> > >
> > > Feb 16 21:26:04.918 pst: %BGP-4-MSGDUMP: unsupported or mal-formatted message
> > > received from X.X.X.X:
> > > FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 022C 0200 0002 1140 0101 0050 0202 0202
> > > 0095 3123 0123 0671 B9BA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA
> > > FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA
> > > FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA
> > > FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA
> > > FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA
> > > FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA
> > > FCBA--
> > >
> > > Any idea of reason? or what can be a bad message for BGP that can tear down
> > > adjacency ?
> > >
> > > Regards,
> > >
> > > M Usman Ashraf
> > >
> > >
> > >
> > > On Tue, Feb 17, 2009 at 12:07 AM, Rodney Dunn <rodunn at cisco.com> wrote:
> > >
> > > That would have to be *real* old code.
> > >
> > > That was fixed back in the 12.1(4)
> > >
> > > and 12.0(10)S3 days.
> > >
> > > On Mon, Feb 16, 2009 at 01:25:32PM -0500, Tim Donahue wrote:
> > > > Joe Provo wrote:
> > > > > On Mon, Feb 16, 2009 at 06:14:08PM +0100, Grzegorz Janoszka wrote:
> > > > >> Ozar wrote:
> > > > >>> I am starting to see random BGP neighbor messages from multiple
> > > neighbors
> > > > >>> on
> > > > >>> different boxes.
> > > > >>>
> > > > >>> %BGP-3-NOTIFICATION: received from neighbor X.X.X.X 3/11 (invalid or
> > > > >>> corrupt
> > > > >>> AS path) 516 bytes
> > > > > [snip]
> > > > >> No, it is not software error, it is extremly long as-path:
> > > > >
> > > > > The message itself, correct. The flapping sessions observed on some
> > > > > code, the long path is indeed triggering some bug. It is immaterial
> > > > > if it is the revival of an ld bug or a new one, there are folks
> > > > > flapping over this (and related) paths. Providers without some level
> > > > > of sanity filters (really need many-multiples the current diameter of
> > > > > the net?) should be shamed into limiting their customer's prepends.
> > > > >
> > > >
> > > > According to the NANOG thread on this, it would seem that the bug would
> > > > be CSCdr54230.
> > > >
> > > > Tim
> > > > _______________________________________________
> > > > cisco-nsp mailing list cisco-nsp at puck.nether.net
> > > > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > > > archive at http://puck.nether.net/pipermail/cisco-nsp/
> > > _______________________________________________
> > > cisco-nsp mailing list cisco-nsp at puck.nether.net
> > > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > > archive at http://puck.nether.net/pipermail/cisco-nsp/
> > >
> > >
> > >
> > >
> > >
More information about the cisco-nsp
mailing list