YEEHAW!! -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Howard C. Berkowitz Sent: Tuesday, December 11, 2001 12:41 PM To: [EMAIL PROTECTED] Subject: Re: Speeding up BGP convergance in Bootcamp lab 18 [7:28859]
>Nice... Nothing like taking cheap shots on someone that is sending to a >forum thats supposed to help you learn. > >I'll bet you can remember a time back when you didn't know everything >there is to know about BGP. > >Try adjusting the timers, soft neighbor reconfiguration. > >>>> "fwells12" 12/10/01 06:22PM >>> >Dude, your a senior network engineer? > >Doing a clear ip bgp * forces the neigbors to renegotiate their >relationship >and resend ALL the routes. > >I think they are probably talking about using the neighbor >soft-reconfiguration command. > > >----- Original Message ----- >From: "Phillip Estrada (EUS)" >To: "Antonio Marfil" ; > >Sent: Monday, December 10, 2001 3:51 PM >Subject: RE: Speeding up BGP convergance in Bootcamp lab 18 > > >> Dude, you're a senior network engineer? >> > > Clear ip bgp * Dude, Isn't as simple as it looks. Just as a start of knowing about some of the mechanisms being introduced, an excerpt from my upcoming book, Building Service Provider Networks, is below. I haven't read this specific scenario. I will make the point, however, that fast BGP reconvergence isn't necessarily a good thing, when weighed against Internet stability. Reconverging quickly to a failed net is futile. Enterprises and ISPs will have different perspectives on this. So the scenario may be artificial rather than real-world. BGP convergence itself is not that well-defined, and I'm actively involved in an IETF effort to formalize the definitions: http://www.ietf.org/internet-drafts/draft-ietf-bmwg-conterm-00.txt -------------- The next implementer approach was to have the router store the entire Adj-RIB-In, rather than only those routes in it that passed filtering criteria and went to the Loc-RIB. If the acceptance policy then changed, the information already was there to refilter. While this improvement avoided needing to do a full reconvergence, it was both memory and processor intensive. The next step was to negotiate a soft refresh between pairs of BGP speakers. When both routers advertise the route refresh capability, a speaker whose policies change can send a ROUTE REFRESH message to the neighbor. On receipt of that message, the neighbor will readvertise the appropriate Adj-RIB-Out, which the local speaker will refilter and send the surviving routes to its Loc-RIB. Figure 12: Route Refresh Even though soft refresh improved the situation, there was still the The Adj-RIB-In conceptually contains all BGP routes received on an interface. When the speaker at the other end is sending all, or a substantial part, of the global routing table, per-interface memory requirements can become quite large. A fairly straightforward workaround was to keep the Adj-RIB-In conceptual. As routes were received, acceptance policy rules were applied to them, and only those that "survived" the input policy were sent to the Loc-RIB. This seems a reasonable workaround -- until you change an acceptance policy rule. At that point, how do you know that one of the "rejected" routes would not pass the new policy, and belongs in the RIB? The first operational solution was to "bounce" the BGP session up and down, resulting in the neighbor resending its entire Adj-RIB-Out. Especially on slower links, this could take significant bandwidth and introduce a noticeable delay. If BGP rules were followed, all routes whose next hop was to the neighboring router were now invalid, and would have to be readvertised to all other neighbors, causing a cascading bandwidth and processing requirement on other routers, potentially across the entire Internet. real-world problem that the sender of the Adj-RIB-Out might very well send routes that would be filtered by the receiver, wasting bandwidth and receiver processing time. Outbound Route Filtering was a new way to deal with this problem. Outbound Route Filtering I have long maintained that BGP doesn't transmit policies, but sends the information on which policy decisions are made based on information configured into the router by element management. Outbound Route Filtering (ORF) has forced me to modify that position, giving a final (if qualified) victory to a long-running debate between me and Sue Hares, co-chair of the IDR working group that develops BGP. At the next IETF we attend, I owe her a drink. The idea of ORF is that it can be of mutual benefit to a pair of routers to exchange their acceptance policies, so a router about to send its Adj-RIB-Out can prefilter it, thus requiring only the bandwidth for the updates the receiver really will use. Figure 13: Outbound Route Refresh Several independent proposals have been made for the policies that can be exchanged, and there is an attempt in the IDR committee to come up with a unified proposal that contains the three filtering criteria suggested: o Prefix expression for NLRI o AS path expression o Community These are a subset of the policy options available on commercial routers, but cover the great majority of cases. Like soft refresh, ORF is an optional capability that must be advertised and agreed to between peer BGP speakers. Graceful Restart In the real world, things break. Operational experience has shown that the control plane of a router may crash, breaking all routing protocol sessions and stopping updates to the RIB, but the FIB and forwarding plane may remain operational. The BGP Graceful Restart capability takes an optimistic view of the FIB contents: that it is more useful to continue forwarding while the routing system recovers, accepting the possibility that some FIB entries may have become obsolete, than to stop forwarding altogether until routing works properly again. Graceful Restart capabilities also are being developed for ISIS and OSPF, and it is arguable that BGP Graceful Restart makes little sense if the BGP speaker does not also implement IGP Graceful Restart. When the IGP does support Graceful Restart, it is good practice for BGP to wait to begin to do route selection until the IGP converges. When the routing system on a highly connected router in the Internet's Default Free Zone (DFZ) fails, strict interpretation of current BGP practice can impact the Internet as a whole. Remember that when a BGP speaker loses connectivity to a route, it must withdraw the route and propagate the withdrawal to all peer speakers to whom it previously advertised the route. It may advertise a new route with a different next hop, but it must withdraw the failed route. The Graceful Restart capability provides a way to avoid a flood of withdrawals and announcements, on the assumption that the routing control subsystem can be restarted, and the router can keep forwarding while its BGP is reinitializing. Specifically, advertising this capability tells peer speakers that the router advertising the capability can retain its FIB during a BGP restart. It is not intended for use when the speaker explicitly terminates the session with a NOTIFICATION message. Optimism can be a great character trait in humans, but network engineers have to pay homage to Murphy's Law. For the graceful restart capability to be plausibly fault-tolerant, it must have safeguards against its optimism being unjustified. More deployment experience is needed to tell the optimal timer values, or possibly the need for other safeguards, to prevent excessive blackholing or route flapping. In the capabilities advertisement is a restart time, which is an estimate, in seconds, of the time it will take the BGP session to reinitialize after a restart. If the timer expires and the router that advertised the capability does not return, its peers can declare it down faster than they would by waiting for the BGP session to time out. One feature of this capability, which could be useful beyond the original intent of the graceful restart capability, is the End-of-RIB marker. The presence of this marker in an update indicates that all routes have been sent, and, if the interface has been batching any routes, full convergence can begin. Indeed, it has been recommended that as long as a BGP speaker can generate end-of-RIB, it can be useful that it advertise the Graceful Restart capability even if it cannot retain its FIB during a BGP restart. Figure 14: Advertising During Graceful Restart Once the receiving speaker receives the End of RIB marker from all peers who have indicated they are restarting, it can begin to run route selection on the received routes. Assume the situation in Figure 14, where Router cinnamon is restarting. Until it receives an end-of-RIB marker from all its peers for a given address family, it has not built its Loc-RIB and thus has no routes to advertise. After route selection, the FIB is updated and any previously marked stale data is removed. The reason stale data must be removed at this time is to avoid the effects of multiple restarts. One of the complexities of Graceful Restart is properly handling multiple restarts. The solution involves the Restarting Speaker marking its existing routes as stale. Stale routes are not treated differently from other routes in the forwarding process. A router with this capability optionally may include a stale route retention timer, and flush these routes if the timer expires. It must support a timer that can be configured as to how long to defer the start of route selection. > > >> >> >> -----Original Message----- >> From: Antonio Marfil [mailto:[EMAIL PROTECTED]] >> Sent: Monday, September 10, 2001 3:33 PM >> To: [EMAIL PROTECTED] >> Subject: Speeding up BGP convergance in Bootcamp lab 18 >> >> In lab 18, task 4, item 9: Is there any way to speed up >convergance? >> >> For example, r1 is dual homed to AS200 via r3 and r5. If I bring >down r3, >> then it takes a couple of minutes for r1 to switch all of it's BGP >routes >to >> r5. can i make this happen isntantly or at least in a couple of >seconds? >> -- >> >> Regards, >> >> Antonio Marfil >> Senior Network Engineer >> NetworX Corporation >> http://www.networxcorp.com >> -- Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=28872&t=28859 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
