BGP Backdoor
In the diagram below, a link has been added between AS10 and AS30. It’s a new EIGRP connection that should be used as a primary path when speaking between the 12.12.12.0/30 network and the 45.45.45.0/30 network. In the event the new EIGRP link fails, the original BGP path via R3 should be used for backup. When analysing the best path between AS10 & AS30, you should be able to spot that the problem is going to be the admin distance: eBGP’s AD 20 vs EIGRP’s AD 90 means that eBGP via R3 is more preferred than the EIGRP link.
The way we’re going to fix this is by using the BGP backdoor feature. Firstly, what I’m going to do is advertise the 45.45.45.0/30 network into BGP on R2, and advertise the 12.12.12.0/30 network into BGP on R4. Sounds weird, but what happens is that it makes the routers advertise these networks as if they are local iBGP routes = AD of 200. This makes EIGRP link more preferred between AS10 & AS30 because it’s admin distance is now lower. Before changing anything, let’s take a glance at the routing table on R2.
R2#sh ip route | b Gate
Gateway of last resort is not set
34.0.0.0/30 is subnetted, 1 subnets
B 34.34.34.0 [20/0] via 23.23.23.2, 00:01:12
23.0.0.0/30 is subnetted, 1 subnets
C 23.23.23.0 is directly connected, FastEthernet0/1
24.0.0.0/30 is subnetted, 1 subnets
C 24.24.24.0 is directly connected, FastEthernet1/0
12.0.0.0/30 is subnetted, 1 subnets
C 12.12.12.0 is directly connected, FastEthernet0/0
45.0.0.0/30 is subnetted, 1 subnets
B 45.45.45.0 [20/0] via 23.23.23.2, 00:00:42
As you can see, the best path to the 45.45.45.0/30 network is via eBGP using an AD of 20, which is taking presidence over our EIGRP route to this network (hence why the EIGRP route isn’t shown in the output above). Let’s make the fix.
R2(config)#router bgp 10
R2(config-router)#network 45.45.45.0 mask 255.255.255.252
R4(config)#router bgp 30
R4(config-router)#network 12.12.12.0 mask 255.255.255.252
R2#sh ip route | b Gate
Gateway of last resort is not set
34.0.0.0/30 is subnetted, 1 subnets
B 34.34.34.0 [20/0] via 23.23.23.2, 00:04:11
23.0.0.0/30 is subnetted, 1 subnets
C 23.23.23.0 is directly connected, FastEthernet0/1
24.0.0.0/30 is subnetted, 1 subnets
C 24.24.24.0 is directly connected, FastEthernet1/0
12.0.0.0/30 is subnetted, 1 subnets
C 12.12.12.0 is directly connected, FastEthernet0/0
45.0.0.0/30 is subnetted, 1 subnets
D 45.45.45.0 [90/30720] via 24.24.24.2, 00:03:42, FastEthernet1/0
Good. So our local router R2 thinks that the 45.45.45.0/30 network is now an iBGP route rather than an eBGP route, meaning the AD for this network is now 200 (via iBGP). Obviously the best path is via EIGRP, using an AD of 90. This makes our EIGRP route more preferred. All I have to do now to complete the configuration, is fix the problem we just made on R3. Let’s check out what happened when we made the change. This is how R3’s BGP table looked before adding the network statements above
R3#sh ip bgp
BGP table version is 5, local router ID is 34.34.34.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
*> 12.12.12.0/30 23.23.23.1 0 0 10 ?
* 23.23.23.0/30 23.23.23.1 0 0 10 i
*> 0.0.0.0 0 32768 i
*> 34.34.34.0/30 0.0.0.0 0 32768 i
* 34.34.34.2 0 0 30 i
*> 45.45.45.0/30 34.34.34.2 0 0 30 ?
This is how the BGP table looks after we made the change
R3#sh ip bgp
BGP table version is 8, local router ID is 34.34.34.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
*> 12.12.12.0/30 34.34.34.2 30720 0 30 i
* 23.23.23.1 0 0 10 ?
* 23.23.23.0/30 23.23.23.1 0 0 10 i
*> 0.0.0.0 0 32768 i
* 34.34.34.0/30 34.34.34.2 0 0 30 i
*> 0.0.0.0 0 32768 i
*> 45.45.45.0/30 23.23.23.1 30720 0 10 i
* 34.34.34.2 0 0 30 ?
R3#traceroute 45.45.45.2
1 23.23.23.1 32 msec 40 msec 20 msec
2 24.24.24.2 40 msec 20 msec 20 msec
3 45.45.45.2 [AS 10] 48 msec * 60 msec
So we are learning that the two highlighted networks now appear to originate in AS10 as well as AS30, which is incorrect. What’s happened is that R2 is now advertising the 45.45.45.0/30 network to eBGP peers as if he was the originator in AS10. Just as R4 is advertising 12.12.12.0/30 as if he is the originator in AS30. Which is correct according to the network statement we just configured. But obviously this is wrong as 45.45.45.0/30 resides in AS30, and 12.12.12.0/30 resides in AS10. The ORIGIN code is then causing R3 to prefer the path via R2 for the 45.45.45.0/30 prefix in AS10. It is also causing R3 to prefer the path for the 12.12.12.0/30 prefix via R4, which isn’t what we wanted to do. We can confirm this by checking out the attributes of the route.
R3#sh ip bgp 45.45.45.0
BGP routing table entry for 45.45.45.0/30, version 8
Paths: (2 available, best #1, table Default-IP-Routing-Table)
Advertised to update-groups:
1
10
23.23.23.1 from 23.23.23.1 (24.24.24.1)
Origin IGP, metric 30720, localpref 100, valid, external, best
30
34.34.34.2 from 34.34.34.2 (45.45.45.1)
Origin incomplete, metric 0, localpref 100, valid, external
When I originally configured this behind the scenes, I advertised the 45.45.45.0/30 network on R4 into EIGRP and then used the #redistribute eigrp 1 command under the BGP process. However, when I just advertised this same network on R2 a moment ago, I used the BGP #network 45.45.45.0 mask 255.255.255.0 command. This creates a more preferred ORIGIN code via R2 (ORIGIN IGP wins vs ORIGIN incomplete). What we can do to fix this is use the #network x.x.x.x backdoor command so that we do not advertise any networks that don’t actually reside in our AS to any of our eBGP peers. Lets do that now:
R2(config-router)#network 45.45.45.0 mask 255.255.255.252 backdoor R4(config-router)#network 12.12.12.0 mask 255.255.255.252 backdoor
Let’s just check that R3 doesn’t receive the 45.45.45.0/30 network via R2, & also doesn’t receive the 12.12.12.0/30 network via R4, then we can confirm this fixed the problem:
R3#sh ip bgp
BGP table version is 5, local router ID is 34.34.34.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
*> 12.12.12.0/30 23.23.23.1 0 0 10 ?
* 23.23.23.0/30 23.23.23.1 0 0 10 i
*> 0.0.0.0 0 32768 i
*> 34.34.34.0/30 0.0.0.0 0 32768 i
* 34.34.34.2 0 0 30 i
*> 45.45.45.0/30 34.34.34.2 0 0 30 ?
Good problem solved. R2 is using the EIGRP path to R4 when speaking between the 12.12.12.0/30 network & the 45.45.45.0/30 network. If the link fails, he will use the BGP path via R3 instead. R3 is only learning the prefixes by the correct AS’s.
source: http://ccieblog.co.uk/bgp/bgp-backdoor
source: http://ccieblog.co.uk/bgp/bgp-backdoor
