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.


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 mask backdoor
R3(config-router)#net mask backdoor

R3(config-router)#net mask backdoor

R3(config-router)#net mask backdoor

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

clear ip bgp soft out
*Mar 1 22:46:20.954: BGP(0): send UPDATE (format), next, metric 0, path Local
*Mar 1 22:46:20.962: BGP(0): send UPDATE (prepend, chgflags: 0×0), next, metric 0, path Local

*Mar 1 22:46:20.966: BGP(0): send UPDATE (prepend, chgflags: 0×0), next, metric 0, path Local

*Mar 1 22:46:21.070: BGP(0): updgrp 1 – updates replicated for neighbors:


So R3 has advertised backdoor prefixes through eBGP…

We can verify this on R2:

R2 (config-router)#do sh ip route is subnetted, 3 subnets

B [20/0] via, 00:00:31

B [20/0] via, 00:00:31

B [20/0] via, 00:00:31


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

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
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

*> 0 0 64014 i

*> 0 0 64014 i

*> 0 0 64014 i

*> 0 32768 i

*> 0 32768 i

*> 0 32768 i

*> 0 64014 i

*> 0 64014 i

*> 0 64014 i


No prefixes 30

R2#sh ip route is subnetted, 3 subnets

D [90/2297856] via, 2d13h, Serial1/2

D [90/2297856] via, 2d13h, Serial1/2

D [90/2297856] via, 2d13h, Serial1/2


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 mask backdoor
R2(config-router)#net mask backdoor

R2(config-router)#net mask backdoor

Now let’s check again R2 BGP & RIB tables

R2#sh ip bgp

r> 0 64014 64030 i

r> 0 64014 64030 i

r> 0 64014 64030 i


R2#sh ip route is subnetted, 3 subnets

D [90/2297856] via, 00:00:13, Serial1/2

D [90/2297856] via, 00:00:19, Serial1/2

D [90/2297856] via, 00:00:16, Serial1/2


That’s exactly what we were looking for.

More detailed BGP inf.

R2#sh ip bgp
BGP routing table entry for, version 20
Paths: (1 available, best #1, table Default-IP-Routing-Table, RIB-failure(17))

Flag: 0×820

Not advertised to any peer

64014 64030 from (

Origin IGP, localpref 100, valid, external, best


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)


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).

About these ads

About ajnouri
Se vi deziras sekure komuniki eksterbloge, jen mia publika (GPG) ŝlosilo: My public key for secure secure communication:

8 Responses to BGP Backdoor

  1. abhishek says:

    very good amezin kya baat hai

  2. Robert says:

    Thank you for your cool explanation.

  3. dewalt steenberg says:

    only seems to work with eigrp. when i configure ospf, the ospf route across the interconnection is preferred over bgp. when using eigrp, it still prefers the bgp route

    • ajnouri says:

      Hi Dewalt, The administrative distance of (external eBGP=20) < (OSPF=110) so it should be reacheable through OSPF.

      • dewalt steenberg says:

        i know – so is eigrp :)

        which is why i think it’s a bit strange. this is only for the link between r3 and r2. the whole idea behind backdoor is to make the igrp more preferred to the same route learned from the igp, right?

        so with eigrp, the backdoor works fine, the route from eigrp is used as opposed to the one from ebgp. when implementing the lab with ospf, the ospf route is immediately taken, without using the backdoor command. it might have been some gns3 bug, but i thought it a bit strange.

      • ajnouri says:

        Can you please provide the output of “show ip bgp”? Does it show the route? Any RIB failure (r>)?

  4. dewalt steenberg says:

    hey, i figured it out. i had the “networks” that required bgp circumvention configured under a loopback. i changed the network type for ospf and that made it work as it should :) – it now requires the backdoor command to prefer the igp over bgp

  5. ajnouri says:

    Well done Dewalt.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: