[c-nsp] slow convergence for full bgp table on a Cisco7613/SUP720-3BXL

[Rodney Dunn]

Or get a sniffer trace and look at the session to see what's
happening.

It sounds like the TCP session is throttling back for some reason.

On Tue, Mar 13, 2007 at 09:43:42AM -0500, Church, Charles wrote:
> It's not carrier class equipment?  What is then?  You said you have one
> session with a full table, how many other sessions are there?  Are all
> your DFCs 3BXL and is the system as a whole running in 3BXL mode?  Any
> chance you're hitting a bug that only affects that 10 gig blade?  Is the
> other side of the link sending jumbo frames that you're not accepting on
> the new blade?  Can you try turning off control plane policing
> temporarily to see if that fixes it?  Just throwing some stuff out
> there...
> 
> 
> Chuck Church
> Multimax Network Engineer, CCIE #8776
> EDS Contractor, Multimax - Navy Marine Corps Intranet (NMCI)
> 1210 N. Parker Rd. | Greenville, SC 29609 
> Office: 864-335-9473 | Cell: 864-266-3978
> cchurch at multimax.com
> 
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Emanuel Popa
> Sent: Tuesday, March 13, 2007 10:21 AM
> To: Gert Doering
> Cc: Cisco Mailing list
> Subject: Re: [c-nsp] slow convergence for full bgp table on a
> Cisco7613/SUP720-3BXL
> 
> Hi Gert,
> 
> We have no packet loss on the 10GE interfaces. We are using
> control-plane policing but everything is configured properly. One of the
> upgrades has been made using old IP addresses, so no change had to be
> made in the access-lists used on the control plane.
> 
> I have attached an image with the cpu load graphs. The 5 min. averages
> look good. But the 5 sec. averages look pretty bad. It has been like
> this since we installed it and Cisco said it is not a carrier class
> equipment and it was not built to hold as many bgp sessions with as many
> prefixes. Also we are using control-plane policing. If we wouldn't use
> it the IGP neighbors would flap a lot. Also we are rate-limiting the TTL
> invalid packets because the traceroutes going through this machine were
> overloading the RP CPU.
> 
> Thanks,
> Emanuel
> 
> 
> On 3/13/07, Gert Doering <gert at greenie.muc.de> wrote:
> > Hi,
> >
> > On Tue, Mar 13, 2007 at 03:50:32PM +0200, Emanuel Popa wrote:
> > > we had 2 x GE links with our upstream and one BGP session with full 
> > > routing table on the loopback interfaces. everything was fine until 
> > > we needed an upgrade. so we upgraded from 2 x GE to 1 x 10GE. our 
> > > biggest issue is that our router needs around two hours to receive 
> > > the full bgp table over the new session. the old session takes a 
> > > maximum of five minutes to converge. the only difference is that one
> 
> > > session ends on a 6724-SFP linecard and the other session ends on a 
> > > 6704-10GE linecard. both of them have DFCs.
> >
> > Do you have packet loss on the new 10GE line?  Or do you happen to 
> > rate-limit (control plane policing) your BGP session?
> >
> > If you see high CPU load, which process is causing it ("show proc cpu
> sort")?
> >
> > Normally the type of line card should not have any effect on control 
> > plane traffic, i.e. BGP.
> >
> > gert
> > --
> > USENET is *not* the non-clickable part of WWW!
> >
> //www.muc.de/~gert/
> > Gert Doering - Munich, Germany
> gert at greenie.muc.de
> > fax: +49-89-35655025
> gert at net.informatik.tu-muenchen.de
> >
> 
> _______________________________________________
> 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/