North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: AT&T NYC
On Mon, 2 Sep 2002 [email protected] wrote: > > > > Has anybody mentioned the benefits of ISIS as an IGP to them. > > > > Link-state protocols are evil, and when they break, they *really* break. > > I still do not see a compeling argument for not using BGP as your IGP. Convergence time? > > Alex > > iBGP is only one half of an IGP. It is the "where to go" half. > You still need some other igp (isis, ospf, rip, static routes, etc) for > the "how to get there" half. > > Most large providers carry next-hops (loopbacks, border /30 (or /31), etc) > around in either isis or ospf, and carry the remainder in iBGP. > > The reason? > > With link-state, one interface flap can mean doing SPF on every route. > If "every route" is only a couple hundred, rather than 100K, you fare As you say disable synchronization and try and control the physical reach of your igp by some mechanism.. areas, summaries, ASes etc Steve > better when circuits are flapping. At that point, comparing the precomputed > metric amongst 100k routes is (imho) rather trivial, especially when > "igp metric" is a few steps down the decision tree. > > In all practicality, you need to haul, at least, eBGP routes around in iBGP, > you need some kind of other igp to jumpstart iBGP, and is advised that this > other igp have some concept of metric or cost to be able to give BGP > some hints. Whether you choose to make your non-BGP igp lean and mean > (disabling synchronization, with the attendant caveats) or fat and happy > (and suffer the consequences during repeated link state changes), is up > to the reader, but you still really need two igps. > >
|