Ben, I stand corrected sorry for the mistype.
you are right about using bgp as Exterior Gateway Protocol but I have used
IBGP internaly on my network in the past. You should be able to segment
your network into different AS's and do more fun stuff.
-Mohamed
Hm. How do your multiple border routers pass routes between themselves,
then? Is that not, by definition, an IGP? Simply because it doesn't have to
worry about which "random sized network that might or might not move" goes
where doesn't exclude the validity of it's IGP status. I don't know of any
other protocol that carries BGP data as an IGP (AS Path, MED's etc) in a
way suitable for re-export.
Moreover, many people do use it as their sole or predominant IGP,
particularly where convergance time because of failure isn't an issue and
adjacancies don't need to be built using an LSA model (ie, lack of
network or administrative complexity).
Chris.
instead of descending into a silly syntax discussion of whether ibgp is an
egp or an igp, perhaps the guy would like an answer to his question.
most large nsps use is-is, but usually only to carry the routes of the bgp
speaking interfaces.
randy
> I would say BGP is an exterior gateway protocol and using iBGP as an IGP is
> unwise. Much like posting to nanog when you have no clue.Hm. How do your multiple border routers pass routes between themselves,
then? Is that not, by definition, an IGP? Simply because it doesn't have to
worry about which "random sized network that might or might not move" goes
where doesn't exclude the validity of it's IGP status. I don't know of any
other protocol that carries BGP data as an IGP (AS Path, MED's etc) in a
way suitable for re-export.
perhaps i should have said "using iBGP as the only IGP" to avoid a flood
of pedantic replies. iBGP is, after all, by definition, not an external
protocol. it is also, like so many knobs to twist in engineering, not
for use in every situation. however, i don't really see that using iBGP
as your predominant IGP in a network of several hundred routers can
eliminate network or administrative complexity (as claiming a "lack" of
such things implies). and if your network is smaller than that, why not
just use a routing protocol designed for the task?
just because BGP is your hammer doesn't mean every problem is a nail.
ben
it probably depends on what you mean by "large". If you mean "the 5 largest"
then yes, most use ISIS (but not all). If you mean the 50 largest, then
OSPF becomes much more prominent (that is, hardly anyone but the largest
ISPs use ISIS, at least from my discussions with dozens at my previous
and current employer).
dave
Ben Black wrote (on Oct 12):
perhaps i should have said "using iBGP as the only IGP" to avoid a flood
of pedantic replies.
Without wanting to descend into a spiralling thread on this... It is
perfectly acceptable to run iBGP as the sole IGP simply because in
some situations there is not enouigh scope to run a more dynamic IGP
of any other nature. One routing protocol uses less CPU/memory than two.
Just because BGP is your hammer doesn't mean every problem is a nail.
All BGP isn't good at is metrics. It makes it a very clumsy IGP, but
useful in small-scale situations, like upto one or two site networks.
But since I'm apparently off-topic. 
I would agree with a previous
poster that the majority of reasonably sized networks these days use
OSPF as the IGP for both internal routes and, notably, next hops for use
by BGP (in either Internal or External contexts). This is what we do.
However, I know of three large networks in Europe that do use BGP as their
sole IGP and I know of one other that is considering ditching OSPF and
moving to BGP (they have bandwidth coming our of their ears so don't care
about the granularity cost-metric gives you) because the CPU overhead of
OSPF was too large for their network. Plenty of bandwidth but tight
purse strings when it comes to hardware.
Chris.
However, I know of three large networks in Europe that do use BGP as their
sole IGP and I know of one other that is considering ditching OSPF and
moving to BGP (they have bandwidth coming our of their ears so don't care
about the granularity cost-metric gives you) because the CPU overhead of
OSPF was too large for their network. Plenty of bandwidth but tight
purse strings when it comes to hardware.
If BGP rides on TCP, how are the TCP sessions built if BGP itself is used
as the IGP?
How does this affect the hierarchy of the network since all iBGP speakers
must be fully meshed?
Paul G. Donner wrote (on Oct 13):
If BGP rides on TCP, how are the TCP sessions built if BGP itself is used
as the IGP?
Same way as it does when you take next-hops from any other IGP. The fact
that one already has a route to ones' directly attached networks.
When you speak to a router that is directly attached and has BGP speaking
routers beyond it, it learns the networks of the interfaces attached to that
router. It then knows how to reach the networks directly behind it, connects
to the BGP speakers on those networks and so forth.
If you can't speak to a BGP router, you time out and try again later, when
perhaps you have learnt a route to it via other means.
With OSPF it builds up this information at startup from it's neighbours,
all of which keep a complete map of the network, all of which must be
learnt, the only difference is the mechanism is more propogatative than
discoverish. You can frig this of course by using BGP reflectors.
How does this affect the hierarchy of the network since all iBGP speakers
must be fully meshed?
iBGP doesn't need to be fully meshed to work, even without reflection. The
results are perfectly predictable. A machine that only needs to know
internal routes doesn't need to speak to any transit routers, for instance.
And in any case, the results are no worse than in the "my network died
and is booting up slowly" situation when you're running any other IGP. It
takes just as long for everything to converge.
Chris.
If BGP rides on TCP, how are the TCP sessions built if BGP itself is
used
as the IGP?
This question should come after the next one.
How does this affect the hierarchy of the network since all iBGP
speakers
must be fully meshed?
You're assuming not only that it has to be fully meshed, but that each
router does not have a single hop distance to every other router.
You don't *have* to fully mesh it. You can use confederations, or you
can use route reflection. Or both, or some other method I didn't
think of.
Or, and this is more likely case, if you only have a few routers, and
each has a direct link to every other one, (Very likely with 2 or 3
routers), you can make a full mesh without problems.
As our network grew here, we used these methods to avoid an IGP until
we needed it. (Right now, we're using OSPF, if you're curious.)