[c-nsp] 3/11 (invalid or corrupt AS path)

Tue Feb 17 15:15:20 EST 2009

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/
> > 
> > 
> > 
> > 
> > 