For over 13 articles in this series, we have been looking at different aspects of BGP. I have decided to end this series by configuring BGP labs using GNS3. These labs will incorporate many parts of BGP in one so that we are not configuring things in isolation.

In this first lab, we will be looking at general BGP peering sessions using the network diagram below:

The IP address table for the network is as shown below:

The initial configuration of these devices can be found in the GNS3 files using the link. This configuration already includes IP address configuration.

The tasks for this lab are as follows:

Note: The BGP Identifier for all routers should be the Loopback0 IP address of each router. All routers should advertise their Loopback1 network subnets into BGP. Use static routes for any routing configuration you need to make.

  1. Form a BGP session between R1 and R3 using their Loopback0 interfaces. Do NOT use the neighbor ebgp-multihop command.
  2. Form a BGP session between R1 and R2 using their physical interface IP addresses. External routes advertised by R1 to R2 should have R1’s IP address as the next hop. Do not update the next hop for external routes advertised by R2 to R1.
  3. Form a BGP session between R2 and R3 using their physical interface IP addresses.
  4. Form a BGP session between R2 and R4. Both links between R2 and R4 should be used for forwarding traffic (i.e. load-balancing).
  5. Test your configuration using ping. A router should be able to ping the other routers’ Loopback1 IP addresses from its own Loopback1 interface.

Task 1: BGP session between R1 and R3

Since R1 and R3 are in different ASs, then it means that we will be forming an EBGP session. The task specifies the use of the loopback0 interfaces to form BGP sessions, meaning we have to use the neighbor update-source command. There is also a requirement not to use the neighbor ebgp-multihop command, which gives us something to think about. The restriction on EBGP sessions is that the BGP neighbors must be directly connected (therefore TTL is set to 1); if they are not directly connected, then we can use the neighbor ebgp-multihop command to increase the TTL value in the BGP messages.

However, since R1 and R3 are directly connected, even though they will be forming a BGP session via their loopback interfaces, the TTL required between those interfaces is still only one. Therefore, we can use the neighbor disable-connected-check command in this case. You can refer to this article on multihop EBGP for more information.

Therefore the configuration on R1 is as follows:

router bgp 1
 bgp router-id 1.1.1.1
 neighbor 3.3.3.3 remote-as 3
 neighbor 3.3.3.3 update-source loopback0
 neighbor 3.3.3.3 disable-connected-check
 network 11.11.11.0 mask 255.255.255.0
!
ip route 3.3.3.3 255.255.255.255 192.168.13.3

Notice that I have also set the BGP router ID to 1.1.1.1 and advertised the loopback1 network subnet into BGP as required by the lab. I have also configured a static route for 3.3.3.3/32 pointing to R3. The configuration on R3 is similar as follows:

router bgp 3
 bgp router-id 3.3.3.3
 neighbor 1.1.1.1 remote-as 1
 neighbor 1.1.1.1 update-source loopback0
 neighbor 1.1.1.1 disable-connected-check
 network 33.33.33.0 mask 255.255.255.0
!
ip route 1.1.1.1 255.255.255.255 192.168.13.1

You should make a habit of verifying your configuration so let us check that our neighbors have formed the BGP session (you should also see it come up in your console):

Task 2: BGP session between R1 and R2

R1 and R2 are in the same AS so this is going to be an IBGP session. The task requires that R1 should update the next hop of external routes (routes from other ASs) advertised to R2. This tells us that we need to use the neighbor next-hop-self command. R2 will not be updating the next hop value, so we don’t need that command on R2.

The configuration on R1 is as follows:

router bgp 1
 neighbor 192.168.12.2 remote-as 1
 neighbor 192.168.12.2 next-hop-self

The configuration on R2 is as follows:

router bgp 1
 bgp router-id 2.2.2.2
 neighbor 192.168.12.1 remote-as 1
 network 22.22.22.0 mask 255.255.255.0

We can see the log on R2’s terminal that the BGP session was formed:

Task 3: BGP session between R2 and R3

R2 and R3 are in different ASs, so this will be another EBGP session. However, there is no direct link between R2 and R3 therefore we must make use of the neighbor ebgp-multihop command. Note that the neighbor disable-connected-check command will not work here because a TTL value of at least two is required between R2 and R3 (since R1 is in between).

The configuration on R2 is as follows:

router bgp 1
 neighbor 192.168.13.3 remote-as 3
 neighbor 192.168.13.3 ebgp-multihop 2
!
ip route 192.168.13.3 255.255.255.255 192.168.12.1

The configuration on R3 will be as follows:

router bgp 3
 neighbor 192.168.12.2 remote-as 1
 neighbor 192.168.12.2 ebgp-multihop 2
!
ip route 192.168.12.2 255.255.255.255 192.168.13.1

We can see that the BGP session was formed by the log message displayed on R3’s console:

Task 4: BGP session between R2 and R4

This particular task is quite interesting because there are two ways with which we can achieve it. The task requires us to form a BGP session between R2 and R4 (easy-peasy right?) but then it also requires that both links are used for forwarding traffic. The reason is because, by default, BGP will choose only one best path for the same route even if there are several equal-cost paths (i.e. in BGP, one path is always preferred over the others).

Method 1

Let’s look at the first method. The configuration on R2 is as follows:

router bgp 1
 neighbor 192.168.241.4 remote-as 4
 neighbor 192.168.242.4 remote-as 4

Notice that I have configured R4 as a neighbor using both links. The configuration on R4 is as follows:

router bgp 4
 bgp router-id 4.4.4.4
 neighbor 192.168.241.2 remote-as 1
 neighbor 192.168.242.2 remote-as 1
 network 44.44.44.0 mask 255.255.255.0

Following this configuration, if we look at the BGP table of R4 for the 22.22.22.0/24 route for example, we will see that although both paths (i.e. through 192.168.241.2 and through 192.168.242.2) are installed there, only one path is selected as the best path:

Furthermore, this is reflected in R4’s routing table that only one path (192.168.241.2) is being used:

To allow more paths other than the best path to be installed in the routing table, we can configure the maximum-paths command. You can read more about the BGP multipath feature here. So, I will just add the following command under both R2’s and R4’s BGP process:

maximum-paths 2

Doing this does not mean that one path is still not selected as the best; it just means that other non-best paths (up to the specified number between 1 and 6) can also be installed in the routing table.

Method 2

A problem with the above method is that you need to form two BGP sessions between the same neighbors, which cause waste of resources. A better method is to form the BGP session using loopback interfaces and then use routing (static or dynamic) to enable load balancing.

The configuration on R2 will be as follows:

router bgp 1
 no neighbor 192.168.241.4 remote-as 4
 no neighbor 192.168.242.4 remote-as 4
 no maximum-paths 2
 neighbor 4.4.4.4 remote-as 4
 neighbor 4.4.4.4 update-source Loopback0
 neighbor 4.4.4.4 disable-connected-check
!
ip route 4.4.4.4 255.255.255.255 192.168.241.4
ip route 4.4.4.4 255.255.255.255 192.168.242.4

Notice how I have configured two static routes for the 4.4.4.4/32 address. This way, even though the BGP session will form using the Loopback 0 interfaces, traffic will be load balanced across the FastEthernet links.

The configuration on R4 will be:

router bgp 4
 no neighbor 192.168.241.2 remote-as 1
 no neighbor 192.168.242.2 remote-as 1
 no maximum-paths 2
 neighbor 2.2.2.2 remote-as 1
 neighbor 2.2.2.2 update-source Loopback0
 neighbor 2.2.2.2 disable-connected-check
!
ip route 2.2.2.2 255.255.255.255 192.168.241.2
ip route 2.2.2.2 255.255.255.255 192.168.242.2

When we check the BGP table of R4 for the 22.22.22.0/24 route like we did before, we see only one path – through 2.2.2.2.

However, when we check the routing table, we see that route is reachable via 2.2.2.2, which is in turn reachable via 192.168.241.2 and 192.168.242.2.

Task 5: Verification

Let’s begin our verification from R1. I will ping 22.22.22.22, 33.33.33.33 and 44.44.44.44.

R1 cannot access the 44.44.44.0/24 network. If we check R1’s BGP table for that route, we find that it is “inaccessible.”

The problem lies in Task 2. The task specified that R2 should not update the next hop value for external routes advertised to R1 (the default behavior of IBGP). Therefore, R1 receives that route with a next hop of 4.4.4.4. The problem is that R1 does not know how to reach 4.4.4.4.

A simple static route on R1 will solve this problem.

ip route 4.4.4.4 255.255.255.255 192.168.12.2

As you can see, the ping is now successful. You can do the same test on the other routers and you will see that everything works as it should. You can also find the final configs for this lab in the GNS3 files.

Summary

In this article, we have configured our 1st BGP lab where we focused on BGP peering. I think we have covered most of the weird scenarios that you can get. We will have more of these labs so be sure to check them out.

References and further reading

  1. Load Sharing with BGP in Single and Multihomed Environments: Sample Configurations: http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13762-40.html