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