BGP Backdoor

In this post I would like to share with you my experience with BGP backdoors along with some interesting observations related to the configuration.

Picture 1: lab topology

Our lab topology (picture1) illustrates two client autonomous systems connected to a backbone through eBGP (external).

The backdoor link will be the direct connection between AS 64030 and AS 64023

Backdoors can be motivated by some business needs like merging, acquisition, temporary collaboration between companies or technical needs like backup for example.

Due to the transient nature of these links they are routed using an internal routing protocol, in our case it is EIGRP.

Recall notes:

To understand the issue that lurks behind backdoors we need to understand some routing concepts.

BGP is a routing protocol used to route between Autonomous Systems. So BGP is not intended to ensure prefix connectivity, this is the role of IGP (internal routing protocols like OSPF, EIGRP or RIP).

In the case the same prefix is advertised through multiple routing protocols an election will take place to choose the best protocol.

Here where Administrative Distances are called into play to set a priority or preference for each protocol. The higher the Administrative Distance the less preferable is the protocol.

unreachable => 255Internal BGP (iBGP) => 200External EIGRP => 170 RIP => 120 OSPF => 110 Internal EIGRP => 90 External BGP (eBGP) = 20 Summary EIGRP => 5 Static route => 1 Directly connected => 0

The key concept behind that particular distribution of AD is that there is a big difference between routing internal prefixes inside a single domain and routing external prefixes (between different routing domain)

The same concept is valid for a single protocol (or should be).

We know that a prefix announced internally is more preferable that the same prefix coming from redistribution.

This is made easy in EIGRP by having different Administrative Distances, partially in OSPF by having preference for internal then inter-area then inter-domain, but needs to be done manually for RIP.

For example BGP understand that it is not the most qualified to talk about internal connectivity, that’s why iBGP prefixes have an AD of 200 (which is worse than any other IGP)

In the same time the Administrative Distance of external BGP = 20, better than any other IGP because BGP is the king, the champion of inter Autonomous system routing.

And for the same reasons OSPF do NOT redistribute by default external type1/type2 prefixes to BGP and by default BGP redistribute ONLY eBGP (external BGP) prefixes to other IGP.

In our case the border routers R2 and R3 will receive prefixes from External BGP (eBGP) = 20 and Internal EIGRP => 90

So if the prefixes 30 are advertised through both protocols, eBGP will be selected to be installed in the RIB.

Picture2: prefix installation in RIB between BGP and EIGRP

Picture 3: prefixes 30 at the Border router R2:

So far everything works according to the previously mentioned concepts, and namely that’s the issue.

Whatever the reason behind this backdoor link the goal is to make the traffic for prefixes 30 take the direct back-to-back connection between AS 64030 and 64023.

So what we need to do is to create an exception to the rule:

Theoretically there are 2 solutions:

A – Manually     1- Making the originator router R3 not advertising backdoor prefixes     2- Play with AD at R2 to make backdoor more preferable. This NOT recommended except when you are asked to do so (strict routing policies or CCIE exam P-:)) B- Using IOS BGP backdoor feature.

Looks like distinct solutions? Let’s see!

Enough of concepts, let’s go to the lab for more details.

Configuration:

Backdoor command: network <X.X.X.X> mask <Y.Y.Y.Y> backdoor

That’s all!

Let’s begin by applying the command on the border router R3 for prefixes 30

R3(config)#router bgp 64023 R3(config-router)#net 30.0.0.0 mask 255.255.255.0 backdoor R3(config-router)#net 30.0.1.0 mask 255.255.255.0 backdoor R3(config-router)#net 30.0.2.0 mask 255.255.255.0 backdoor R3(config-router)#net 30.0.3.0 mask 255.255.255.0 backdoor

And I will trigger an on-demand outbound advertisement using soft reset

clear ip bgp 4.4.4.4 soft out

R3# *Mar 1 22:46:20.954: BGP(0): 4.4.4.4 send UPDATE (format) 30.0.2.0/24, next 3.3.3.3, metric 0, path Local *Mar 1 22:46:20.962: BGP(0): 4.4.4.4 send UPDATE (prepend, chgflags: 0x0) 30.0.1.0/24, next 3.3.3.3, metric 0, path Local *Mar 1 22:46:20.966: BGP(0): 4.4.4.4 send UPDATE (prepend, chgflags: 0x0) 30.0.0.0/24, next 3.3.3.3, metric 0, path Local *Mar 1 22:46:21.070: BGP(0): updgrp 1 – 4.4.4.4 updates replicated for neighbors: R3#

So R3 has advertised backdoor prefixes through eBGP…

We can verify this on R2:

R2 (config-router)#do sh ip route … 30.0.0.0/24 is subnetted, 3 subnets B 30.0.2.0 [20/0] via 1.1.1.1, 00:00:31 B 30.0.0.0 [20/0] via 1.1.1.1, 00:00:31 B 30.0.1.0 [20/0] via 1.1.1.1, 00:00:31 R2(config-router)#

That’s not what Cisco states in the documentation??!?!?!

http://www.cisco.com/en/US/docs/ios/iproute_bgp/configuration/guide/irg_basic_net_ps6441_TSD_Products_Configuration_Guide_Chapter.html#wp1117226

Interestingly enough, only if I reboot R3 the router will not advertise these prefixes and R2 will receive only EIGRP prefixes and the issue is resolved. (Solution A-1)

(The following RIB and BGP tables are the result of configuring backdoor on R3 and rebooting it)

R2#sh ip bgp BGP table version is 10, local router ID is 20.0.2.1 Status codes: s suppressed, d damped, h history, * valid, > best, i – internal, r RIB-failure, S Stale Origin codes: i – IGP, e – EGP, ? – incomplete Network Next Hop Metric LocPrf Weight Path *> 10.0.0.0/24 1.1.1.1 0 0 64014 i *> 10.0.1.0/24 1.1.1.1 0 0 64014 i *> 10.0.2.0/24 1.1.1.1 0 0 64014 i *> 20.0.0.0/24 0.0.0.0 0 32768 i *> 20.0.1.0/24 0.0.0.0 0 32768 i *> 20.0.2.0/24 0.0.0.0 0 32768 i *> 40.0.0.0/24 1.1.1.1 0 64014 i *> 40.0.1.0/24 1.1.1.1 0 64014 i *> 40.0.2.0/24 1.1.1.1 0 64014 i R2#

No prefixes 30

R2#sh ip route … 30.0.0.0/24 is subnetted, 3 subnets D 30.0.2.0 [90/2297856] via 172.16.23.3, 2d13h, Serial1/2 D 30.0.0.0 [90/2297856] via 172.16.23.3, 2d13h, Serial1/2 D 30.0.1.0 [90/2297856] via 172.16.23.3, 2d13h, Serial1/2 R2#

Now, let’s go further and configure backdoor feature on R2 even though networks 30 are not connected.

R2(config)#router bgp 64023 R2(config-router)#net 30.0.0.0 mask 255.255.255.0 backdoor R2(config-router)#net 30.0.1.0 mask 255.255.255.0 backdoor R2(config-router)#net 30.0.2.0 mask 255.255.255.0 backdoor

Now let’s check again R2 BGP & RIB tables

R2#sh ip bgp … r> 30.0.0.0/24 1.1.1.1 0 64014 64030 i r> 30.0.1.0/24 1.1.1.1 0 64014 64030 i r> 30.0.2.0/24 1.1.1.1 0 64014 64030 i … R2#

R2#sh ip route … 30.0.0.0/24 is subnetted, 3 subnets D 30.0.2.0 [90/2297856] via 172.16.23.3, 00:00:13, Serial1/2 D 30.0.0.0 [90/2297856] via 172.16.23.3, 00:00:19, Serial1/2 D 30.0.1.0 [90/2297856] via 172.16.23.3, 00:00:16, Serial1/2 R2#

That’s exactly what we were looking for.

More detailed BGP inf.

R2#sh ip bgp 30.0.0.0 BGP routing table entry for 30.0.0.0/24, version 20 Paths: (1 available, best #1, table Default-IP-Routing-Table, RIB-failure(17)) Flag: 0x820 Not advertised to any peer 64014 64030 1.1.1.1 from 1.1.1.1 (1.1.1.1) Origin IGP, localpref 100, valid, external, best R2#

Note the RIB-failure

This is when BGP fail to install its best selection into the routing table (or maximum prefix number is configured or even in some cases IOS failure)

In our case it is caused by a better routing protocol, and knowing that EIGRP AD = 90 and eBGP =90 we can conclude that IOS manipulated them accordingly to make EIGRP the winner. (Solution A-2)

Conclusion:

We have seen that backdoor feature (solution B) accomplishes the work in 2 different ways:

1- Not advertise prefixes through eBGP (solution A-1) if configured only on the originating router and this last is rebooted.

2- Continue to advertise prefixes and manipulate Administrative distances if configured on both Border routers delimiting the backdoor connection (solution A-2).