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. 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. 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_note09186a0080094823.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 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? Thoughts? Curious if Juniper has the same issue. Thanks Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=57548&t=57548 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
