BGP vs IGP

trackit

Hi!

I have read a lot of times that BGP is for routing between different AS-s while IGP-s are for routing within an AS etc, but i have kinda hard time seeing the big picture how this all exactly fits together... So... Is it safe to say that basically, from practical viewpoint, BGP is for routing publicly routable address space while IGP-s are for private address space? I mean yeah, there are certainly some companies/institutions that have been allocated some bigger block of public addresses that they route with IGP internally etc, but basically, im i correct?

regards...

ColbyG

That's an odd correlation and I don't think it's accurate. Consider an enterprise who uses BGP on their private MPLS WAN, which is very, very common. That's RFC1918 space most of the time.

Usually IGP is used in places where you have full control and BGP is used when you're connecting to or traversing a network you don't control. Even that isn't completely accurate, but I think it's a bit better.

SteveO86

Sorta, although BGP can be used as a companies primary routing protocol it all depends on the circumstances.

BGP is just far more scale able and offers much more control over traffic flow, route advertising, and even route acceptance.

Just way BGP handles the routes it's capable of handling far more routes then an IGP, where-as an IGP would probably hang and become unstable BGP can handle it.

In the end it just comes down to the way BGP works.

Forsaken_GA

Well, for starters, BGP relies on IGP, whether you're using a routing protocol, or static routing. If the route isn't already in the table, BGP won't announce it.

In a traditional implementation, IGP is used in an administrative domain where you have full control of the routing. Every device, every hop, you can make the decision for.

BGP is for when you need to connect to others who aren't inside your administrative domain. You can still have end to end connectivity, but your control of that connectivity ends t your border.

Which if you think about it, is practical. I do not want route announcements from another company having any effect on my internal routing at all, which is what you'd have if two different entities did their interconnection through an IGP. A misconfiguration at Company B could seriously screw up Company A if they were interconnected through, say, OSPF, and someone at Company B screwed up.

So by seperating the routing domains, if Company A is peering with Company B via BGP, then Company B's screwup could certainly effect Company A, but it would be limited to traffic that was leaving Company A. Company B isn't likely to be able to screw with Company A's routing to the point where mail traffic would be delivered to Company B's Exchange server instead of Company A's, for example (this assumes the BGP administrator has taken basic precautions, like making sure Company B can't advertise RFC1918 space, or advertise Company A's own prefixes back to them, for example).

So IGP and EGP have very different functions.

Now, with that being said - BGP can and has been used in an IGP style within companies, and quite successfully. Given that BGP was designed to scale, for very large companies, or those with many sites, using BGP to transport routing data across the enterprise can be very advantageous. I know one company that, once they grew to a point where OSPF's requirements to connect back to area 0 became a very annoying prohibition, just converted all their sites to use BGP when transferring data between sites, and only used OSPF internally at a given site, and it has worked very well.

shodown

Forsaken_GA wrote: »

Now, with that being said - BGP can and has been used in an IGP style within companies, and quite successfully. Given that BGP was designed to scale, for very large companies, or those with many sites, using BGP to transport routing data across the enterprise can be very advantageous. I know one company that, once they grew to a point where OSPF's requirements to connect back to area 0 became a very annoying prohibition, just converted all their sites to use BGP when transferring data between sites, and only used OSPF internally at a given site, and it has worked very well.

Very interesting. I've worked on things like this before, and the decision was made to go to EIGRP instead of OSPF cause we could have several EIGRP AS, and Use BGP to Advertise the routes between Different AS'es since there were multiple paths out of each AS. There's always more than one way to skin a cat.

Forsaken_GA

shodown wrote: »

Very interesting. I've worked on things like this before, and the decision was made to go to EIGRP instead of OSPF cause we could have several EIGRP AS, and Use BGP to Advertise the routes between Different AS'es since there were multiple paths out of each AS. There's always more than one way to skin a cat.

Yup. Unfortunately, EIGRP is off the table when you have non-Cisco gear in the mix, which is why this particular company had to go OSPF. But it's essentially the same thing conceptually, instead of different EIGRP AS's, you just have many OSPF area 0's. I actually like EIGRP as a protocol. When EIGRP is properly designed to limit query range, it's a wonderful and simple protocol, but the vendor lockin requirement doesn't sit well with me.

trackit

First off, thanks for your reply's guys.

Forsaken_GA wrote: »

Well, for starters, BGP relies on IGP, whether you're using a routing protocol, or static routing. If the route isn't already in the table, BGP won't announce it.

In a traditional implementation, IGP is used in an administrative domain where you have full control of the routing. Every device, every hop, you can make the decision for.

BGP is for when you need to connect to others who aren't inside your administrative domain. You can still have end to end connectivity, but your control of that connectivity ends t your border.

This is what i have hard time understanding. How exactly IGP's and BGP play together. I know the synchronization rule and as far as i know its mostly turned off nowadays?

Lets say i am an ISP, i have my network and i have full administrative control over it. Correct me if im wrong, but i would be running BGP everywhere in my network (unless i have some MPLS etc), i wouldnt be redistributing BGP into some IGP in my administered network because IGP-s cant handle BGP table and would blow up. In other words, is there any common practice for ISP-s to redistribute BGP routes (by that i mean public address space) into IGP (in their networks where they have full control over every router every hop etc) and if not then is it safe to say that public address space is routed basically with BGP across the board?

Forsaken_GA

trackit wrote: »

This is what i have hard time understanding. How exactly IGP's and BGP play together. I know the synchronization rule and as far as i know its mostly turned off nowadays?

Basically how they play together is that BGP must have the route in the routing table from *some* source before it can advertise it to peers. Simple as that. The easiest way to get those routes in the table is via an IGP. This is not the same as the synchronization rule, it's just a basic fact of BGP.

Lets say i am an ISP, i have my network and i have full administrative control over it. Correct me if im wrong, but i would be running BGP everywhere in my network (unless i have some MPLS etc), i wouldnt be redistributing BGP into some IGP in my administered network because IGP-s cant handle BGP table and would blow up. In other words, is there any common practice for ISP-s to redistribute BGP routes (by that i mean public address space) into IGP (in their networks where they have full control over every router every hop etc) and if not then is it safe to say that public address space is routed basically with BGP across the board?

I think the part you're missing is that BGP doesn't require a direct connection between peers, especially not iBGP. You just need network reachability. Basically, I need to have a route to the next hop in my routing table before I can learn a prefix, but let's say you're an ISP and you have two border points, one in Atlanta, one in Los Angeles. You're only required to be running BGP in those two locations, your entire backbone doesn't necessarily need to be running BGP (this is one of the benefits of an MPLS network, a BGP free core), but for a normal ISP, yes, you'd be running BGP across the network on routers in the backbone path. iBGP for your internal connections to get the routes throughout the backbone, eBGP with the systems external to your system.

Your non-backbone routers don't need to have a full BGP table, they just need to route towards a backbone router that does have the full BGP table. The backbone routers will deliver the traffic to a border router, and the border router will egress it from the AS. You normally would not redistribute BGP into your IGP. There are resource issues, true, but there's also stability issues to consider. You don't want internal IGP changes to start flapping routes, which will also have an effect on the global BGP table. That's a good way to get depeered.

Your BGP routers will carry a full table, and your non-BGP routers will carry the IGP table that will either use summary routes, or a default route to go towards a backbone router.

trackit

Ahh ok, so as an ISP i would run IGP to route for my own network (with public address space) and establish BGP peerings with outside world... That makes sense... thanks!

Forsaken_GA

trackit wrote: »

Ahh ok, so as an ISP i would run IGP to route for my own network (with public address space) and establish BGP peerings with outside world... That makes sense... thanks!

Yes, your IGP tables are going to contain all of an ISP's personal prefixes,whether it's public space or not. For traffic that is bound for a system outside of the provider, the customer edge router sends that traffic up to a backbone router, and the backbone router sends it towards an exit point that can reach your desired destination. The border router at that exit point sends it into the new AS, and the same procedure happens again and again until it reaches the destination

For the reply traffic, it comes into the AS, and the border router sends it towards whatever backbone router is advertising the prefix for the source, and when it reaches that backbone router, it gets handed off from there to the internal routers and uses the IGP to get back to the source.

So you basically have two routing topologies, one for internal traffic, one for external traffic, and various interchange points. You can think of it alot like the american interstate system. The interstates are your BGP backbone, and the various exits off the interstate are handoffs to internal routers.

trackit

thanks, thats what i was missing