There are 2 ways BGP is used. Internal BGP or iBGP for short, and external BGP or eBGP. It's exactly the same protocol, but works in 2 different ways that complement each other. eBGP is what you use to exchange prefixes with other ASes. eBGP is also where you control your routing policy, by filtering and modifying the attributes of the route announcements that you receive and send. iBGP is used for distributing the routes you learnt from an eBGP speaking router to the other routers within your own AS. This is how BGP routes propagate through your AS. And also how routes learnt from one external AS can arrive at another router to be re-announced to another AS. So if you look at this diagram, you'll see that within a single AS you use iBGP alongside an interior gateway protocol, like OSPF and ISIS. And between ASes, you use eBGP only. Now this means that within your AS you have 2 protocols running. iBGP and your chosen IGP. And this gives you another way that you can use iBGP, you can use it to carry your customer routes within your AS and offload them from your IGP. Let me explain. If you're a service provider, you will have customers connected to access routers at the edge of your network. And each customer has block of IP addresses that needs to be routed to them. If those customers are single-homed, then you'll have a static route for the address space you've allocated to that customer, pointing at that customer's router. These static routes need to be learned by all the other routers in your network. If your network is small, maybe you've just been redistributing these routes into your IGP. And that does work, up to a point. The problem is when you get large. Your IGP won't scale for carrying many thousands of these routes, and it will become slower to converge or may fail completely. The solution is to keep your customer routes out of your IGP entirely, and distribute them via iBGP instead. You still have the static routes on the access routers, but you introduce those prefixes into iBGP. We'll talk about how you actually do that later. iBGP carries the prefix along with a "nexthop" attribute, which says which access router each customer is connected to. If you implement this fully, then your IGP only need carry the loopback addresses of your routers and nothing else. And iBGP will carry all the other routes for your network. Since BGP works with millions of routes, there are well over half a million routes in the internet at large now, it won't have any problem carrying all your customer routes. And this is indeed how large service providers work. When I first learned about this my immediate reaction was, well if iBGP is so great why do I even need an IGP in the first place? Couldn't I just run iBGP and nothing else? Well, it turns out that doesn't work. The reason is that BGP works at the level of autonomous systems, and it doesn't know anything about the internal topology within an AS. In BGP, one "hop" can take you straight from one router in your network to any other router in your network, without knowing anything about the routers in between or the path the packet has to take. In fact, if you wanted to use BGP for your internal topology you would have to put every router into it's own autonomous system, and that wouldn't make any sense at all. So there you have it. eBGP is for exchanging routes with other ASes and for applying routing policy. iBGP is for distributing BGP information to the routers within your own AS, and can also be used to carry your customer routes. And an interior gateway protocol, such as OSPF or ISIS, is still needed to determine the paths between the routers in your AS.
© Produced by Philip Smith and the Network Startup Resource Center, through the University of Oregon.
Attribution-NonCommercial 4.0 International (CC BY-NC 4.0)
This is a human-readable summary of (and not a substitute for) the license. Disclaimer. You are free to: Share — copy and redistribute the material in any medium or format Adapt — remix, transform, and build upon the material The licensor cannot revoke these freedoms as long as you follow the license terms. Under the following terms: Attribution — You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use. NonCommercial — You may not use the material for commercial purposes. No additional restrictions — You may not apply legal terms or technological measures that legally restrict others from doing anything the license permits.