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.
