BGP LAB #3: Sessions, Next-hop-self and Local Preference

Topology:

Objectives:

  1. Research the concepts for “next-hop-self” and “Local-Preference” attributes and implement these in order for the IBGP Peers to correctly exchange routing information and provide redundancy.
  2. Ensure that the *preferred* link is used for sending and receiving data and that the *backup* link is only used in the event that the *preferred* one has failed.

Initial Configuration:

We will start by setting up IBGP between R2 and R3.
I will also configure IBGP on these two routers to use their loopback addresses to communicate instead of the physical ones. This can be done with the “update-source” keyword in the neighbour statement.

It’s good practice to use a loopback interface in this kind of configuration because a loopback can never go down on its own, unlike a physical interface.

R2(config)#router bgp 64512
R2(config-router)#neighbor 172.16.32.1 remote-as 64512
R2(config-router)#neighbor 172.16.32.1 update-source loopback 0

R3(config)#router bgp 64512
R3(config-router)#neighbor 172.16.64.1 remote-as 64512
R3(config-router)#neighbor 172.16.64.1 update-source loopback 0

I noticed that my neighbourships are not forming yet because I misconfigured EIGRP earlier.
The networks that the loopback interfaces are in are not being advertised so IBGP has no way to communicate between the two routers.

Note that BGP is a Transport Layer Protocol which sets up its sessions through TCP Port 179.

Here’s the correct EIGRP config which should be added to the overview above.

R3(config)#router eigrp 10
R3(config-router)#network 172.16.32.0 0.0.0.255

R2(config)#router eigrp 10
R2(config-router)#network 172.16.64.0 0.0.0.255

And now my neighbours wake up.

R2#
*Mar 1 00:59:58.755: %BGP-5-ADJCHANGE: neighbor 172.16.32.1 Up

R3#
*Mar 1 00:59:55.727: %BGP-5-ADJCHANGE: neighbor 172.16.64.1 Up

Looking at the output of “show ip bgp neighbours” we can see this neighbourship is being recognized as an internal link.

Now I will configure EBGP to run between the ISP router and R2/3. We will not be using the update-source keyword because there’s only one available WAN link between the ISP and both routers.

On the ISP Router;

ISP(config)#router bgp 200
ISP(config-router)#neighbor 192.168.1.6 remote-as 64512
ISP(config-router)#neighbor 192.168.1.2 remote-as 64512
ISP(config-router)#network 192.168.100.0

On R2;

R2(config)#ip route 172.16.0.0 255.255.0.0 null 0
R2(config)#router bgp 64512
R2(config-router)#neighbor 192.168.1.5 remote-as 200
R2(config-router)#network 172.16.0.0

A few notes on the above configuration of R2;

A static “null” or “black hole” route has been configured for the 172.16.0.0/16 network. This will cause all traffic not matched by the more specific routes to be dropped by this router. (As you know, more specific routes are always preferred over less specific ones) We can see this by looking at R2’s routing table.

Lets look at the output from “show ip bgp neighbors” on R2 to verify that the neighbourship is correctly up and running. This is giving me alot of output so I will only copy/paste the most interesting part for this section.

R2#sh ip bgp neighbors 192.168.1.5
BGP neighbor is 192.168.1.5, remote AS 200, external link
BGP version 4, remote router ID 192.168.100.1
BGP state = Established, up for 00:11:25

We can see that for our new neighbor, the neighbourship is Established and is recognized as an External Link. Good.

I’ll configure the same for R3 now.

R3#conf t
R3(config)#ip route 172.16.0.0 255.255.0.0 null 0
R3(config)#router bgp 64512
R3(config-router)#neighbor 192.168.1.1 remote-as 200
R3(config-router)#network 172.16.0.0

Another useful command to verify if the neighborships are up and running correctly is “show ip bgp summary

This is the output of the above command as seen on R3:

In this output we can see some useful information such as an overview of our neighbors and the router identifier along with its local AS number.

We will now run a test to see which path our traffic is currently taking. To make sure everything is up to date, I will clear the BGP process on the ISP router with the command “Clear ip bgp *” I do not advise you do this on a production router. There are less impacting ways to refresh your BGP setup which we will go into later on.

ISP#clear ip bgp *
ISP#
*Mar 1 00:20:57.055: %BGP-5-ADJCHANGE: neighbor 192.168.1.2 Down User reset
*Mar 1 00:20:57.059: %BGP-5-ADJCHANGE: neighbor 192.168.1.6 Down User reset
ISP#
*Mar 1 00:21:19.143: %BGP-5-ADJCHANGE: neighbor 192.168.1.2 Up
*Mar 1 00:21:19.155: %BGP-5-ADJCHANGE: neighbor 192.168.1.6 Up

You can see that both our neighbors go down because of a “User reset” and come back up again a bit later.

What I like about this is that there is no confirmation dialog for this potentially very destructive command, yet if you try to clear counters or the logging buffer, you are required to confirm.

But then again, you could make the argument that you are supposed to know what you are doing when working on a production router.

Let’s start pinging from the ISP router and see what kind of results we get:

ISP#ping 172.16.64.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.64.1, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)
ISP#ping 172.16.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.1, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)
ISP#ping 172.16.32.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.32.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/6/16 ms
ISP#ping 172.16.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/5/16 ms
ISP#

It seems our pings towards the ip addresses of R2 are failing. Let’s find out why.

I run the command “show ip bgp” on the ISP router. Here is the output:

Here we can see that, for the 172.16.0.0 network, there are two paths. The ISP router has chosen 192.168.1.2 as preferred path as indicated by the ‘>’.

As from the official Cisco Documentation:

BGP operates differently than all other protocols. Unlike other routing protocols that use complex algorithms involving factors such as bandwidth, delay, reliability, and load to formulate a metric, BGP is policy-based. BGP determines the best path based on variables, such as AS path, weight, local preference, MED, and so on. If all things are equal, BGP prefers the route leading to the BGP speaker with the lowest BGP router ID.

So R3 with BGP router ID 172.16.32.1 was preferred to the higher BGP router ID of R2 which is 172.16.64.1.

This is why we can reach the 32 subnet and not the .64 one.

What we need to do to solve this, is advertise the links between the ISP and the two routers, which I’ll do now:

ISP#conf t
ISP(config)#router bgp 200
ISP(config-router)#network 192.168.1.0 mask 255.255.255.252
ISP(config-router)#network 192.168.4.0 mask 255.255.255.252

I am now able to reach both networks from the ISP router:

ISP#ping 172.16.64.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.64.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/7/16 ms
ISP#ping 172.16.32.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.32.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/6/20 ms

I will now configure the “next-hop-self” neighbor keyword on both R2 and R3 so they advertise themselves as the next hop for foreign routes.

This is the current ip bgp table on R2 and R3

Now to enter the aforementioned commands.

R2#conf t
R2(config)#router bgp 64512
R2(config-router)#neighbor 172.16.32.1 next-hop-?
next-hop-self next-hop-unchanged

R2(config-router)#neighbor 172.16.32.1 next-hop-self

R3#conf t
R3(config)#router bgp 64512
R3(config-router)#neighbor 172.16.64.1 next-hop-self

And let’s take another look at our ip bgp tables to see what has changed.

This is looking nice and clean.
Do note the ‘r‘ symbol in front of the route for network 192.168.1.0/30. This indicates a RIB Failure.

In most cases this will mean that BGP can not inject the route, because a more specific or preferred route already exists.

If you check the routing table on R3, you will see that the network is Directly Connected, which is indeed more preferred.
The same goes for the alternate path through 172.16.64.1, which is learned through EIGRP, thus more preferred.

At this point, everything is looking good, with the exception of default routes and the outbound and inbound traffic flow.

Our objective states that we must use the link between R2 and ISP as the preferred link.

To achieve this I will be using Local Preference to manipulate our routing decisions.

This can be done by using Route-maps and the “local-preference” sub-command.

We will create a Route-Map and use it to set the local-preference.  Then we will enter a neighbor statement to refer to the routemap.

Vamos!

R2#conf t
R2(config)#route-map PREFERREDLINE_IN permit
R2(config-route-map)#set local-preference 150
R2(config-route-map)#exit
R2(config)#router bgp 64512
R2(config-router)#neighbor 192.168.1.5 route-map PREFERREDLINE_IN in

R3#conf t
R3(config)#route-map BACKUPLINE_IN permit
R3(config-route-map)#set local-preference 125
R3(config-route-map)#exit
R3(config)#router bgp 64512
R3(config-router)#neighbor 192.168.1.1 route-map BACKUPLINE_IN in

Now, after clearing the BGP process, let’s take another look at the ip bgp table.

Everything is now being sent over our preferred link as intended.

Let’s do a recorded ping test on R3 to 192.168.100.1 with as source its loopback interface.

Reply to request 0 (28 ms). Received packet has options
Total option bytes= 40, padded length=40
Record route:
(172.16.1.2)
(192.168.1.6)
(192.168.100.1)
(192.168.1.5)
(172.16.1.1)
(172.16.32.1) <*>

Looks like we’re taking the path R3 – R2 -> ISP -> R2 -> R3.

If we take down the preferred link, traffic will flow over the backup link as intended.

R2(config)#int se 0/1
R2(config-if)#shut
R2(config-if)#
R2#
R2#
*Mar 1 02:36:26.939: %BGP-5-ADJCHANGE: neighbor 192.168.1.5 Down Interface flap

Reply to request 1 (12 ms). Received packet has options
Total option bytes= 40, padded length=40
Record route:
(172.16.1.1)
(192.168.1.2)
(192.168.100.1)
(192.168.1.1)
(172.16.1.2)
(172.16.64.1) <*>

And there we go, objective completed.