Running BGP on your Service Provider Network
In this scenario, you as a network consultant of service provider X is to configure a BGP on top of the OSPF in AS 500. You will have an ISP1 and ISP2 as your uplink and your task is to be a transit Autonomous System for the YMCA client. Create also BGP authentication with your client using its name as its password.
Let's use the diagram and the IP address assignment below:
Before we begin, let's tackle the basic concept behind BGP process on a service provider perspective.
What is a service provider? Service provider is a transit autonomous system consisting of a group of routers that is acting as a single autonomous system. It allows the connected enterprise network to forward its traffic to another autonomous system. Like in our diagram, AS 500 (Service provider) connects to another ISP (AS 1200 and AS 6590) which will provide the up-link connection to the internet. Service provider can also assume the role of assigning the IP address range to all of its client basing from its internal network address block.
There are 2 types of routing protocol. They are:
1. Internal Gateway Protocol (IGP)
2. External Gateway Protocol (EGP)
In order to forward the traffic, Service provider needs to run an IGP within its Autonomous System. OSPF, IS-IS, EIGRP, RIP are the basic examples of it.
On the other hand, EGP is the protocol for communicating with other Autonomous System. An example of EGP is a Bridge-Gateway Protocol (BGP) which is the only routing protocol used in the internet today.
BGP can be categorized as an Internal BGP (iBGP) and as an external BGP (eBGP).
By definition, iBGP is used to define the neighbor router within the same Autonomous System. While eBGP is used to define a neighbor router residing in a different Autonomous System.
Always put in mind that routes in BGP will only be advertised if and only if it comes from an eBGP but it will however stop the advertisement if the route will come from iBGP. To fairly distribute the BGP route, iBGP will provide a logical connection to other iBGP neighbors that doesn't have any physical connection with so as to obtain a full-mesh connectivity with its surrounding iBGP neighbors . This is a BGP split horizon rule that prevents the issue on looping.
Router eBGP neighbor relationship:
1. R1 and SPI
2. R2 and SP2
3. R4 and YMCA
Router iBGP neighbor relationship:
1. R1 neighbor: R2, R3, R4
2. R2 neighbor: R1, R3, R4
3. R3 neighbor: R1, R2, R4
4. R4 neighbor: R1, R2, R3
NOTE: Administrative distance of EBGP is 20 and 200 for iBGP.
Now let's dig in the configuration.
On our AS 500, we configured an IGP (OSPF) to advertise the internal network including the loopback interface.
Verify the ospf full neighbor relationship.
Verify the routes using the show ip route ospf. It should reflect the learned route as shown below:
You can now route and be able to ping the internal network and the loopback address from any of the routers inside the AS 500.
Now that your IGP is set, we start the configuration of the internal BGP. BGP will identify the neighbor if it is an internal or an external using the keyword remote-as. An iBGP should have the same value of remote-as as with the value of the created Autonomous System on the router itself. Otherwise, BGP will tag it as an eBGP.
For load balancing feature, we will going to source our routing updates on the loopback interface assigned to our routers using the keyword update-source loopback 0.
As a normal practice, description specific to the link should also be created for information purposes.
Now we will obtain a full-mesh connection for our iBGP configuration.
Router iBGP neighbor relationship:
1. R1 neighbor: R2, R3, R4
2. R2 neighbor: R1, R3, R4
3. R3 neighbor: R1, R2, R4
4. R4 neighbor: R1, R2, R3
Note: BGP will run on top of OSPF that forwards the traffic within the same Autonomous system.
Verify if the BGP neighbor relationship have formed using show ip bgp summary
Now our iBGP is fully configured and is running in a full-mesh relationship.
Let's now proceed with the configuration of the eBGP peering of ISP1, ISP2 and YMCA.
As you notice from our diagram, a redundant connection is needed for ISP1 and ISP2. In order to support redundancy, we have to use once again the loopback 0 as an external neighbor address and create a static route for from ISP1 to R1 and from R1 to ISP1. In this way we did not only attain redundancy but also gain advantage on the load balancing feature.
Now you should be able to do an ICMP on the loopback address from R1 to ISP1 and from ISP1 to R1.
Creating the eBGP neighbor from ISP1 and R1 is almost the same as the procedure being done in creating an iBGP neighbor, the only difference, since this is an eBGP, is the value of the remote-as which is different with the value of the BGP Autonomous system in ISP1 and versa.
We will use the keyword ebgp-multihop on the BGP process to allow connecting the eBGP of R1 and ISP1's loopback.
We should now see the neighbor relationship of R1 and ISP1 using show ip bgp summary
Note: Same procedures applies for the eBGP configuration on R2 and ISP2 and for the R4 and YMCA.
I will not show the eBGP configuration on R2 and ISP2 anymore since it is almost identical with the R1 and ISP1 procedure.
For the R4 and YMCA, you can see that it is also the same except that there is no load balancing.
To add security on the YMCA, we will create a BGP authentication between R4 and YMCA.
eBGP neighbor relationship should now form on R4 and YMCA.
Right now we were able to establish the eBGP neighbor relationship with the YMCA and BGP is now running on top of OSPF.
Advertising the network to your BGP using filtered redistribution
In this example, we are going to include an internal network using a loopback interface on ISP1. We then advertise only the internal network of ISP1 to the BGP topology using a filtered redistribution.
Internal network on ISP1:
100.100.10.0/24
100.100.20.0/24
100.100.30.0/24
100.100.40.0/24
100.100.50.0/24
By definition, filitered redistribution will advertise the network connected from the ISP1 to the BGP topology table with the conditional statement inside an access-list.
In order to do this, we need to initially create a standard ACL that will permit the 100.100.0.0/16 network. We will then create a route-map statement matching the standard ACL. Then finally we will include the created route-map in the redistribution command for the advertisement to the BGP topology.
Let's create a standard ACL.
Then we'll create the route-map and match our ACL statement.
Now that the ACL has been defined on the route-map, we can then apply it for BGP advertisement using the redistribution command.
Now ISP1 should now advertise the permitted network defined on the route-map into the BGP topology.
The advertisement of the network should reflect on the BGP Topology of the AS 500.
Is the BGP topology advertised? The answer is Yes but only to R1. Notice the *i on R2, R3 and R4? that is the problem right now wherein those routers doesn't know how to get to 10.10.10.10.
The route for 10.10.10.10 was only being learned by R1 using a static route. IGP (OSPF) doesn't know of this until we allow it to be advertisement using static redistributed command.
My approach to address this issue is to create a standard access-list on R1 and permit the 10.10.10.10/32. We'll then create a route-map and apply this access-list to be distributed.
Create the standard ACL to permit 10.10.10.10/32 then verify.
Create a route-map to match the standard ACL then verify.
Now let's distribute the static route by using the route-map command on OSPF process 1 using the keyword:
redistribute static route-map INCLUDE_LOOPBACK_RM metric 40 subnets
Note: You can put any value to the metric. Subnet is included so that it will not do any summarization.
The command should now advertise the static route defined on R1 to the OSPF internal routing.
BGP topology on reflecting on R2 R3 and R4 should now have a valid and best route.
Now the network coming from the ISP1 is now properly being advertised on the BGP topology table via OSPF.
Using the Autonomous system of the Service provider
As a service provider with a registered public autonomous system, you can hide the private AS of your client by allowing your AS to be their transit autonomous system.
On our current network topology, ISP1 right now is seeing the private AS path of the YMCA client.
As you can see, AS path shows the Private Autonomous System of the YMCA client. In order to remove this, you can issue a command remove-private-as on the service provider’s router connecting to the ISP1.
Now verify the removal of the private AS of the YMCA client using show ip bgp on ISP1.
This command will only hide the private AS of the YMCA client on the ISP1 but YMCA’s private AS will still be reflected inside the transit autonomous system.