Re: iBGP and convergence when failure happens [7:57255]
One clarification below. On Mon, 2002-11-11 at 21:51, The Long and Winding Road wrote: a couple of things - in line below bergenpeak wrote in message news:200211120028.AAA03239;groupstudy.com... Suppose I have several routers making up an iBGP mesh. Lets suppose I have two routers (R1 and R2) which are advertising the same set of networks: N1, N2, ... Nk. OSPF is running underneath BGP (assume area 0). All of the N networks are being advertised with a next-hop set to the respective loopback's from R1 and R2. Now consider some other BGP router in the network. It will have received a BGP announcement for each of N1, N2, .. Nk from R1 and R2. This third router will select one of the paths to N1, N2, etc. and insert it into the routing table. I'd expect to see something like: subnet next-hop --- --- N1 R1-lo0 N2 R1-lo0 ... ... Nk R1-lo0 R1-lo0 R2-lo0 Now, suppose R1 goes belly up. OSPF will quickly inform all other routers that R1 and its loopback no longer exist. I'm assuming that this will invalidate all the routes in the routing table which have R1-lo0 as next hop. This will therefore cause the removal of all occurences of routes to N1, N2, ... Nk from the routing table. The question is this: what event will trigger BGP to re-evaluate the routes it knows about and add in routes for N1, N2, ... Nk via R2-lo0? Will the removal of the N1 route from the routing table inform BGP to re-evaluate? Or will the BGP timers need to timeout and detect that R1 is dead before re-evaluating? detecting a link down, or dead timer expired. One other question-- does no sync in BGP have a role here or is that related only to determining when to advertise a route via eBGP? iBGP will not install a route into the BGP table unless it can verify reachability. I.e. unless there is a valid path to the advertiser in the routing table. This is synchronization. the no synch command allows BGP to bypass this validation step. in the case you mention, with full mesh, and full IGP connectivity, no sync is not not necessary. Just wanted to clarify a point that might be ambiguous to some. BGP, sync or otherwise, must verify reachability to the BGP Next-Hop of each path advertised prior to considering a path valid. This is normal BGP blackhole prevention. With sync, BGP must verify that the actual NLRI for advertised in the path are otherwise reachable. HTH Thanks Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=57284t=57255 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: iBGP and convergence when failure happens [7:57255]
Thanks. So the removal of a BGP route from the routing table will not cause the BGP process to be tickled to run and possibly re-insert a new route for N1, N2, .. Nk through R2? Does the no sync apply here? The book examples always mention no sync in conjunction with eBGP and sending advertisements. Here it's iBGP and when to re-evaluate putting routes into the routing table. It would seem that load balancing, if possible, might help. That is, if routes to N1 via R1 and R2 are both in the routing table, the loss of routes to R1 would cause those routes to be removed, but not prevent traffic from being forwarded to N1. So, besides the questions above, a few more: * Is it possible, in an iBGP configuration, to have BGP install multiple routes to the same destination? If so, how is this done so that loops do not ocurr in the hops towards R1 and R2? (That is, if each intermediate router randomly picks R1 or R2 as the target for N1, loops might develop) * I've never tried, but can I use local pref in iBGP to indicate a course level of load balancing by network prefix destination? I want to make sure that packet re-ordering is very unlikely and this seems like this would prevent the loop problem. It would seem this might provide prefix load balancing, but does not install two routes in the routing table for N1? The Long and Winding Road wrote: a couple of things - in line below bergenpeak wrote in message news:200211120028.AAA03239;groupstudy.com... Suppose I have several routers making up an iBGP mesh. Lets suppose I have two routers (R1 and R2) which are advertising the same set of networks: N1, N2, ... Nk. OSPF is running underneath BGP (assume area 0). All of the N networks are being advertised with a next-hop set to the respective loopback's from R1 and R2. Now consider some other BGP router in the network. It will have received a BGP announcement for each of N1, N2, .. Nk from R1 and R2. This third router will select one of the paths to N1, N2, etc. and insert it into the routing table. I'd expect to see something like: subnet next-hop --- --- N1 R1-lo0 N2 R1-lo0 ... ... Nk R1-lo0 R1-lo0 R2-lo0 Now, suppose R1 goes belly up. OSPF will quickly inform all other routers that R1 and its loopback no longer exist. I'm assuming that this will invalidate all the routes in the routing table which have R1-lo0 as next hop. This will therefore cause the removal of all occurences of routes to N1, N2, ... Nk from the routing table. The question is this: what event will trigger BGP to re-evaluate the routes it knows about and add in routes for N1, N2, ... Nk via R2-lo0? Will the removal of the N1 route from the routing table inform BGP to re-evaluate? Or will the BGP timers need to timeout and detect that R1 is dead before re-evaluating? detecting a link down, or dead timer expired. One other question-- does no sync in BGP have a role here or is that related only to determining when to advertise a route via eBGP? iBGP will not install a route into the BGP table unless it can verify reachability. I.e. unless there is a valid path to the advertiser in the routing table. This is synchronization. the no synch command allows BGP to bypass this validation step. in the case you mention, with full mesh, and full IGP connectivity, no sync is not not necessary. HTH Thanks Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=57286t=57255 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: iBGP and convergence when failure happens [7:57255]
bergenpeak wrote in message news:200211121340.NAA13803;groupstudy.com... Thanks. So the removal of a BGP route from the routing table will not cause the BGP process to be tickled to run and possibly re-insert a new route for N1, N2, .. Nk through R2? depends on how your are set up in the first place, nad the nature of the failure. I have been going through some BGP exercises, so I had my pod set up for some basic stuff when I saw your post. in the case you mention, with all routes contained in and advertised through OSPF, there are only two things that can happen - a directly connected OSPF neighbor goes down, in which case SPF is run again and relatively quickly order is re-established. BGP is not effected in this case ( you did say that the loopbacks were advertised in OSPF? ) because of recursive routing. the routing in the BGP table points to a loopback as the next hop. in the regular routing table, the route to the loopback points to another network ( directly connected ) and it is this next hop that changes when OSPF reconverges. BGP is fat and happy and doesn't know there was ever a problem. the other thing that can happen is that some distant network is down ( do a shut on the loopback or on some other link. OSPF might noty become aware of the change for the holddown time, but BGP could become aware sooner, because the keepalives fail. the n BGP would go into its routing, waiting for the dead time to expire, before removing the route from the bgp table. geez, I didn't realize how tired I am tonight. Hope I am not rambling too much. Does the no sync apply here? The book examples always mention no sync in conjunction with eBGP and sending advertisements. Here it's iBGP and when to re-evaluate putting routes into the routing table. the important thing is to be sure that the routes become part of the iBGP or the BGP process of the router on which they originate. eBGP will accept all routes from eBGP peers so long as the neighbor relationship is formed. on the other hand, an eBGP peer will not advertise a route unless it can verify there is a path to that route via it's IGP. hence the no sync option It would seem that load balancing, if possible, might help. That is, if routes to N1 via R1 and R2 are both in the routing table, the loss of routes to R1 would cause those routes to be removed, but not prevent traffic from being forwarded to N1. So, besides the questions above, a few more: * Is it possible, in an iBGP configuration, to have BGP install multiple routes to the same destination? If so, how is this done so that loops do not ocurr in the hops towards R1 and R2? (That is, if each intermediate router randomly picks R1 or R2 as the target for N1, loops might develop) * I've never tried, but can I use local pref in iBGP to indicate a course level of load balancing by network prefix destination? I want to make sure that packet re-ordering is very unlikely and this seems like this would prevent the loop problem. It would seem this might provide prefix load balancing, but does not install two routes in the routing table for N1? The Long and Winding Road wrote: a couple of things - in line below bergenpeak wrote in message news:200211120028.AAA03239;groupstudy.com... Suppose I have several routers making up an iBGP mesh. Lets suppose I have two routers (R1 and R2) which are advertising the same set of networks: N1, N2, ... Nk. OSPF is running underneath BGP (assume area 0). All of the N networks are being advertised with a next-hop set to the respective loopback's from R1 and R2. Now consider some other BGP router in the network. It will have received a BGP announcement for each of N1, N2, .. Nk from R1 and R2. This third router will select one of the paths to N1, N2, etc. and insert it into the routing table. I'd expect to see something like: subnet next-hop --- --- N1 R1-lo0 N2 R1-lo0 ... ... Nk R1-lo0 R1-lo0 R2-lo0 Now, suppose R1 goes belly up. OSPF will quickly inform all other routers that R1 and its loopback no longer exist. I'm assuming that this will invalidate all the routes in the routing table which have R1-lo0 as next hop. This will therefore cause the removal of all occurences of routes to N1, N2, ... Nk from the routing table. The question is this: what event will trigger BGP to re-evaluate the routes it knows about and add in routes for N1, N2, ... Nk via R2-lo0? Will the removal of the N1 route from the routing table inform BGP to re-evaluate? Or will the BGP timers need to timeout and detect that R1 is dead before re-evaluating? detecting a link down, or dead timer expired. One other question-- does no sync in BGP have a role here or is that
Re: iBGP and convergence when failure happens [7:57255]
a couple of things - in line below bergenpeak wrote in message news:200211120028.AAA03239;groupstudy.com... Suppose I have several routers making up an iBGP mesh. Lets suppose I have two routers (R1 and R2) which are advertising the same set of networks: N1, N2, ... Nk. OSPF is running underneath BGP (assume area 0). All of the N networks are being advertised with a next-hop set to the respective loopback's from R1 and R2. Now consider some other BGP router in the network. It will have received a BGP announcement for each of N1, N2, .. Nk from R1 and R2. This third router will select one of the paths to N1, N2, etc. and insert it into the routing table. I'd expect to see something like: subnet next-hop --- --- N1 R1-lo0 N2 R1-lo0 ... ... Nk R1-lo0 R1-lo0 R2-lo0 Now, suppose R1 goes belly up. OSPF will quickly inform all other routers that R1 and its loopback no longer exist. I'm assuming that this will invalidate all the routes in the routing table which have R1-lo0 as next hop. This will therefore cause the removal of all occurences of routes to N1, N2, ... Nk from the routing table. The question is this: what event will trigger BGP to re-evaluate the routes it knows about and add in routes for N1, N2, ... Nk via R2-lo0? Will the removal of the N1 route from the routing table inform BGP to re-evaluate? Or will the BGP timers need to timeout and detect that R1 is dead before re-evaluating? detecting a link down, or dead timer expired. One other question-- does no sync in BGP have a role here or is that related only to determining when to advertise a route via eBGP? iBGP will not install a route into the BGP table unless it can verify reachability. I.e. unless there is a valid path to the advertiser in the routing table. This is synchronization. the no synch command allows BGP to bypass this validation step. in the case you mention, with full mesh, and full IGP connectivity, no sync is not not necessary. HTH Thanks Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=57263t=57255 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
