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.

rrg mailing list

Reply via email to