[c-nsp] bgp scalability C7600

Paul paul at gtcomm.net
Sat Feb 7 22:02:17 EST 2015


It's not as bad as everyone is saying. Have one with 6 full feeds (3 
million paths, 800k attribute entries).
As long as you are using relatively new code (such as SXJ on 6500), it's 
not too bad.  The 2 biggest problems is the hardware FIB update and 
RAM.  The platform runs out of RAM due to 1g limitation, and hardware 
FIB updates are very slow, especially the mcast to the DFCs.
All tests run with SXJ, Some examples:
Having 0 routes in the FIB, turning up a full (520k) internet BGP takes 
a while (10 minutes) due to FIB update mainly.
Once the FIB is updated, turning up another full session does not have 
to update the fib with every single route because the new routes coming 
in not ALL of them are the best path.  This takes ~ 5 minute.
Turning up a 3rd session which means even less routes will be bestpath, 
we can download the entire 520k in ~1-2 minutes.
Turning up a session and assigning it higher priority [like localpref 
900] to test forcing FIB update (meaning all will be best path) will 
take quite some time, 10-15 minutes.
Turning up several PE type sessions (meaning sending full routes to the 
customer but only taking ~1000 or less from them) and then doing a 
complete update will make it churn even longer.
Bottom line is, the more paths you have the longer it churns. The more 
FIB updates, the less CPU to process BGP (since it's a single core).  
The CPU is amazingly fast for when it was made, don't discount it. It's 
a sandcraft sr71000 cpu, 64 bit MIPS.

This should hopefully be reduced on the new code (see below).

The 15.1.x code seems to support (CEF output chain building)next-hop 
indirection and BGP-PIC.
Optimizations in BGP/CEF should at reduce churn a lot, still testing 
this though.....
However, this uses more resources which is quite the limiting factor on 
this platform aside from the CPU.

I am very curious to finish doing more tests on the 15.1.x code for this 
platform.   This is kind of like a hobby of mine now since we are mostly 
using these for PE now which works well.  I like to see how much I can 
push things before they break :)

They could extend the life of the platform by using some sort of memory 
compression or if someone would come up with a 2gb sdram sodimm that 
would actually work would be a serious money maker.

Additionally, the 7600 platform RSP720-3CXL can take 2GB/4G ram, while 
the SUP720 on 6500 is limited to 1G.

If anyone else has love for these platforms and likes to tinker around 
with them feel free to email me off list.  :D


On 2/6/2015 9:16 AM, james list wrote:
> Gents,
> do anybody have numbers in terms of BGP sessions scalability oin C7600
> SUP-720 ?
>
> greetings
> _______________________________________________
> 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/
>

-- 
GloboTech Communications
Phone: 1-514-907-0050 x 215
Toll Free: 1-(888)-GTCOMM1
Fax: 1-(514)-907-0750
paul at gtcomm.net
http://www.gtcomm.net



More information about the cisco-nsp mailing list