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.

BGP LAB #2: Removing Private Autonomous System Numbers

In the topology below you can see that R3’s BGP process is running in AS 65000. AS Numbers 64511 through 65535 are private and should not be leaked into a BGP table because they are not unique.

Private AS numbers are usually assigned to a company that only has a single ISP with one or multiple connections. This is called a single-homed connection.

In this update I will look into which methods are available to make sure the private AS numbers are removed from the PATH list before the routers are propagated to a BGP peer.

Topology

R3 represents our client-side office, with R2 being its ISP. R1, in turn, represents a network somewhere else on the internet.

Initial Configuration

R1
==

R1#sh run int se 0/0
Building configuration…

Current configuration : 84 bytes
!
interface Serial0/0
ip address 10.0.0.1 255.255.255.252
clock rate 2000000
end

R1#sh run int lo 1
Building configuration…

Current configuration : 61 bytes
!
interface Loopback1
ip address 1.1.1.1 255.255.255.0
end

R1#sh run | sec bgp
router bgp 100
no synchronization
bgp log-neighbor-changes
network 1.1.1.0 mask 255.255.255.0
neighbor 10.0.0.2 remote-as 200
no auto-summary

R2
==

R2#sh run int se 0/0
Building configuration…

Current configuration : 84 bytes
!
interface Serial0/0
ip address 10.0.0.2 255.255.255.252
clock rate 2000000
end

R2#sh run int se 0/1
Building configuration…

Current configuration : 84 bytes
!
interface Serial0/1
ip address 20.0.0.2 255.255.255.252
clock rate 2000000
end

R2#sh run int lo 1
Building configuration…

Current configuration : 61 bytes
!
interface Loopback1
ip address 2.2.2.2 255.255.255.0
end

R2#sh run | sec bgp
router bgp 200
no synchronization
bgp log-neighbor-changes
network 2.2.2.0 mask 255.255.255.0
neighbor 10.0.0.1 remote-as 100
neighbor 20.0.0.1 remote-as 65000
no auto-summary

R3
==

R3#sh run int se 0/1
Building configuration…

Current configuration : 84 bytes
!
interface Serial0/1
ip address 20.0.0.1 255.255.255.252
clock rate 2000000
end

R3#sh run int lo 1
Building configuration…

Current configuration : 61 bytes
!
interface Loopback1
ip address 3.3.3.3 255.255.255.0
end

R3#sh run | sec bgp
router bgp 65000
no synchronization
bgp log-neighbor-changes
network 3.3.3.0 mask 255.255.255.0
neighbor 20.0.0.2 remote-as 200
no auto-summary

Looking at the paths on R1, we can see that AS 65000 is included. This means that our private AS information is being leaked into the internet which could have some bad results!

By doing some research, you can find that Cisco has added a feature to their routers which will allow you to remove the private AS numbers from any advertisements.

This is done by adding the keyword “remove-private-as” to your BGP neighbour statement towards the router that should NOT receive the private AS.

Let’s go on our ISP router, R2, and configure this to see the results.

R2(config)#router bgp 200
R2(config-router)#neighbor 10.0.0.1 remove-private-as

Let’s take another look at the paths on R1 after running “Clear IP BGP *” on R2.

We can now see that the private AS is no longer showing up.

What happened is that R2 removed the private AS number and replaced it with its own. You can see that for R3’s loopback interface, the only known path is AS 200.

Then at R2, we can still see the required path information and are still able to ping R3 from R1.

So that is it. We have successfully stopped the private AS number from leaking into the ‘internet’.

References:
BGP Best path selection.
Removing private AS.

BGP LAB #1: Default Routing, Route Filtering and Floating Static Routes

In this LAB I will configure basic BGP with default routing and also touch on subjects such as verification, route filters and floating static routes.

Topology:

Initial Configuration:

HQ_Office
=========
interface Loopback0
ip address 192.168.0.1 255.255.255.0

interface Loopback1
ip address 192.168.1.1 255.255.255.0

interface Serial1/1
ip address 10.0.0.2 255.255.255.252
serial restart-delay 0

interface Serial1/2
ip address 172.16.0.2 255.255.255.252
serial restart-delay 0

ISP_1
=====
interface Loopback0
ip address 10.1.1.1 255.255.255.0

interface Serial1/1
ip address 10.0.0.1 255.255.255.252
serial restart-delay 0

ISP_2
=====
interface Loopback0
ip address 172.16.1.1 255.255.255.0

interface Serial1/2
ip address 172.16.0.1 255.255.255.252
serial restart-delay 0

First up is the configuration of the BGP router process with an AS number (Autonomous System) and its neighbours. In BGP neighbours are statically assigned with a reference to the remote AS.
The two ISP routers will become neighbours of the HQ router, but not of eachother.

HQ_Office(config)#router bgp 100
HQ_Office(config-router)#neighbor 10.1.1.1 remote-as 200
HQ_Office(config-router)#neighbor 172.16.0.1 remote-as 300

You can see the syntax is “neighbour remote-interface-IP remote-as remote-as-number

Like other router protocols, you must also chose which networks to advertise. I will only add the loopback interfaces to these “network” commands, because we already have static neighbourships on the others.

HQ_Office(config-router)#network 192.168.0.1
HQ_Office(config-router)#network 192.168.1.1

Debug BGP All has been turned on on the HQ router so we can see what kind of output we get once the neighbourships are configured. After enabling the debugging, I can already see peering attempts go out. They fail however, because the other side is not yet configured.

*Mar 1 01:07:24.975: BGP: 172.16.0.1 open active, local address 172.16.0.2
*Mar 1 01:07:25.007: BGP: 172.16.0.1 open failed: Connection refused by remote host, open active delayed 27179ms (35000ms max, 28% jitter)

I will now configure the same for routers ISP_1 and 2.

The neighbour statement on ISP_1

ISP_1(config)#router bgp 200
ISP_1(config-router)#neighbor 10.0.0.2 remote-as 100

And now I’m seeing the following output on the HQ Router. It looks like our neighbourship has formed with 10.0.0.1.

*Mar  1 01:09:54.859: BGP: 10.0.0.1 went from Idle to Active
*Mar 1 01:10:17.459: BGP: 10.0.0.1 passive open to 10.0.0.2
*Mar 1 01:10:17.459: BGP: 10.0.0.1 went from Active to Idle
*Mar 1 01:10:17.459: BGP: 10.0.0.1 went from Idle to Connect

After these messages, it starts exchanging its BGP information, something I do not know that much about yet ..

*Mar 1 01:10:17.467: BGP: 10.0.0.1 rcv message type 1, length (excl. header) 26
*Mar 1 01:10:17.467: BGP: 10.0.0.1 rcv OPEN, version 4, holdtime 180 seconds
*Mar 1 01:10:17.467: BGP: 10.0.0.1 went from Connect to OpenSent
*Mar 1 01:10:17.467: BGP: 10.0.0.1 sending OPEN, version 4, my as: 100, holdtime 180 seconds
*Mar 1 01:10:17.467: BGP: 10.0.0.1 rcv OPEN w/ OPTION parameter len: 16
*Mar 1 01:10:17.467: BGP: 10.0.0.1 rcvd OPEN w/ optional parameter type 2 (Capability) len 6
*Mar 1 01:10:17.467: BGP: 10.0.0.1 OPEN has CAPABILITY code: 1, length 4
*Mar 1 01:10:17.467: BGP: 10.0.0.1 OPEN has MP_EXT CAP for afi/safi: 1/1
*Mar 1 01:10:17.467: BGP: 10.0.0.1 rcvd OPEN w/ optional parameter type 2 (Capability) len 2
*Mar 1 01:10:17.467: BGP: 10.0.0.1 OPEN has CAPABILITY code: 128, length 0
*Mar 1 01:10:17.467: BGP: 10.0.0.1 OPEN has ROUTE-REFRESH capability(old) for all address-families
*Mar 1 01:10:17.467: BGP: 10.0.0.1 rcvd OPEN w/ optional parameter type 2 (Capability) len 2
*Mar 1 01:10:17.467: BGP: 10.0.0.1 OPEN has CAPABILITY code: 2, length 0
*Mar 1 01:10:17.467: BGP: 10.0.0.1 OPEN has ROUTE-REFRESH capability(new) for all address-families
BGP: 10.0.0.1 rcvd OPEN w/ remote AS 200
*Mar 1 01:10:17.467: BGP: 10.0.0.1 went from OpenSent to OpenConfirm
*Mar 1 01:10:17.467: BGP: 10.0.0.1 send message type 1, length (incl. header) 45
*Mar 1 01:10:17.495: BGP: 10.0.0.1 went from OpenConfirm to Established
*Mar 1 01:10:17.495: %BGP-5-ADJCHANGE: neighbor 10.0.0.1 Up

But, you can see, at the end of all this, it says that the neighbour is up. Let’s also configure out network statement on ISP_1 now.

ISP_1(config-router)#network 10.1.1.0 mask 255.255.255.0

Okay, so far the HQ and ISP_1 router are configured, let’s take a look at how the output of our “show bgp neighbours” is like at the moment.

HQ_Office#sh bgp nei
BGP neighbor is 10.0.0.1, remote AS 200, external link
BGP version 4, remote router ID 10.1.1.1
BGP state = Established, up for 00:06:03
Last read 00:00:03, last write 00:00:03, hold time is 180, keepalive interval is 60 seconds
Neighbor capabilities:
Route refresh: advertised and received(old & new)
Address family IPv4 Unicast: advertised and received
Message statistics:
InQ depth is 0
OutQ depth is 0
Sent Rcvd
Opens: 1 1
Notifications: 0 0
Updates: 1 1
Keepalives: 9 9
Route Refresh: 0 0
Total: 11 11
Default minimum time between advertisement runs is 30 seconds

For address family: IPv4 Unicast
BGP table version 2, neighbor version 2/0
Output queue size: 0
Index 1, Offset 0, Mask 0x2
1 update-group member
Sent Rcvd
Prefix activity: —- —-
Prefixes Current: 1 1 (Consumes 52 bytes)
Prefixes Total: 1 1
Implicit Withdraw: 0 0
Explicit Withdraw: 0 0
Used as bestpath: n/a 1
Used as multipath: n/a 0

Outbound Inbound
Local Policy Denied Prefixes: ——– ——-
Total: 0 0
Number of NLRIs in the update sent: max 1, min 1

Connections established 1; dropped 0
Last reset never
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 1
Local host: 10.0.0.2, Local port: 179
Foreign host: 10.0.0.1, Foreign port: 46649
Connection tableid (VRF): 0

Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes)

Event Timers (current time is 0x45F068):
Timer Starts Wakeups Next
Retrans 10 0 0x0
TimeWait 0 0 0x0
AckHold 10 1 0x0
SendWnd 0 0 0x0
KeepAlive 0 0 0x0
GiveUp 0 0 0x0
PmtuAger 0 0 0x0
DeadWait 0 0 0x0
Linger 0 0 0x0
ProcessQ 0 0 0x0

iss: 3073044154 snduna: 3073044418 sndnxt: 3073044418 sndwnd: 16121
irs: 18814913 rcvnxt: 18815182 rcvwnd: 16116 delrcvwnd: 268

SRTT: 221 ms, RTTO: 832 ms, RTV: 611 ms, KRTT: 0 ms
minRTT: 20 ms, maxRTT: 300 ms, ACK hold: 200 ms
Status Flags: passive open, gen tcbs
Option Flags: nagle
IP Precedence value : 6

Datagrams (max data segment is 1460 bytes):
Rcvd: 20 (out of order: 0), with data: 11, total data bytes: 268
Sent: 13 (retransmit: 0, fastretransmit: 0, partialack: 0, Second Congestion: 0), with data: 11, total data bytes: 263
Packets received in fast path: 0, fast processed: 0, slow path: 0
Packets send in fast path: 0
fast lock acquisition failures: 0, slow path: 0

BGP neighbor is 172.16.0.1, remote AS 300, external link
BGP version 4, remote router ID 0.0.0.0
BGP state = Active
Last read 00:15:07, last write 00:15:07, hold time is 180, keepalive interval is 60 seconds
Message statistics:
InQ depth is 0
OutQ depth is 0
Sent Rcvd
Opens: 0 0
Notifications: 0 0
Updates: 0 0
Keepalives: 0 0
Route Refresh: 0 0
Total: 0 0
Default minimum time between advertisement runs is 30 seconds

For address family: IPv4 Unicast
BGP table version 2, neighbor version 0/0
Output queue size: 0
Index 1, Offset 0, Mask 0x2
1 update-group member
Sent Rcvd
Prefix activity: —- —-
Prefixes Current: 1 0
Prefixes Total: 0 0
Implicit Withdraw: 0 0
Explicit Withdraw: 0 0
Used as bestpath: n/a 0
Used as multipath: n/a 0

Outbound Inbound
Local Policy Denied Prefixes: ——– ——-
Total: 0 0
Number of NLRIs in the update sent: max 0, min 0

Connections established 0; dropped 0
Last reset never
No active TCP connection

Wow, that is alot more output than the equivalent commands of, for example, EIGRP. When glancing over it, you should notice that for the neighbour  10.0.0.1, the relationship is Established, but for the other neighbour, 172.16.0.1, the state is Active. Active sounds good, but it actually means that is is Actively Searching for its neighbour.

This is all very exciting so let’s move on and configure BGP on ISP_2.

ISP_2(config)#router bgp 300
ISP_2(config-router)#neighbor 172.16.0.2 remote-as 100
ISP_2(config-router)#network 172.16.1.0 mask 255.255.255.0

And now I”m seeing similar output on the HQ router for this neighbourship.

*Mar 1 01:24:53.543: BGP: 172.16.0.1 open active, local address 172.16.0.2
*Mar 1 01:24:53.579: BGP: 172.16.0.1 went from Active to OpenSent
*Mar 1 01:24:53.579: BGP: 172.16.0.1 sending OPEN, version 4, my as: 100, holdtime 180 seconds
*Mar 1 01:24:53.591: BGP: 172.16.0.1 send message type 1, length (incl. header) 45
*Mar 1 01:24:53.623: BGP: 172.16.0.1 rcv message type 1, length (excl. header) 26
*Mar 1 01:24:53.627: BGP: 172.16.0.1 rcv OPEN, version 4, holdtime 180 seconds
*Mar 1 01:24:53.631: BGP: 172.16.0.1 rcv OPEN w/ OPTION parameter len: 16
*Mar 1 01:24:53.631: BGP: 172.16.0.1 rcvd OPEN w/ optional parameter type 2 (Capability) len 6
*Mar 1 01:24:53.635: BGP: 172.16.0.1 OPEN has CAPABILITY code: 1, length 4
*Mar 1 01:24:53.635: BGP: 172.16.0.1 OPEN has MP_EXT CAP for afi/safi: 1/1
*Mar 1 01:24:53.635: BGP: 172.16.0.1 rcvd OPEN w/ optional parameter type 2 (Capability) len 2
*Mar 1 01:24:53.635: BGP: 172.16.0.1 OPEN has CAPABILITY code: 128, length 0
*Mar 1 01:24:53.635: BGP: 172.16.0.1 OPEN has ROUTE-REFRESH capability(old) for all address-families
*Mar 1 01:24:53.635: BGP: 172.16.0.1 rcvd OPEN w/ optional parameter type 2 (Capability) len 2
*Mar 1 01:24:53.635: BGP: 172.16.0.1 OPEN has CAPABILITY code: 2, length 0
*Mar 1 01:24:53.635: BGP: 172.16.0.1 OPEN has ROUTE-REFRESH capability(new) for all address-families
BGP: 172.16.0.1 rcvd OPEN w/ remote AS 300
*Mar 1 01:24:53.635: BGP: 172.16.0.1 went from OpenSent to OpenConfirm
*Mar 1 01:24:53.635: BGP: 172.16.0.1 went from OpenConfirm to Established
*Mar 1 01:24:53.635: %BGP-5-ADJCHANGE: neighbor 172.16.0.1 Up

It looks like the process goes something like Idle -> Active -> OpenSent (Sends ‘Open’) -> (Receive ‘Open‘) -> OpenConfirm -> Established. And it looks like the ‘Open’ message carries alot of information about the neighbouring router’s BGP configuration. I will have to get deeper into this, later on.

The basic BGP configuration for all three routers is now done, Let’s check out the HQ router’s routing table with the command “show ip route“.

HQ_Office#sh ip route
Codes: C – connected, S – static, R – RIP, M – mobile, B – BGP
D – EIGRP, EX – EIGRP external, O – OSPF, IA – OSPF inter area
N1 – OSPF NSSA external type 1, N2 – OSPF NSSA external type 2
E1 – OSPF external type 1, E2 – OSPF external type 2
i – IS-IS, su – IS-IS summary, L1 – IS-IS level-1, L2 – IS-IS level-2
ia – IS-IS inter area, * – candidate default, U – per-user static route
o – ODR, P – periodic downloaded static route

Gateway of last resort is not set

172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
C 172.16.0.0/30 is directly connected, Serial1/2
B 172.16.1.0/24 [20/0] via 172.16.0.1, 00:03:54
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
B 10.1.1.0/24 [20/0] via 10.0.0.1, 00:13:25
C 10.0.0.0/30 is directly connected, Serial1/1
C 192.168.0.0/24 is directly connected, Loopback0
C 192.168.1.0/24 is directly connected, Loopback1

It looks like we have ‘B’ routes for the ISP router’s loopback interfaces as intended. Further verification can be done with the command “show bgp“.

We have a BGP Table Version of 3 and we can see the networks and through which next hop they are reachable.
Now let’s make a change and see if anything happens to the  Table Version counter.

I will shutdown the loopback interface on ISP_1.

ISP_1(config)#int lo 0
ISP_1(config-if)#shut

*Mar 1 01:34:21.747: %LINK-5-CHANGED: Interface Loopback0, changed state to administratively down
*Mar 1 01:34:22.747: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback0, changed state to down

And another “show bgp” on the HQ router:

There you go, the shutdown interface’s network has disappeared and the Table Version‘s counter has gone up by one. I’ll bring ISP_1’s loopback interface back up.

ISP_1(config-if)#no shut
ISP_1(config-if)#
*Mar 1 01:37:21.151: %LINK-3-UPDOWN: Interface Loopback0, changed state to up
*Mar 1 01:37:22.151: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback0, changed state to up
ISP_1(config-if)#

If we now take a look at ISP_2’s routing table, we can see the following;

There seems to be a route that belongs to the ISP_1 network, what is it doing on the ISP_2 router? I guess our HQ router advertised a route belonging to a different ISP and because we have taken no steps to prevent this kind of behavior, the ISP_2 router has gone ahead and added this route to its routing table!

The solution that we will implement is Route Filtering.

On the HQ router, we will configure an access-list that will allow the routes for 192.168.0.0 and 192.168.1.0 to be advertised. As there is an implicit deny at the end of every access-list, the other routes’ advertisements will be blocked.

HQ_Office(config)#access-list 1 permit 192.168.0.0 0.0.1.255

I will now apply this access list in our BGP router process’ neighbour statements with the “distribute-list” keyword.

HQ_Office(config)#router bgp 100

HQ_Office(config-router)#neighbor 10.0.0.1 distribute-list ?
<1-199> IP access list number
<1300-2699> IP access list number (expanded range)
WORD IP Access-list name

HQ_Office(config-router)#neighbor 10.0.0.1 distribute-list 1 ?
in Filter incoming updates
out Filter outgoing updates

HQ_Office(config-router)#neighbor 10.0.0.1 distribute-list 1 out
HQ_Office(config-router)#neighbor 172.16.0.1 distribute-list 1 out

The access-list 1 has been used to filter Outgoing Updates.

Before we can see any changes, we must first clear the BGP process on the HQ router with the command “Clear ip BGP *

HQ_Office#clear ip bgp *

For reference, here is the output from the “debug ip bgp all” after clearing the bgp process.

Let’s see if our route filter has worked, “Show ip route” on ISP_2 go!

Yes sir, the loopback networks from the other ISP are no longer showing up as intended!

Now, the HQ router is the border router for its network and has a connection with two different ISPs. We will implement floating static routes that will use ISP_1 as the primary provider and ISP_2 as the backup.

This can be done by specifying a lower metric route for ISP_1 on the HQ router and a higher one for ISP_2 with the command “ip route“.

HQ_Office(config)#ip route 0.0.0.0 0.0.0.0 10.0.0.1 210
HQ_Office(config)#ip route 0.0.0.0 0.0.0.0 172.16.0.1 220

With this configured, this is how our routing table looks on the HQ router:

You can see that there now is a gateway of last resort pointing to 10.0.0.1 with a distance metric of 210. If this route fails, it will be replaced by the one to 172.16.0.1 with a distance metric of 220.

I will shut down ISP_1’s interface;

ISP_1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
ISP_1(config)#int se 1/1
ISP_1(config-if)#shut
ISP_1(config-if)#
*Mar 1 02:24:16.271: %BGP-5-ADJCHANGE: neighbor 10.0.0.2 Down Interface flap
ISP_1(config-if)#
*Mar 1 02:24:18.243: %LINK-5-CHANGED: Interface Serial1/1, changed state to administratively down
*Mar 1 02:24:19.243: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/1, changed state to down
ISP_1(config-if)#

And the HQ router is now showing ..

A default route to 172.16.0.1 as intended! So that is working aswell.

You can also configure these primary and backup default routes by configuring an “ip default-network ip-address” on the HQ router and then have a static route pointing to the backup path, which is ISP_2.

References:
Official Cisco LAB Guide
Border Gateway Protocol
Configuring BGP