BGP and Redistribution

Hello everyone! Today I would like to share with you all a few obscure specific details related to both BGP and redistribution. Having things like this down will be important to your success in the lab. I know that some of the details I will be discussing were surprises to me when I first learned them, so hopefully it will help you guys out!

While we will be using both of the technologies in this article they are not necessarily related. Let’s take a look at our network diagram. What we have here is a fairly simple (by CCIE standards hehe) topology. R1 runs BGP and is in AS 1. R1 peers to R2 which is in AS 2 along with routers R5 and R6. The peering between R1 and R2 uses the physical interface on VLAN 100 for sourcing. The frame-relay cloud in AS 2 runs OSPF as an IGP. All routers in AS 2 run iBGP as well with R2 acting as a route-reflector. Peers inside of AS 2 peer using the loopback0 address. The VLAN 100 subnet is NOT advertised into BGP.

The first thing I would like to cover is how BGP behaves with respect to next-hop reachability. R1 is advertising in the 11.11.11.11/32 network into BGP. We can see this on R2:

R2(config-router)#do sh ip bgp
BGP table version is 4, local router ID is 2.2.2.2
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
*> 11.11.11.11/32   100.100.100.1            0             0 1 i

As we can see here, we have the 11.11.11.11/32 prefix in R2’s BGP table. The route is marked as valid and best, with a next hop of 100.100.100.1. Let’s check out R5.

R5(config-if)#do sh ip bgp
BGP table version is 4, local router ID is 5.5.5.5
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
* i11.11.11.11/32   100.100.100.1            0    100      0 1 i
R5(config-if)#do sh ip route 100.100.100.0
% Subnet not in table

As we would expect, we see 11.11.11.11/32 in the BGP table of R5, but it is not marked as best. Why? Because we have no reachability to the next-hop of 100.100.100.1. Up until now, this seems like a pretty typical issue you might see in a CCIE lab or mock lab. Typically, we can solve this problem a few different ways: We could advertise 100.100.100.0/24 into OSPF so we would have a route to the next-hop, OR we could set R2 to next-hop-self on all its neighbor statements down to R5 and R6. Today I want to talk about a third more obscure way – The default route. Yes, it’s true! The default-route can actually be used for the BGP next-hop check. Even if we have no route to the next-hop, if we have a default-route in our routing table, the BGP route will be seen as valid, best, and added to the RIB. Let’s see this in action.

R2(config-router)#router ospf 1
R2(config-router)#default-information originate always
R5(config-if)#do sh ip route ospf | i 0.0.0.0
100.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
O*E2 0.0.0.0/0 [110/1] via 100.100.150.2, 00:00:37, Serial0/1/0
R5(config-if)#do sh ip bgp
BGP table version is 5, local router ID is 5.5.5.5
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
*>i11.11.11.11/32   100.100.100.1            0    100      0 1 i
R5(config-if)#do sh ip route bgp
11.0.0.0/32 is subnetted, 1 subnets
B       11.11.11.11 [200/0] via 100.100.100.1, 00:02:01
R5(config-if)#do sh ip route 100.100.100.0
% Subnet not in table

As we can see, the 11.11.11.11/32 prefix is now seen as valid and best and therefore added to the RIB even though we have no specific route to the next-hop! We would see the exact same thing happening on R6. So, the lesson here is that the default-route can actually be used for BGP next-hop reachability checks.

The second thing I want to talk about today is redistribution, and how things are actually seen on the router. Right now on R2 we are redistributing in the loopback0 interface by using a very specific route-map.

R2(config-router)#do sh run | s ospf
ip ospf network point-to-multipoint
router ospf 1
log-adjacency-changes
redistribute connected subnets route-map OSPF-Connected
network 100.100.150.2 0.0.0.0 area 0
default-information originate always
R2(config-router)#do sh route-map OSPF-Connected
route-map OSPF-Connected, permit, sequence 10
Match clauses:
interface Loopback0
Set clauses:
Policy routing matches: 0 packets, 0 bytes
R2(config-router)#do sh ip route 2.2.2.2
Routing entry for 2.2.2.2/32
Known via "connected", distance 0, metric 0 (connected, via interface)
Redistributing via ospf 1
Advertised by ospf 1 subnets route-map OSPF-Connected
Routing Descriptor Blocks:
* directly connected, via Loopback0
Route metric is 0, traffic share count is 1

OK, this should be no big deal. We are doing a redistribute connected and filtering which connected interfaces we redistribute in by using a route-map. Our route-map specifically calls Loopback0 and ONLY Loopback0. We can validate this by checking out R5 or R6 and seeing we have no route to 22.22.22.22/32 (the other loopback on R2).

R6(config-if)#do sh ip route 22.22.22.22
% Network not in table

Now, the interesting part is the following: Take a look at 22.22.22.22/32 on R2.

R2(config-router)#do sh ip route 22.22.22.22
Routing entry for 22.22.22.22/32
Known via "connected", distance 0, metric 0 (connected, via interface)
Redistributing via ospf 1
Routing Descriptor Blocks:
* directly connected, via Loopback22
Route metric is 0, traffic share count is 1
R2(config-router)#do sh ip ospf database
OSPF Router with ID (2.2.2.2) (Process ID 1)
Router Link States (Area 0)
Link ID         ADV Router      Age         Seq#       Checksum Link count
1.1.1.1         1.1.1.1         2121        0x80000003 0x00496D 2
2.2.2.2         2.2.2.2         1563        0x80000009 0x00E942 3
5.5.5.5         5.5.5.5         1724        0x80000003 0x008B39 3
6.6.6.6         6.6.6.6         1706        0x80000003 0x009D19 3
Type-5 AS External Link States
Link ID         ADV Router      Age         Seq#       Checksum Tag
0.0.0.0         2.2.2.2         511         0x80000001 0x00FEAB 1
2.2.2.2         2.2.2.2         1539        0x80000001 0x004F41 0

So we are NOT redistributing 22.22.22.22/32 into OSPF, yet our “show ip route” output shows “redistributing via ospf 1”. To further prove the fact that it is not in OSPF, we see above that the route is not showing on R6. Also, it is not even in the OSPF database. No other filtering has been put in place. So what gives? Well, it is a subtlety. In actuality we ARE redistributing all connected interfaces, and then filtering those connected interfaces with the route-map. When we say “redistribute connected” inside of OSPF the router will actually show all connected interfaces as “redistributed via OSPF” weather they are filtered or not. The route will never make it to the RIB or even the OSPF LSDB, due to filtering in our route-map but will still be shown as “redistributed via OSPF.” This could really throw you for a loop (like it did me once) if you didn’t know about it, which is why I wanted to take the time to write this article.

Thanks for reading, and until next time, study hard and you will succeed!

Joe Astorino — CCIE #24347

BGP and Redistribution, 4.0 out of 5 based on 1 rating