Jared Mauch wrote: | I've heard arguments about the amount of cpu time | it takes to do both, but simply put: BGP is fundamentally rate-limited by virtue of running on TCP. If the receiving router or the underlying connectivity fabric is congested (slow CPU, busy or lossy network) then convergence time slows down. Also, if there is a burst of too much routing information to exchange, TCP and other mechanisms tend to smooth things out. A dramatic slow-down of convergence time is just fine if you can mitigate the effects of being unconverged (unreachability and forwarding loops, the latter of which is liable to be Bad). By contrast, IGPs are *not* fundamentally rate-limited -- retransmissions are not congestion avoiding in any IGP that I know of. So, routing information heading into a congested link or router adds to congestion, which can lead to congestion collapse (and possibly consequent re-routing, moving the problem to another point). Thus, the iBGP hack is good for you CPU-wise, since it slows down when your CPU is too busy. IS-IS and the overload bit are the only mechanism I can think of that is similar, and the overload bit is not exactly a graceful response to being (temporarily) busy. Finally, as a side-note, TCP also gives BGP the proper data-stream ordering and dramatically improves the odds that the receiving process will get exactly what was sent by the transmitting process across the network. Many IGPs have really bad behaviours in the presence of lost frames/packets, and some are very prone to processing corrupted data without realizing it's been corrupted. These behaviours can also lead to huge consumptions of CPU time. Now, design wise: | 1) If you put your backbone connected interfaces (loopbacks | serials, etc.. in your IGP [isis, ospf, whatever]) [and other good points] In other words, all you need to do is make sure that all the NEXT_HOP addresses your iBGP speakers know about are reachable with information gained independently from BGP. This means: the NEXT_HOP for any given route is directly connected, is statically configured, or is learned through another dynamic protocol. If you are clever in your address-allocation, you can have a single prefix per router, and set next-hop-self. This aggregates all the NEXT_HOP addresses on that box into one single prefix/address which its iBGP neighbours need to know how to reach. Sean.