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 [email protected]
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
[email protected]
http://www.gtcomm.net
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
