BGP Backdoor Feature

Introduction

 

In this blog, we are going to be taking a look at the BGP backdoor feature.  We will explain what problem the feature allows us to solve and look at implementing the feature on a rack of real Cisco gear.

“Mr Potatohead!!! Backdoors are NOT secrets!!!”

– Jim from “Wargames”

Of course in “Wargames” they were talking about backdoor passwords put in place to hack into systems, but still…gotta love it!  Today we won’t be talking about backdoor passwords, but we will be talking about the backdoor feature of BGP.

 

Topology Summary


 

 

As usual, a quick diagram explanation — We have a point-to-point serial link between R2 and R5 running HDLC.  We are running OSPF over this serial link.  At the same time, both R2 and R5 peer eBGP to R4 over frame-relay at layer 2.  R2 is in AS 2 while R5 is in AS 5.  Both peer eBGP to R4 in AS 4.  The OSPF and BGP configurations are relatively straight forward — R2 and R5 advertise in their /32 loopback addresses and run OSPF on the HDLC link.  In BGP both R2 and R5 also advertise their /32 loopbacks.

This is a fairly typical type of setup for WAN redundancy.  You can think of R4 as a service provider in this case.  Since I was mucking about with using VRF light on a single router I went ahead and implemented VRFs on R4, but that is not really important here.

 

Initial Configs

 

R2

interface Loopback0
 ip address 2.2.2.2 255.255.255.255
!
interface Serial0/1/0
 no ip address
 encapsulation frame-relay
 no fair-queue
 no frame-relay inverse-arp
!
interface Serial0/1/0.24 point-to-point
 ip address 24.24.24.2 255.255.255.0
 snmp trap link-status
 frame-relay interface-dlci 204
!
interface Serial0/2/0
 ip address 25.25.25.2 255.255.255.0
!
router ospf 1
 log-adjacency-changes
 network 2.2.2.2 0.0.0.0 area 0
 network 25.25.25.2 0.0.0.0 area 0
!
router bgp 2
 no synchronization
 bgp log-neighbor-changes
 network 2.2.2.2 mask 255.255.255.255
 neighbor 24.24.24.4 remote-as 4
 no auto-summary

R4

ip vrf VPN
 rd 4:1
 route-target export 4:1
 route-target import 4:1
!
interface Serial0/0
 no ip address
 encapsulation frame-relay
 no fair-queue
 no frame-relay inverse-arp
!
interface Serial0/0.24 point-to-point
 ip vrf forwarding VPN
 ip address 24.24.24.4 255.255.255.0
 frame-relay interface-dlci 402
!
interface Serial0/0.45 point-to-point
 ip vrf forwarding VPN
 ip address 45.45.45.4 255.255.255.0
 frame-relay interface-dlci 405
!
router bgp 4
 no synchronization
 bgp log-neighbor-changes
 no auto-summary
 !
 address-family ipv4 vrf VPN
 neighbor 24.24.24.2 remote-as 2
 neighbor 24.24.24.2 activate
 neighbor 45.45.45.5 remote-as 5
 neighbor 45.45.45.5 activate
 no synchronization
 exit-address-family

R5

interface Loopback0
 ip address 5.5.5.5 255.255.255.255
!
interface Serial2/0
 no ip address
 encapsulation frame-relay
 serial restart-delay 0
 no fair-queue
 no frame-relay inverse-arp
!
interface Serial2/0.45 point-to-point
 ip address 45.45.45.5 255.255.255.0
 frame-relay interface-dlci 504
!
interface Serial2/1
 ip address 25.25.25.5 255.255.255.0
 serial restart-delay 0
!
router ospf 1
 log-adjacency-changes
 network 5.5.5.5 0.0.0.0 area 0
 network 25.25.25.5 0.0.0.0 area 0
!
router bgp 5
 no synchronization
 bgp log-neighbor-changes
 network 5.5.5.5 mask 255.255.255.255
 neighbor 45.45.45.4 remote-as 4
 no auto-summary
!

Let’s do a bit of simple verification.  First up, is our layer 2 and basic layer 3 connectivity working?

R2#ping 24.24.24.4

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 24.24.24.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/56/56 ms
R2#ping 25.25.25.5

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

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

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

I’m satisfied with that. How about OSPF and BGP?

R2#show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
5.5.5.5           0   FULL/  -        00:00:36    25.25.25.5      Serial0/2/0

R2#show ip bgp sum | b Neighbor
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
24.24.24.4      4     4      62      58       12    0    0 00:53:43        1
R5#show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2           0   FULL/  -        00:00:37    25.25.25.2      Serial2/1

R5#show ip bgp sum | b Neighbor
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
45.45.45.4      4     4      60      59       12    0    0 00:52:32        1

Good!

Feature Summary

 

Like many things in networking in general, the BGP backdoor feature exists to solve a specific problem.  So, what is the problem?  Well, it all depends on how you are looking at it and what you want in your network.  Ask yourself how R2 will route to get to R5’s loopback and visa versa by default?  If you guessed over the frame-relay network via BGP you are correct.  Why?  Because we will learn the route via both OSPF and BGP and eBGP routes have a lower administrative distance (20) than OSPF routes (110).  Let’s verify our logic on R2 and R5

R2#sh ip route bgp
     5.0.0.0/32 is subnetted, 1 subnets
B       5.5.5.5 [20/0] via 24.24.24.4, 00:00:36
R5#show ip route bgp
     2.0.0.0/32 is subnetted, 1 subnets
B       2.2.2.2 [20/0] via 45.45.45.4, 00:00:50

If you want to be routing over the frame-relay network in this case, that is all fine and good. However, what if you wanted R2 and R5 to reach each others routes over the point-to-point HDLC link instead? Well, we COULD modify the administrative distance of BGP with the distance bgp command from router config mode to make eBGP routes less preferred than OSPF. We COULD modify the administrative distance of OSPF to make OSPF routes more preferred than eBGP routes, but there is another way. We might not want to modify the AD for some good reasons. In BGP there is also no way to modify the AD per route, so you would be changing the AD for ALL eBGP routes which you might not want to do. We can use the BGP backdoor feature to accomplish our goal.

Under the BGP routing process we can simply use the network command followed by the backdoor route we wish to prefer, and then the keyword backdoor. This tells BGP under the hood to not actually advertise that route out through BGP but to give it an administrative distance of 200. Thus, it will make the route less preferred than OSPF and fix our issue here.

 

Implementation

 

The implementation of BGP backdoor is very simple.  We use the network command.  We will do this on both sides here to avoid asynchronous routing issues.

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#router bgp 2
R2(config-router)#network 5.5.5.5 mask 255.255.255.255 backdoor
R5#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R5(config)#router bgp 5
R5(config-router)#network 2.2.2.2 mask 255.255.255.255 backdoor

Let’s see how we did by checking the routing tables again

R2#show ip route 5.5.5.5
Routing entry for 5.5.5.5/32
  Known via "ospf 1", distance 110, metric 65, type intra area
  Last update from 25.25.25.5 on Serial0/2/0, 00:01:10 ago
  Routing Descriptor Blocks:
  * 25.25.25.5, from 5.5.5.5, 00:01:10 ago, via Serial0/2/0
      Route metric is 65, traffic share count is 1
R5#show ip route 2.2.2.2
Routing entry for 2.2.2.2/32
  Known via "ospf 1", distance 110, metric 65, type intra area
  Last update from 25.25.25.2 on Serial2/1, 00:01:02 ago
  Routing Descriptor Blocks:
  * 25.25.25.2, from 2.2.2.2, 00:01:02 ago, via Serial2/1
      Route metric is 65, traffic share count is 1

Excellent! What if we shut down our point-to-point serial link on R2?

R2(config)#int s0/2/0
R2(config-if)#shutdown
R2(config-if)#
*Oct 25 20:41:23.175: %OSPF-5-ADJCHG: Process 1, Nbr 5.5.5.5 on Serial0/2/0 from FULL to DOWN, Neighbor Down: Interface down or detached
R2(config-if)#
*Oct 25 20:41:25.175: %LINK-5-CHANGED: Interface Serial0/2/0, changed state to administratively down
*Oct 25 20:41:26.175: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/2/0, changed state to down

R2(config-if)#do sh ip route 5.5.5.5
Routing entry for 5.5.5.5/32
  Known via "bgp 2", distance 200, metric 0
  Tag 4, type locally generated
  Last update from 24.24.24.4 00:00:27 ago
  Routing Descriptor Blocks:
  * 24.24.24.4, from 24.24.24.4, 00:00:27 ago
      Route metric is 0, traffic share count is 1
      AS Hops 2
      Route tag 4

There we go…notice the AD is 200 and not the standard eBGP value of 20! So, what we learned is that the BGP backdoor feature is useful for modifying the default routing behavior of BGP for specific networks in situations where we wish to route over a backdoor link running some other normally less preferred IGP. Hope this was useful to everybody!

Last but not least, the video inspiring the comment at the beginning from one of my favorite movies : )

Tags: , , ,

5 Comments

Leave a Reply