On May 15, 2011, at 12:48 PM, Nick Hilliard wrote: > if that happens, then your loopback will disappear in no more than dead-time > seconds, or possibly earlier if your igp notices that the interface carrier > drops. This will cause the ibgp next-hop will be become unreachable or else > to point by default to the nearest traffic sink on your network. Either > way, convergence time won't be hugely different if you compare ibgp+loopback > igp vs non-infrastructure igp prefix situations, because in both cases, all > you're doing is updating your fib with an igp-induced topology change. > > Some time after this, ibgp will notice that the edge device has disappeared, > at which point the non-infrastructure prefixes will disappear from ibgp.
I don't think that its the same and just depends on FIB operations, because when the iBGP next-hop disappears, BGP will notice that through BGP next-hop address tracking (can react quite fast on the IGP event) and then needs to run its path-decision process to install alternates. I believe that this takes more time than just running SPF, because its like two operations and not only one. If you have PIC support on your platform available then i would say that it should behave like you mentioned, (mostly). Imho BGP would pre-calculate in such a case a backup-route and the BGP path-decision process wouldn't be needed on next-hop change. Cheers Christian _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
