This is the final lab in our BGP labs and this is also the last article in the BGP series. In this lab, we will be using BGP to implement different routing policies.

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:

  1. Configure BGP sessions between the following pairs of routers: (R1-R2), (R1-R3), (R2-R4), (R2-R5), (R3-R4), and (R4-R5). Ensure that each router receives all the other routers’ Loopback0 network subnets via BGP.
  2. Ensure that AS1 is not used as a transit AS.
  3. AS2 should forward traffic destined for the 10.10.20.0/24 network via the R2-R4 link. The R1-R3 link should be used if the R2-R4 fails. This configuration should be done within AS1.
  4. AS2 should forward traffic destined for the 10.10.10.0/24 network via the R1-R3 link. The R2-R4 link should be used as a backup link in case the primary link fails. This configuration should be done within AS2.
  5. Using communities, ensure that AS5 sets a local preference of 300 on the 10.10.10.0/24 route received from AS1.

Task 1: BGP Peering Sessions

As usual, the first task deals with BGP peering and route advertisement into BGP. The configuration on the routers is as follows:

R1

router bgp 1
 neighbor 192.168.12.2 remote-as 1
 neighbor 192.168.13.3 remote-as 2
 network 10.10.10.0 mask 255.255.255.0

R2

router bgp 1
 neighbor 192.168.12.1 remote-as 1
 neighbor 192.168.24.4 remote-as 2
 neighbor 192.168.25.5 remote-as 5
 network 10.10.20.0 mask 255.255.255.0

R3

router bgp 2
 neighbor 192.168.13.1 remote-as 1
 neighbor 192.168.34.4 remote-as 2
 network 10.10.30.0 mask 255.255.255.0

R4

router bgp 2
 neighbor 192.168.24.2 remote-as 1
 neighbor 192.168.34.3 remote-as 2
 neighbor 192.168.45.5 remote-as 5
 network 10.10.40.0 mask 255.255.255.0

R5

router bgp 5
 neighbor 192.168.25.2 remote-as 1
 neighbor 192.168.45.4 remote-as 2
 network 10.10.50.0 mask 255.255.255.0

After your configuration, you should confirm that each router receives the Lo0 network of all other routers. For example, I can check the BGP table of R1 to see that all the Lo0 networks are there:

Task 2: AS1 Not a Transit AS

With our current configuration, AS1 is acting as a transit AS for AS2 and AS5. This means that traffic destined to AS2 from AS5 (and vice versa) can use AS1 as its transit; e.g., if the link between R4 and R5 fails. We can confirm this by checking the BGP table of R5:

As you can see, AS2 routes are reachable via R2 (AS1) even though it is not the best path. To remedy this situation, we can configure the AS1 routers to send only routes that were originated within their own AS. The easiest way to identify these routes is through the use of the regular expression “^$”. You can refer to this article for more information on BGP regular expressions.

The configuration on R1 is as follows:

ip as-path access-list 1 permit ^$
!
route-map OUTBOUND_POLICY permit 10
 match as-path 1
!
router bgp 1 
 neighbor 192.168.13.3 route-map OUTBOUND_POLICY out

The configuration on R2 is similar except that the route map is applied to its two external neighbors as follows:

ip as-path access-list 1 permit ^$
!
route-map OUTBOUND_POLICY permit 10
 match as-path 1
!
router bgp 1 
 neighbor 192.168.24.4 route-map OUTBOUND_POLICY out
 neighbor 192.168.25.5 route-map OUTBOUND_POLICY out

After the configuration has taken effect (you may have to perform BGP soft reconfiguration), you will notice that the AS2 routes are no more reachable via AS1 in R5’s BGP table:

We can also check that the AS5 route is not reachable via AS1 in either R3 or R4:

Task 3: Influencing Routing Decisions

This task requires that a configuration done in AS1 should affect routing decisions in AS2. To influence the routing decision in other ASs, we can use the MED attribute. Currently, R3 is using R1 as its best path for the 10.10.20.0/24 route while R4 is using R2 as its own best path.

To ensure that AS2 sends traffic for the 10.10.20.0/24 route through the R2-R4 link, we can configure R1 to send a higher MED for that route. Since R2 will keep sending the default MED value for that route, which is 0 as seen in the output above, the R2-R4 link will be used as the primary link for that route.

Hint: Remember that MED is a metric, which means the lower the better.

The configuration to be done on R1 is as follows:

ip prefix-list 1 permit 10.10.20.0/24
!
route-map OUTBOUND_POLICY permit 5
 match ip address prefix-list 1
 set metric 50

In the above configuration, I edited the OUTBOUND_POLICY route map so that the 10.10.20.0/24 is set with a metric of 50.

Note: The sequence number (5) of this route map entry is important because it will be checked before the previous entry (seq 10) we configured in Task 2. If you use a higher sequence number of, say, 15, this entry will never be matched because the 10.10.20.0/24 route will be matched in the first entry of “^$”.

If we check the BGP tables of R3 and R4 now, we see that the R2-R4 link is the best path for the 10.10.20.0/24 route:

You may be wondering what will happen if the R2-R4 link fails; will R4 forward traffic destined to 10.10.20.0/24 via R5 or via the R1-R3 link? The answer is that the R1-R3 link will be used because, if the R2-R4 link fails, R4 will stop advertising the 10.10.20.0/24 network and R3 will start advertising that route to R4. Since the route received from R3 will have a shorter AS_PATH (“1”) than the one received from R5 (“5 1”), then R4 will use R3 as its best path.

Task 4: Implementing Routing Policies

This task is like a reverse of the previous task. To influence routing decisions in our own AS, we can use the local preference attribute. Currently, R3 is using R1 as its best path to reach the 10.10.10.0/24 route, while R4 is using R2 as its own best path.

We can configure R3 to set a higher local preference for the 10.10.10.0/24 route. Since local preference affects all routers within an AS, then the R1-R3 link will be used as the primary link for traffic to that destination.

The configuration on R3 is as follows:

access-list 100 permit ip host 10.10.10.0 host 255.255.255.0
!
route-map INBOUND_POLICY permit 10
 match ip address 100
 set local-preference 200
!
router bgp 2
 neighbor 192.168.13.1 route-map INBOUND_POLICY in

Notice the weird looking ACL I have used in this configuration instead of using a prefix-list. This type of ACL is used to match a route/prefix length specifically. When we check the BGP tables of R3 and R4 now, we see that our configuration achieves our desired goal:

Again, if the R1-R3 link fails, AS2 will use the R2-R4 link as backup.

Task 5: Communities

By using communities, we can also influence routing policies, but it has to be a coordinated effort between the ASs concerned. For this task, we can configure R2 to add a certain community on the 10.10.10.0/24 route advertised to R5; R5 then sets the local preference of routes received with the community configured by R2.

The configuration on R2 is as follows:

ip prefix-list 1 permit 10.10.10.0/24
!
ip bgp new-format
!
route-map OUTBOUND_POLICY_TO_R5 permit 10
 match ip address prefix-list 1
 set community 5:300
route-map OUTBOUND_POLICY_TO_R5 permit 20
 match as-path 1
!
router bgp 1
 neighbor 192.168.25.5 route-map OUTBOUND_POLICY_TO_R5 out
 neighbor 192.168.25.5 send-community

The configuration on R5 is as follows:

ip bgp new-format
!
ip community-list 1 permit 5:300
!
route-map INBOUND_POLICY_FROM_R2 permit 10
 match community 1
 set local-preference 300
route-map INBOUND_POLICY_FROM_R2 permit 20
!
router bgp 5
 neighbor 192.168.25.2 route-map INBOUND_POLICY_FROM_R2 in

Since you can only apply one route-map for a BGP neighbor in a particular direction, I had to configure another route map for R5 to replace the one we configured under Task 2. Sequence 10 of this route map achieves what we want for this task while Sequence 20 achieves Task 2. Remember that, by default, communities are not sent to BGP neighbors and that is why we need the neighbor send-community command.

On R5, I created a route map that matches the community value of 5:300 and sets a local preference of 300 to routes that have that community value. All other routes (Sequence 20) do not have any action on them. This route map is then applied to neighbor R2 in the inbound direction.

Before the configuration, this is the 10.10.10.0/24 route in R5’s BGP table:

After the configuration, this is what we have:

Summary

We have finally come to the end of this BGP series with this third lab. I hope you have found it insightful. I know I have learnt a lot from it. In this lab, we have configured various routing policies using regular expressions, MED, local preference and communities.

References and Further Reading