A team of us have been drafting IETF documents for a generalized approach to single-router BGP convergence. The terminology document is about to go to the RFC editor after some final text formatting. The methodology document has technically expired--the economy hit the team, but we should be getting back to work. I'll see about posting the drafts, probably at certificationzone.com.
The bottom line is that a lot more factors go into even initial convergence than the number of routes, even simplifying to a single peer and no additional policy. Among other things, there will be variation based on the way a given implementation sends its updates (e.g., by order of prefix length, by order of IP address, randomly, etc.) and the particular prefix storage implementation of the receiving router. Another factor will be the number of prefixes packed into each update. Terminology draft: http://www.ietf.org/internet-drafts/draft-ietf-bmwg-conterm-04.txt At 1:08 AM +0000 6/22/03, Zsombor Papp wrote: >At 08:35 PM 6/21/2003 +0000, - jvd wrote: >>Hi Zsombor, >> >>The last time I checked BGP was a routing protocol, that means there is an >>algorithm running that's calculating the best path to a destination. A bunch >>of information is advertised to you and your router needs to decide which >>routes to put in the routing table based on the information in the BGP >tables. >> >>So of course you need a processor to do this. > >No doubt about that. :) Holding the routes however doesn't require any >processing. So I am thinking that the sheer number of routes impacts only >the initial convergence time, when the BGP session comes up. This appears >to be far less common than what comes after that, ie. calculating the >effects of continuous routing updates. So the rate of incoming routing >updates seems to be a more important parameter when trying to guesstimate >the CPU utilization. Due to the nature of the best path calculation, >probably the number of peers plays a role, too. I haven't seen these being >mention in the discussion so far, and I was wondering if I am missing >something here. Both the total number of peers and the rate of change at each peer affect convergence after changes. The number affects TCP performance, which is a processor hog. You also run into multiple cases of a change, such as: completely new route route withdrawn and existing less-preferred route now selected route withdrawn and new route learned from a different peer ..and so forth. When you start adding routing policies, the processor load can go up exponentially. > >I glanced through the document you referenced below, that also seems to >talk about memory issues only. > >You haven't answered my question as to how you know that the 1720 is not >fast enough but the 2691 is. Did you do any tests, or have you seen the >1720 fail in a live network due to too many BGP routes? > >Thanks, > >Zsombor > >>Have a look at: >>http://www.cisco.com/en/US/partner/tech/tk365/tk80/technologies_tech_n >>ote09186a0080094a83.shtml >>So of course you need a processor to do this. >> > >Regards, Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=71078&t=70960 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
