This is our second BGP lab towards the completion of this BGP series. In the first lab, we dealt with general BGP peering sessions. In this lab, we will be looking at more advanced capabilities of BGP.
The network diagram for the lab is as shown below:
The IP address table for the network is as follows:
The initial configuration of these devices can be found in the “initial configs” folder inside the GNS3 files posted in the link above. The tasks for this lab are as follows:
Configure BGP sessions between the following pairs of routers: (R1-R2), (R1-R3), (R1-R4), (R1-R5) and (R4-R5). Ensure that each router receives all the other routers’ Loopback0 network subnets via BGP.
Advertise an aggregate route of 10.10.0.0/16 from both R1 and R4.
Using route aggregation manipulation techniques, ensure that AS5 sends traffic for the destinations 10.10.10.0/24, 10.10.20.0/24 and 10.10.10.30.0/24 through R1; traffic for the destination 10.10.40.0/24 should be sent through R4. In the case of the failure of either link, traffic should be sent through the other link.
After your aggregation configuration, make sure that each router still receives the Loopback0 network subnets of all other routers.
Task 1: BGP Peering Sessions
The first task requires us to configure BGP peering sessions between sets of routers and also advertise Loopback0 network subnets. The configuration for each router is as follows:
router bgp 1 neighbor 192.168.12.2 remote-as 1 neighbor 192.168.13.3 remote-as 1 neighbor 192.168.14.4 remote-as 1 neighbor 192.168.15.5 remote-as 5 network 10.10.10.0 mask 255.255.255.0
router bgp 1 neighbor 192.168.12.1 remote-as 1 network 10.10.20.0 mask 255.255.255.0
router bgp 1 neighbor 192.168.13.1 remote-as 1 network 10.10.30.0 mask 255.255.255.0
router bgp 1 neighbor 192.168.14.1 remote-as 1 neighbor 192.168.45.5 remote-as 5 network 10.10.40.0 mask 255.255.255.0
router bgp 5 neighbor 192.168.15.1 remote-as 1 neighbor 192.168.45.4 remote-as 1 network 172.16.50.0 mask 255.255.255.0
The task also specifies that each router should receive all other routers’ Lo0 network subnets. The problem is that, inside AS1, there is no full-mesh IBGP peering; e.g., there is no peering between R2 and R3. The rule that a BGP speaker should not advertise routes learned from an IBGP peer to other IBGP peers will prevent R1 from advertising R2’s Lo0 network to R3 and vice versa. This article on fully meshed IBGP gives more details about this. Therefore, if we check the BGP table of R2, we do not see R3’s and R4’s Lo0 networks.
One of the features we can used to solve this problem is route reflection. We can configure R1 as a route reflector with R2 and R3 as clients.
Note: You can also configure R4 as a client since it does not have any other IBGP peers.
We will add the following configuration on R1:
router bgp 1 bgp cluster-id 123 neighbor 192.168.12.2 route-reflector-client neighbor 192.168.13.3 route-reflector-client
Now when we check R2’s BGP table, we see that it receives all the Lo0 networks. Same thing applies to R3 and R4.
Task 2: Route Aggregation
Route aggregation in BGP is achieved using the aggregate-address command. The task does not specify if we should send only the aggregate route or the aggregate route with the more specific route. I will stick to configuring just the aggregate route without including the summary-only option. The configuration on R1 and R4 is as follows:
router bgp 1 aggregate-address 10.10.0.0 255.255.0.0
When we check the BGP table of R5, we will see that aggregate route there (it will also be in the BGP tables of all other routers).
Task 3: Route Aggregation Manipulation
Taking a look at R5’s BGP table above, we can see that it prefers R1 for most of the “10.10” routes even though it is receiving those routes from both R1 and R4. This task requires that traffic destined to 10.10.10.0/24, 10.10.20.0/24 and 10.10.30.0/24 from AS5 should be sent through R1, while traffic for 10.10.40.0/24 should be sent through R4.
There are several techniques we can use to accomplish a policy like this, such as setting MED values, but the task explicitly states “route aggregation manipulation techniques.” What we can do is configure R1 to send the 10.10.10.0/24, 10.10.20.0/24 and 10.10.30.0/24 networks along with the aggregate route while R4 sends only the 10.10.40.0/24 network, along with the aggregate route. This can be accomplished using suppress maps. You can refer to this article for more information on route aggregation and suppress maps.
The configuration on R1 is as follows:
ip prefix-list TO_BE_SUPPRESSED permit 10.10.40.0/24 ! route-map SUPPRESS permit 10 match ip address prefix-list TO_BE_SUPPRESSED ! router bgp 1 aggregate-address 10.10.0.0 255.255.0.0 suppress-map SUPPRESS
The configuration on R4 is follows:
ip prefix-list TO_BE_ADVERTISED per 10.10.40.0/24 ! route-map ALLOW deny 10 match ip address prefix-list TO_BE_ADVERTISED route-map ALLOW permit 20 ! router bgp 1 aggregate-address 10.10.0.0 255.255.0.0 suppress-map ALLOW
Notice how I used different logic for my suppress maps? For R1, since I wanted to suppress one route, I permitted it in the route map. For R4, since I wanted to suppress three routes and allow just one, I denied the one not to be suppressed in the router map and permitted every other one.
When we check the BGP table of R5, we see that our goal has been achieved:
The task also specifies that, in the event of failure of one of the links, e.g., R1-R5 or R4-R5, AS5 should use the other link to forward traffic. This is achieved with the aggregate route because, if the R1-R5 link goes down, for example, the aggregate route from R4 will be used to forward traffic to the 10.10.0.0/16 network.
Let’s simulate this. First, when the links are both up, R5 sends traffic for 10.10.30.0/24 through R1:
Now, I will shut down the link between R1 and R5. Notice that R5 does not have the routes through R1 in its BGP table any more:
However, since the aggregate route from R4 is still there, when we traceroute, the traffic goes through R4.
Task 4: Route Advertisement Checkup
By configuring route aggregation and using suppress maps, we have indirectly affected the routes received by R2 and R3. The BGP table of R2 is as shown below:
Notice that the 10.10.40.0/24 route is not there any more because R1 is suppressing that route. This is because route aggregation is not neighbor- or AS-specific—it is BGP wide. To remedy this situation, we can use what we call an unsuppress map. Unsuppress maps are neighbor-specific, so we can control which neighbors we want to selectively send suppressed routes to.
The configuration on R1 is as follows:
route-map UNSUPPRESS_ALL permit 10 ! router bgp 1 neighbor 192.168.12.2 unsuppress-map UNSUPPRESS_ALL neighbor 192.168.13.3 unsuppress-map UNSUPPRESS_ALL
I have configured a route map without any match statements, which basically means “match all” and then I have used that route map as an unsuppress map.
Hint: I could also have been specific and matched the 10.10.40.0/24 in the route map and still have gotten the same result.
Now when we look at the BGP table of R2, we see that the 10.10.40.0/24 route is back there:
In this article, we have configured the second BGP lab where we configured advanced capabilities of BGP, such as route reflection and route aggregation. In the final lab, we will be implementing different routing policies using BGP. I hope you have found this article useful.
References and Further Reading
Fully meshed IBGP: http://resources.intenseschool.com/bgp-fully-meshed-ibgp/
BGP Route Reflectors: http://resources.intenseschool.com/bgp-route-reflectors/
BGP Route Aggregation: http://resources.intenseschool.com/bgp-route-aggregation/