Best practice for BGP session/ full routes for customer

Mon Jul 28 06:18:52 UTC 2014

On Thursday, July 17, 2014 12:24:45 PM Nick Hilliard wrote:

> there are other drawbacks too: the difference in
> convergence time between < 24k prefixes  and a full dfz
> is usually going to be large although I haven't tested
> this on an me3600x yet.

Not having to install the routes into FIB (even on software-
based platforms) makes a ton of difference.

Our testing when using this feature on the ME3600X has 
shown:

	1. The switch will download a full copy of the IPv6
	   table of 18,282 entries in 1 second. This is from
	   2x local route reflectors, so no latency.

	2. The switch will download a full copy of the IPv4
	   table of 499,437 entries in 3 minutes, 10
	   seconds. This is from 2x local route reflectors,
	   so no latency.

The IPv4 convergence was consuming between 12% - 30% CPU 
utilization during the table download. This was on the IPv4 
table, given its size. The IPv6 didn't bother the switch in 
any way.

The CPU on the ME3600X is a little slow; we've seen far 
better IPv4 BGP table download times on meatier CPU's, and 
the CSR1000v, which runs on servers that kick typical router 
CPU's into the stone age.

> Also these boxes only have 1G
> of memory might be a bit tight as the dfz increases. 
> For sure, it's already not enough on a bunch of other
> vanilla ios platforms.

Total memory utilized (for 2x full BGPv4 and BGPv6 feeds, 
and after IOS deducts system memory for itself) came to 
370MB.

That left 424MB of memory free.

Code is 15.4(2)S.

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20140728/057b4ed5/attachment.sig>