just a comment or two below -- TANSTAAFL "there ain't no such thing as a free lunch"
""p b"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > I had posted earlier in the week regarding some questions about > iBGP, the routing table, and convergence. Have some more > information and some more detailed questions. > > In terms of the design, the network consists of many routers > all running iBGP in a direct mesh or through route reflectors. > OSPF runs under these routers and just carries loopbacks and p2p > networks. All iBGP route next-hops are use the router's > loopback. > > Now, consider three iBGP routers in this network: R1, R2, and E. > R1 and R2 advertise the same set of networks: N1, N2 and N3 via > iBGP. OSPF advertises R1 and R2's loopbacks and p2p networks. > E is a router on the other side of the network from R1 and R2. > > In normal operating mode, one will find the following in router > E's routing table: > > N1 -> R1_lo0 (via iBGP) > N2 -> R1_lo0 (via iBGP) > N3 -> R1_lo0 (via iBGP) > R1_lo0 -> e0 (via OSPF) > R2_lo0 -> e0 (via OSPF) > > This is as one would expect. > > Now, assume R1 goes down. OSPF quickly informs all networks > that R1 has gone away, including it's loopback. Interestingly > when I do a show ip route on E1, I see the following: > > N1 -> R1_lo0 (via BGP) > N2 -> R1_lo0 (via BGP) > N3 -> R1_lo0 (via BGP) > R2_lo0 -> e0 (via OSPF) > > Notice that R1_lo0 is no longer a prefix that E knows how to > get to. However, the iBGP next-hops continue to reference > R1_lo0 as a next hop. These routes remain in E until BGP > figures out, via BGP timers, that R1 has gone away. > > So, now the questions. > > 1) I *assumed* that the routing table process, once removing the > R1_lo0 route, would have also removed any routes dependent on > R1_lo0. This doesn't seem to be the case. CL: sure. routes placed into the routing table are subject to the rules of the protocol that places them there. I'm not clear on how R1 is "disappearing". I presume you are either unplugging it, or doing interface shutdowns. OSPF detects a directly connected interface shutdown almost immediately, and goes into its routine. Suppose instead you were to issue a "shutdown" on the R1 loopback. I "believe" that in this case, OSPF would go through its hold time process before reconfiguring. >Apparently, the route > table process waits for BGP to attempt to re-insert its routes > and only at that time does the route table remove the BGP routes > dependent on R1_lo0. This seems somewhat improper behavior. CL: why so? there are hold times to protect against flapping routes and short interruptions. this dates to the days when telco circuits might flake out momentarily. ( stop laughing. you all know as well as I do that telco networks are FAR more reliable today than they were 10 years ago. ) I'm not sure that instantaneous reconvergence is necessarily a Good Idea. > Note, this behavior is also verifiable using two static routes > pointing to two different next hops which are added/removed from > OSPF. > > 2) I boated around on the cisco web site and found the following > related URL (watch the wrap) > > http://www.cisco.com/en/US/tech/tk648/tk365/technologies_tech_note09186a0080 094823.shtml > > Now it mentions two ways for the routing table to be updated: > > * The routing protocol periodically attempts to re-insert it's > best routes into the routing table. This appears to be the > behavior being observed with BGP above. > > * The second approach is where the routing table tracks when a > routing protocol failed to get its route inserted into the > table. The routing protocol is notified when the prefered path > is removed from the route table and the routing protocol's > path is then re-attempted to be inserted. Now, this is not > exactly the configuration I have, but it's close. Instead > of being a route learned by two different protocols, I've got > two routes from the same protocol. I'd like the failed iBGP path > to be removed, iBGP notified, and then have it re-insert the path > to R2. Is there a way to cause this triggering event to the > same protocol to happen? > > 3) From what I can tell "no sync" or "sync" in the iBGP config > has no applicability here CL: sync / no sync applies only in that "sync" requires that the route exist in the local routing table prior to being placed into BGP. No sync bypasses this requirement. As an aside, I believe there was a thread on NANOG not too long ago suggesting that Cisco remove the "no synch" option because it is only applicable in the Cisco CCIE Lab. >as the problem above is not related > to the advertising of routes, but rather, it's around having > BGP re-attempt to insert an updated best-path. Is there a way > to tune the timers on how often BGP attempts to *insert* it's > routes into the routing table? CL: as near as I can tell, BGP timers can be adjusted, but they only relate to neighbor connections, not to routes. > > Thoughts? > > Curious if Juniper has the same issue. CL: that's a PVO or an NRF question, and I'm sure one or the other will chime in. I would speculate that Juniper would make decisions based on the same concerns about routing table stability and / or route flapping. > > Thanks Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=57556&t=57548 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
