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

[Church, Charles]

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
>