In this Cisco CCNA training tutorial, you’ll learn about the need for BGP (the Border Gateway Protocol). Scroll down for the video and also text tutorial.
This is the 1st in a series of BGP tutorials.
Part 5: Cisco BGP for Enterprises
Why We Need BGP – The Border Gateway Protocol – Video Tutorial
This course has a great balance of in depth knowledge of networking principles as well as covering everything you need for the exam. One thing I really really appreciated was the labs. I like many others am a hands on learner. The labs is one of the biggest factors for me why I chose this course and provided the 5 star score.
Beyond the labs, Neil has done a great job with this course. I would highly recommend this course to anyone who wants to pass the CCNA exam.
IGP Interior Gateway Protocols in Service Provider networks
This might sound obvious, but Internet Service Providers do not have just one huge router that routes traffic between all their customers. They've got many routers which connect all of their different physical locations. Those routers provide connectivity for customer traffic and also for the service provider’s own internal traffic between their own internal departments.
Service providers therefore need to use an IGP (Interior Gateway Protocol) for the routing within their administrative domain. It's usually OSPF or IS-IS which is used. You might find both OSPF and IS-IS in use in different parts of the network in large networks.
Let's have a quick recap of how IGP's like OSPF and ISIS work because we're going to compare this to how BGP works later.
How IGPs work
In the example above the administrator enabled OSPF on router R1's interfaces. R1 then sends out link-local multicast hello messages looking for other OSPF routers that it can form an adjacency with.
In this example, R2 does not have OSPF enabled yet so it drops the OSPF hello packet from R1. As it's a link-local multicast, R2 does not forward it out other interfaces.
Then the administrator does enable OSPF on R2. R2 starts sending out multicast OSPF hello messages.
The message reaches R1 and R1 says, "Hey, I'm running OSPF too. Let's check that our settings match. (For example, these interfaces are both in the same area and the timers match.) Then we'll form an adjacency."
The adjacency is formed and then the routers exchange routes.
In our autonomous system (our administrative domain) we enable OSPF on all of our routers. This is what the service provider are doing in their network in our example. The OSPF adjacency is formed between R1 and R2 and they exchange routes. The same happens between R2 and R3, R3 and R4, R4 and R5, and R5 and R1. All of the routers form adjacencies with their neighbours. They all exchange routes with each other and pretty soon all of the routers know the routes to get to everywhere inside the network.
IGP's learn the IP subnets that are available within the autonomous system and calculate the best paths to those IP subnets. They do this based on the links between the individual physical routers. IGP's share information and make decisions - which is the best route - on a physical hop by physical hop basis. All of the routers in the IGP learn about all the best paths to get everywhere, physical router by physical router.
Service providers also need to maintain connectivity between their internal networks. In the example above, we've got New York up at the top left of the diagram, Washington beneath, Boston in the top right, and Philadelphia in the bottom right. In between those routers, the service provider has their core routers. They're running an IGP, OSPF or IS-IS, on all of those routers and all of the routers will learn the routes to everywhere else within the service provider network.
But the service provider doesn't just have its own internal traffic, it also needs to have customers so that it can make money. And those customers need public IP addresses to be able to communicate with each other.
Let's look at how public IP address allocation works next.
Internet IP Address Allocation
The allocation of public IP addresses follows a hierarchical model. At the top of the tree is IANA, the Internet Assigned Numbers Authority. They're responsible for global public IP address allocation. That then gets broken down into smaller regions. IANA delegates allocations of IP address blocks to Regional Internet Registries, RIRs. Each RIR allocates addresses for a different area of the world. For example, there's an RIR in North America and so on.
The RIR's then break down to another lower level. They divide their allocated address pools into smaller blocks again and delegate them to Internet Service Providers. These smaller blocks of addresses can also be delegated to another organisation, like a company, at that level if the company is big enough to have their own block.
Going down to the last level, Internet Service Providers can allocate addresses to customers. The company next door and your network at home are going to get their public IP addresses from an Internet Service Provider.
Connectivity between customers
The Internet Service Provider is shown in the middle of the diagram above. They're running their IGP inside their network.
Customer 1 shown on the left are a medium sized company. They're also running an IGP inside their network as well. They also want to have Internet connectivity so they connect to the Internet Service Provider.
Customer 2 on the right are a different company who also maintain their own IGP and want Internet connectivity.
Both customers have only one path out to the Internet, with the ISP as the next hop. Both customers configure a default static route pointing to the ISP. All internal traffic will be routed via their IGPs, and traffic destined to the Internet will match the default static routes.
At this point, the service provider knows the routes to all of their own internal networks. They also know the routes to the public IP addresses for their customers because they allocated those addresses. And the customers have default static routes pointing out to the Internet and IGP's for their own internal routes.
We have connectivity within all internal private networks (but not between the different private networks) and also between all of the public networks.
At this point we don't need BGP. IGPs are running inside the service provider and the customers, default static routes at the customers point out to the Internet, and everything works just fine.
But, we obviously don't just have one Internet Service Provider in the world. There are lots of Internet Service Providers. All of the different service providers have got their own customers and so that customers everywhere in the whole world can communicate with each other, the service providers need to have connectivity to each other. So the service providers peer with each other in Internet exchanges, which are big data centres that allow them to connect.
Service provider interconnectivity
In the example above Service Provider 1 have got their IGP and their customers. They connect to Service Provider 2, who've also got their IGP and their customers. Service Provider 2 is connecting to Service Provider 3 in our example. 1 is connected to 4, 4 is connected to 5, and 5 is connected to 3.
Note this topology is just an example. In the real world, it's not like the service providers always connect to each other in a ring like this. You're going to have multiple service providers connected to other multiple different service providers. We’re just using this topology because it's going to be helpful for the examples that you're going to see later.
IGP Scalability Issue
You saw before when we just had the one service provider that an IGP would work for everything. But we're going to run into a problem as the network grows and we've got multiple different service providers. IGP's such as OSPF and IS-IS are not designed to support routing on the Internet. It's not feasible to control routing for the entire planet on a physical hop by physical hop basis. We can't have every service provider knowing about all the different individual routers in the whole world - obviously that's not going to work! So a different model needs to be used. And that's where BGP, the Border Gateway Protocol, comes in.
The Border Gateway Protocol (BGP)
BGP is the only EGP (Exterior Gateway Protocol) currently in use and it controls routing on the Internet. There's lots of choices for an IGP within a company, like ERGIP, OSPF, et cetera. But for routing on the Internet, it's always BGP that is used. And with BGP, rather than sharing information and making decisions on a physical hop by physical hop (physical router by physical router) basis, BGP works on an AS by AS basis - Autonomous System by Autonomous System.
An Autonomous System is a portion of a large network, such as the Internet, which is under a single administrative control. So that AS could be the network of a service provider or it could be the network of a company. The point is that it is a single entity that is controlling the routing within that part of the network.
The term Autonomous System has also got another meaning. It's also used in EIGRP and BGP configurations to specify their scope. For EIGRP routers to form an adjacency with each other they have to be in the same EIGRP AS.
Our Interior Gateway Protocols are used to share routes within an AS. And the AS's have a single coherent interior routing plan and they present a consistent picture of what destinations are reachable through it. Within a company's or an organization's network, they’re going to be running an IGP and all of the routers in that IGP know how to get to all of the other networks within that network. So that's how an IGP works within an AS. But for routing between different AS's, that's where we're going to use BGP.
When we do use BGP, the service providers each have a unique BGP AS number. This is overlaid in the diagram above. Each of those different service providers, SP1 to SP5, have got an AS number. BGP is going to be aware of that AS number and it's going to use it for routing traffic between the different service providers. Find out more about BGP routing within Service Providers in the next post in this series!