In this Cisco CCNA training tutorial, you will learn why an enterprise (rather than an Internet Service Provider) would use BGP and how to configure BGP from the enterprise point of view. Scroll down for the video and also text tutorial.
This is the 5th in a series of BGP tutorials.
Part 1: Why We Need BGP
Part 2: BGP Routing and Path Selection for Service Providers
Part 3: Configuring BGP Neighbors on Cisco Routers
Part 4: How to Advertise BGP Routes on Cisco Routers
Cisco BGP for Enterprises Tutorial Video
Max Kreis
I passed, Neil! Thank you so much. My new job is very pleased with my newly achieved CCNA as well. Couldn’t thank you more for your course and I really appreciate you answering all of my questions. You’re the man!
You learned about BGP from the point of view of a service provider in the previous posts in this series. You really need to look at BGP from that point of view to understand why we have BGP and how it works.
You don't need to know how to configure BGP in a service provider environment for the CCNA exam though. That's covered in the CCNA Service Provider certification, not CCNA Routing and Switching. What you need to know is how to configure BGP from the enterprise point of view - the service provider's customer.
Very often a site will use static default routes pointing to the Internet rather than BGP. I'll explain why an enterprise would use BGP in this post and how to configure it.
As you saw earlier in this series, ISPs (internet service providers) connect to other ISPs and use BGP for internet routing between them. BGP is how routing works on the internet. An enterprise location that is connected into an ISP can however use either static routes or BGP for their internet connectivity.
If you enable BGP at the enterprise it increases the load on the routers, they have to do more work. It also increases the load on the administrators that are looking after those routers because it is more complicated to configure BGP than it is to use static routes.
Continuing with the same topology from earlier in this series, we have five service providers and they have customers that are connected into them. Each customer is connected into a single service provider with a single link for internet connectivity.
Looking at it from the customer's point of view, they have only one path in and out for Internet traffic so there is no need to use anything more complicated than a default static route. In the example here, Customer 1 sets up a default static route pointing at the service provider:
ip route 0.0.0.0 0.0.0.0 203.0.113.1
From the service provider side, they need a route going to the customer. This can be in their IGP or, as in our example here, using a static route:
203.0.113.8 255.255.255.248 203.0.113.2
Using Redundancy to Safeguard Internet Connectivity - Redundant Links to Same Service Provider Router
You can see that when we have a single link from the customer to the provider, it is a very simple configuration. That topology will sometimes be acceptable for small offices but larger offices are probably going to want redundancy for their internet connectivity. They may have some mission-critical services for which it is really important that the internet is always up. Maybe it is just really important they've got internet access for browsing. Or maybe they have remote workers or remote offices that VPN in to the corporate site.
In this example topology, there is a single link between the customer and provider, so that single link is a single point of failure. We want to eliminate single points of failure. We can put in redundant links between the customer and the provider routers.
In the example topology above we have two links, 203.0.113.0 at the top and 203.0.113.4 on the bottom. On the customer side, we configure two default static routes. We configure one pointing to 203.0.113.1. Then we configure another default static route using other link, pointing to 203.0.113.5:
ip route 0.0.0.0 0.0.0.0 203.0.113.1
ip route 0.0.0.0 0.0.0.0 203.0.113.5
At the provider, we will have two routes for the customer's network of 203.0.113.8/29. One will point to 203.0.113.2 (the top link) and the other will point to 203.0.113.6 (the bottom link):
ip route 203.0.113.8 255.255.255.248 203.0.113.2
ip route 203.0.113.8 255.255.255.248 203.0.113.6
When we do this, all traffic to and from the customer travels via a single service provider (via a single AS), so there's no need to configure BGP. Default static route equal cost load balancing will spread the traffic equally over both links.
We have two routes that have exactly the same destination: 0.0.0.0. One is going to 203.0.113.1, the other one is going to 203.0.113.5. They are equal cost, so half the traffic will be going over each link. If a link fails, all traffic will go over the surviving link.
If a customer has two links going the same provider, this would be the recommended way to configure it: two default static routes.
Same Service Provider, Redundant Routers
Hopefully, it is obvious that we still have single points of failure. We have put in two links between the customer and the router, but they are on a single router on each side. If a router fails, we will lose access. So, the routers are also a single point of failure.
To fix the issue with the routers being single points of failure we install two routers at the customer and two routers at the provider. The configuration is going to be the same other than that. The difference is that rather than having two routes on the one router on either side, the routes will be split over two routers on each side.
Customer1A(config)# ip route 0.0.0.0 0.0.0.0 203.0.113.1
Customer1B(config)# ip route 0.0.0.0 0.0.0.0 203.0.113.5
Because the configuration and scenario are so similar, the result is going to be the same. All traffic to and from the customer travels via a single AS again, so there is still no need to configure BGP. The pair of default static routes will do equal cost load balancing across them - half the traffic will go over either link and if either link fails or any router fails, then traffic will go over the surviving link.
At this point we have eliminated all physical single points of failure for the connection between the customer and the provider. We have two routers at the customer, two routers at the provider, and two links between the customer and the provider, each connected to a different router.
So when would you use BGP?...
Different Service Providers, Redundant Routers
The service provider itself as a whole is a single point of failure. They could have a physical or operational issue which drops their connectivity to the rest of the Internet. In our previous example the customer has two connections, but they are both going through the same provider. If the provider goes down, then you have lost their internet access. That is a lot less likely than a physical link or a physical router failing, but it is still possible.
Because of this, some providers will offer redundant Internet connections with completely separate physical paths using no shared infrastructure. That removes single physical points of failure in their network... there still could be an operational failure though. The service provider could go bust or a rogue employee could bring their Internet connectivity down service provider wide. It's highly unlikely, but not impossible. Because of that, some companies prefer to be connected to two completely separate service providers with two separate physical connections to give them the best redundancy.
In this example Customer one in the bottom left of the diagram is connected to SP1 and also SP4. Now there is no single point of failure for that customer.
At this point the customer has the choice of either using default static routes again or BGP for their internet routing. The benefit of using static routes is that they are very easy to implement and support — it is the simplest way of doing it. We use the same configuration in the last example, the only difference is the service provider routers are in two different providers.
Customer1A(config)# ip route 0.0.0.0 0.0.0.0 203.0.113.65
Customer1B(config)# ip route 0.0.0.0 0.0.0.0 203.0.113.129
There is a drawback to this however. Look at the traffic going from Customer 1 to Customer 5. All traffic is going to be a load balanced over the top path via Service Provider 1 and over the bottom path via Service Provider 4. Half will take the top path and half will take the bottom path. Traffic that takes the bottom path is going through AS65004 and AS65005 (two ASs). When traffic goes over the top path, it is going to go through AS65001, AS65002, AS65003, and AS65005 (four ASs). So traffic is going to be quicker (as long as the paths have the same bandwidth) when it goes over the bottom path than when it goes over the top path. Using static routes has led to sub-optimal routing in this situation.
If the customer uses BGP instead the routers will learn the best paths (the shortest AS path everywhere) and achieve optimal routing.
Implementing BGP on the Customer Side
The customer should first acquire their own BGP AS number and provider independent public IP address space from the internet authorities (meaning the customer owns the IP addresses, they are not 'leased' from a service provider). The customer will act similarly to a service provider themselves as far as the Internet routing goes, just on a smaller scale and without their own customers.
Getting a provider independent public IP address space for IPv4 may be impossible because of the IPv4 address shortage, it will be easier with IPv6 addresses.
Using BGP makes optimal routing achievable. The drawback is that it is more complicated, so it puts more workload on you as the administrator. It also puts more work on the routers.
In our example Customer 1 in the bottom left corner has their own AS number of 65010 and their own range of provider independent public IP addresses 203.0.113.0/29. They are peering with both Service Provider 1 with AS65001 and Service Provider 4 with AS65004. They advertise their public IP address range of 203.0.113.0/29 with BGP to both providers.
eBGP needs to be configured from the customer AS to the provider AS on both of the customer routers. The two customer routers will have an iBGP relationship with each other as well. We use the 'neighbor' commands for the eBGP and iBGP relationships. Then we enter 'network' commands to advertise the customer public IP addresses out to the service providers:
R1(config)#router bgp 65010
R1(config-router)#neighbor 172.16.0.2 remote-as 65010
R1(config-router)#neighbor 203.0.113.129 remote-as 65001
R1(config-router)#network 203.0.113.0 mask 255.255.255.248
R2(config)#router bgp 65010
R2(config-router)#neighbor 172.16.0.1 remote-as 65010
R2(config-router)#neighbor 203.0.113.65 remote-as 65004
R2(config-router)#network 203.0.113.0 mask 255.255.255.248
Traffic coming in and going out will take the shortest AS path, so now we get optimal routing.
Use the same commands shown earlier in this series for verification:
“show ip bgp summary” to check that the BGP neighbors come up.
“show ip bgp” to check that the routes are making it into BGP as expected.
“show ip route” to check that the routes are actually making it into the final routing table and going to be used.
BPG Filtering
The global internet routing table is huge, there are over 600,000 IPv4 routes already and it is still growing. Having that many routes on the router would overwhelm many enterprise class routers. BGP filtering can be used to only advertise or only accept a subset of the entire Internet routing table. Customers may filter incoming routes in order to allow for optimal routing where it is most suitable and a default selection for everything else. This way they do not have too many routes in the routing table.
It is very common to do filtering with BGP, both on the customer side and the provider side. At the provider, they will typically implement filtering to prevent a customer from accidentally advertising the entire Internet as being available through themselves. Obviously, the customer wouldn't want to do that as it would lead to other enterprises using their connections and bandwidth when sending Internet traffic. To ensure this doesn't happen, the provider will have BGP filtering rules to say, “only accept routes from the customer that we would expect to be getting from them.”
That's BGP for enterprises and how to configure it. See you in the next post in this series where you'll see how BGP is used in MPLS networks.
Additional Resources
Making BGP Our Core Enterprise Routing Protocol | Network World
Best practices for enterprise IP routing | networkop
Text by John Rallison. Need your audio transcriptions or other work edited into stellar written English? Visit johnrallison.com