On Mon, Mar 15, 2010 at 6:04 PM, Tony Li <tony...@tony.li> wrote: > <employer hat off> > Any operator who would like to stand up and embarrass their favorite router > vendor by showing a graph of router boot convergence times is welcome to do > so. ;-) > </employer hat off>
eh, I don't have a hat nor a graph, but at a former employer we put a great deal of stress on 2 vendors to bring cold-boot times under 15minutes (cold-boot -> normalized/converged full table). As I understand things today at that employer, this time has been slowly increaseing again :( it makes sense, based on the prior conversation. Another point to keep in mind is that in the overall table let's say there is a 1% churn per time period (per second for grins). That the pathway from route-processor (or whatever the part that digests inbound bgp messages is called on your fav platform) to forwarding-bits (asics + tcam again whatever it is in your fav device) can only handle 10,000 changes in that same time period. If the table grows to beyond where 1% == 10k prefixes I don't think you can expect, under normal conditions, convergence to ever happen. Part of the RRG discussion gets back to 'can we sustain the current model where every butterfly flutter is felt by all devices', this is what the above is about. I don't think you'll be able to measure this in the live network until you reach these limitations. I'm CERTAIN Cisco/Juniper both have a graph that shows where their platforms start not-converging under bgp update-load. It's trivial to extend that to a constant X% of the table churning. Now, keep in mind that Geoff's numbers are for 'full internet routes' (DFZ routes perhaps even), not 'provider bgp table' which invariably will include internal deaggregates + other address families. -chris _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
