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 On Mon, 12 Oct 1998, Ben Black wrote:
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.
Ben
On Mon, Oct 12, 1998 at 04:14:10PM -0400, Megatron wrote:
I would say the most interior Routing Protocol that is out there is BGP. It gives a better control of route announcements.
-Megatron
On Mon, 12 Oct 1998, Andre' Zehl wrote:
Is there an overview on what the dominantly used interior routing protocols are percentagewise in large AS backbones (IBGP, OSPF, IGRP, EIGRP, IS-IS, any?). I don't want to start religous wars on what's the best protocol, I'm rather interested if there is an overview available on the facts of protocols used. Is there an "objective" (vendor-independent) feature-based overview on the compared advantages/disadvantages (especially regarding redistribution) of the various protocols that goes with those numbers?
Andre'
zehl@berkom.de
On Mon, 12 Oct 1998, Ben Black wrote:
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. 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. -- == chris@easynet.net, chrisy@flix.net, chrisy@flirble.org == Systems Manager for Easynet, part of Easynet Group PLC.
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
At 02:55 PM 10/12/98 -0700, Randy Bush wrote:
most large nsps use is-is, but usually only to carry the routes of the bgp speaking interfaces.
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
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.
Really?? Not that I desire to express any prejudices, but I honestly thought nobody used it. Does it just work better for very large networks? -Phil
On Tue, Oct 13, 1998 at 02:24:23PM -0400, Phillip Vandry wrote:
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.
Really?? Not that I desire to express any prejudices, but I honestly thought nobody used it.
Does it just work better for very large networks?
If properly deployed it works in smaller networks well also. I've heard arguments about the amount of cpu time it takes to do both, but simply put: 1) If you put your backbone connected interfaces (loopbacks serials, etc.. in your IGP [isis, ospf, whatever]) 2) Have a full iBGP mesh doing next-hop-self of the loopback interface 3) Redistribute statics and connected into your iBGP routing table (with route-map, or appropriate filters as necessary that vary by vendor) Once you've done this, shifting traffic is all about adjusting your igp metrics, and everything will be advert'ed appropriateley. If you are multiply connected to various NSPs, you can send them the same metrics from your igp in eBGP for the distance away, so they can make better decisions of where to hand you the traffic (unless they do hot potato) - jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net | http://puck.nether.net/~jared/
Jared,
1) If you put your backbone connected interfaces (loopbacks serials, etc.. in your IGP [isis, ospf, whatever]) 2) Have a full iBGP mesh doing next-hop-self of the loopback interface 3) Redistribute statics and connected into your iBGP routing table (with route-map, or appropriate filters as necessary that vary by vendor)
No argument with the principles here but why do you need to redistribute connected interfaces into your IGP *and* into iBGP? Overkill, surely? IMHO all you need do is put appropriate connected interfaces and statics pointing out of your core into either the IGP *or* iBGP. Whether you do this via redistribution or not is probably network dependent. In case anyone hadn't realized (I'm sure Jared did), (2) ensures you carry round the iBGP next hop of the loopback addres of the exit router rather than (say) the next hop over the NAP concerned, which some idiot is bound to leak a more specific of just when you've forgotten to filter it. This also removes the nead for carrying the DMZ in your IGP (or, I suppose iBGP). Are there really networks out there that chose to run iBGP not only as an IGP (we do this in one AS), but also don't run something to hold up the loopback interface mesh too? (i.e. use Chris' auto-discovery method). Presumably they peer between interface addresses or it's not going to work as nothing will ever discover an arbitrary /32 loopback. Euch! -- Alex Bligh GX Networks (formerly Xara Networks)
On Mon, Oct 12, 1998 at 10:42:00PM +0100, Chrisy Luke wrote:
On Mon, 12 Oct 1998, Ben Black wrote:
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
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. -- == chris@easynet.net, chrisy@flix.net, chrisy@flirble.org == Systems Manager for Easynet, part of Easynet Group PLC.
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. -- == chris@easynet.net, chrisy@flix.net, chrisy@flirble.org == Systems Manager for Easynet, part of Easynet Group PLC.
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. -- == chris@easynet.net, chrisy@flix.net, chrisy@flirble.org == Systems Manager for Easynet, part of Easynet Group PLC.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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.) -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.0 for non-commercial use <http://www.pgp.com> iQA/AwUBNiOYfGfkezbzToVaEQLNIgCg33nj1D8ZPEp8Wq4dOcqGLKxyX5YAnjAE hPeREC0BqrLLruAfhQQLI3sx =SsjW -----END PGP SIGNATURE-----
participants (10)
-
Alex Bligh -
Ben Black -
Chrisy Luke -
David O'Leary -
Jared Mauch -
Megatron -
Paul G. Donner -
Phillip Vandry -
Randy Bush -
Thom Youngblood