It's a well known fact that RR (Route Redistribution) is a complicated topic (putting it mildly), and all of you studying for expert level certifications or running old and complicated networks know what I'm talking about. Don't worry, I won't go into a crazy corner-case scenario, this is based on something that happened in a production network.
To start off, I'll list a few things which are relevant to the cases we'll look at below:
- RR is a complex policy-based process.
- Vendor implementations are proprietary (there is no clear standard) and documentation is usually lacking on the finer points.
- A route is redistributed only if it is actively used (installed in the RIB/FIB) and learned via the specified source protocol.
- RR does not impact local route selection (a redistributed route will not replace its source in the RIB).
- Information (metrics, topology) is lost when redistributing from one routing protocol to another (with some exceptions, such as EIGRP<->EIGRP).
The topology is rather simple: three routers connected as above - so you might be asking yourselves how much mischief can I generate with just 3 routers? The answer is: enough.
The main focus here is the fact that
R2 have two equal cost paths between them, so we'll be looking at what happens when
R2 becomes a redistribution point.
R1 advertises loopback
R3 sends out its loopback
220.127.116.11/32 and, while I've configured full reachability between them, I'm only interested in the
OSPF and EIGRP
Once the dust settles, the routing tables will have the following information:
#R1 O E2 18.104.22.168 [110/20] via 10.2.12.2, 00:00:02, FastEthernet0/1 [110/20] via 10.1.12.2, 00:00:02, FastEthernet0/0 #R2 O 22.214.171.124 [110/11] via 10.2.12.1, 00:57:30, FastEthernet0/1 [110/11] via 10.1.12.1, 00:57:30, FastEthernet0/0 D 126.96.36.199 [90/156160] via 10.1.23.3, 00:05:45, FastEthernet1/0 #R3 D EX 188.8.131.52 [170/2560002816] via 10.1.23.2, 00:05:31, FastEthernet0/0
First thing that stands out is that
R3 has no idea of the equal-cost load-balancing that's done by
R2 in the OSPF domain. This is lost information and redistribution does not care about it.
When traffic flows from
R1, it will be load-balanced by
R2 over both links. I had to disable per-flow load-balancing (never a good idea outside of a lab) on
R2 in order to get the output below and prove it actually works:
R3# trace 184.108.40.206 so lo0 Type escape sequence to abort. Tracing the route to 220.127.116.11 1 10.1.23.2 28 msec 28 msec 20 msec 2 10.2.12.1 48 msec 10.1.12.1 52 msec 10.2.12.1 36 msec
Why does it work? While
R3 has no idea of the OSPF topology,
R2 has two routes to
18.104.22.168/32 in its RIB and it's not afraid to use them!
The question screaming for an answer right now is: if
R2 has two equal cost routes in its RIB, why doesn't it redistribute both when it exports them from OSPF into EIGRP?
RR is done out of the RIB (routes that are best andin use are a candidate) and it doesn't really matter if this route has one or multiple next-hops. It is reachable via this redistributing router and that's all the destination protocol cares about.
When a packet for
R2, it's taken care of by the source route (OSPF in this case) in the RIB. It's out of EIGRP's hands.
And even if it had any information about it, EIGRP is a distance-vector protocol. The next-hop is the advertising router, so when
R3 gets updates from
R2, it will use
R2's IPs as next-hops.
Same goes for RIP. OSPF and ISIS calculate the topology themselves and, while they have a full view of their own domain, they know nothing about other routing domains (information lost while redistributing).
OSPF and BGP
What about BGP, you might be asking. It's a protocol that propagates next-hop information so it must do something differently. Well, sort of.
After I replace the EIGRP adjacency with an eBGP peering, the routing tables have the following information:
#R1 O E2 22.214.171.124 [110/1] via 10.2.12.2, 00:01:04, FastEthernet0/1 [110/1] via 10.1.12.2, 00:01:04, FastEthernet0/0 #R2 O 126.96.36.199 [110/11] via 10.2.12.1, 00:02:09, FastEthernet0/1 [110/11] via 10.1.12.1, 00:02:09, FastEthernet0/0 B 188.8.131.52 [20/0] via 10.1.23.3, 00:00:49 #R3 B 184.108.40.206 [20/11] via 10.1.23.2, 00:00:33
And, again, the traceroute shows us loadbalancing works:
R3# trace 220.127.116.11 so lo0 Type escape sequence to abort. Tracing the route to 18.104.22.168 1 10.1.23.2 20 msec 28 msec 20 msec 2 10.1.12.1 [AS 2] 48 msec 10.2.12.1 [AS 2] 36 msec 10.1.12.1 [AS 2] 44 msec
The end result is identical to the previous case. When looking at the BGP table on
R2, we can see it has taken the
22.214.171.124/32 prefix with a next-hop of
10.1.12.1. Is this arbitrary? Not really. It looks like it chooses the lowest next-hop IP address - this is based on observation, as I couldn't find anything in Cisco's documentation about it.
R2# show ip bgp 126.96.36.199 BGP routing table entry for 188.8.131.52/32, version 4 Paths: (1 available, best #1, table Default-IP-Routing-Table) Local 10.1.12.1 from 0.0.0.0 (184.108.40.206) Origin incomplete, metric 11, localpref 100, weight 32768, valid, sourced, best
This being an eBGP peering, the next-hop changes when the prefix is passed on to
R3# show ip bgp 220.127.116.11 BGP routing table entry for 18.104.22.168/32, version 2 Paths: (1 available, best #1, table Default-IP-Routing-Table) 10.1.23.2 from 10.1.23.2 (22.214.171.124) Origin incomplete, metric 11, localpref 100, valid, external, best
Had this been iBGP instead, then
R3 would've done a recursive lookup for
10.1.12.1 and resolved it towards
R2. Once the packet got to
R2 though, it would've been forwarded according to
R2's RIB (with the two equal cost paths).
So we've seen that the destination protocol has no idea if any load-balancing is happening on the other side, even when this is as close as the redistributing router itself.
In the examples above there is no real downside and routing functions as you'd expect it to. That's about to change though: in part 2, I'm bringing VRFs and MPBGP into the picture and, as you might expect, something will go wrong.
And, as always, thanks for reading.