Complex redistribution can be quite a challenging task to encounter studying for the CCIE R&S lab. There doesn’t seem to be that many clearly define general rules out there. So I thought why not dissect each individual case that could cause tricky redistribution problems.
RIP and OSPF are a perfect example of two protocols that when they meet, something will go wrong by default. The reason that these two protocols are so prone to problems is for 1. RIP has no concept of an external routes and 2. OSPF has the same AD for internal and external routes.
In this simple looking example, I have mutual redistribution on R2. RIP routing domain is R1,R2,R3 and OSPF routing domain is R2,R3 and R4. Whenever I start redistribution problem, I write down which routes belongs to which routing domain. In this example I have:
RIP
10.1.12.0/24 (R1->R2)
10.1.13.0/24 (R1->R3)
1.1.1.0/24 (Loopback on R1)
OSPF
10.1.24.0/24 (R2 ->R4)
10.1.34.0/24 (R3-> R4)
4.4.4.0/24 (Loopback on R4)
I found it to be a good idea to create an ACL for each routing domain and use it to verify all routes are installed in their native routing domain. This ACL would only be configured on routers where both routing domain meet. For example an ACL to match all routes that should be nativelly learned over RIP on R2 and R3 :
ip access-list standard RIP-NATIVE
permit 1.1.1.0
permit 10.1.13.0
permit 10.1.12.0
..and for OSPF
ip access-list standard OSPF-NATIVE
permit 4.4.4.0
permit 10.1.24.0
permit 10.1.34.0
Before I do any redistribution, I would like to verify that my ACLs are working correctly. To do so, on R3 and R2 I use the command show ip route list (ACL) followed by the ACL name like RIP-NATIVE or OSPF-NATIVE.
R3#sh ip route list OSPF-NATIVE
O IA 4.4.4.0/24 [110/11] via 10.1.34.4, 00:01:18, FastEthernet0/1
O 10.1.24.0 [110/20] via 10.1.34.4, 00:12:55, FastEthernet0/1
C 10.1.34.0 is directly connected, FastEthernet0/1
R3#sh ip route list RIP-NATIVE
R 1.1.1.0 [120/1] via 10.1.13.1, 00:00:20, FastEthernet0/0
C 10.1.13.0 is directly connected, FastEthernet0/0
R 10.1.12.0 [120/1] via 10.1.13.1, 00:00:20, FastEthernet0/0
All routes have their respective route either directly connected or using their native routing protocol. Now I can configure mutual redistribution on R2.
R2(config)#router rip
R2(config-router)#redistribute ospf 1 metric 1
R2(config-router)#router ospf 1
R2(config-router)#redistribute rip subnets
Let me do a quick check of my routing table to see if all routes are being learn nativelly. First R2 and then R3.
R2#sh ip route list OSPF-NATIVE
O IA 4.4.4.0/24 [110/11] via 10.1.24.4, 00:00:11, FastEthernet0/1
C 10.1.24.0 is directly connected, FastEthernet0/1
O 10.1.34.0 [110/20] via 10.1.24.4, 00:00:11, FastEthernet0/1
R2#sh ip route list RIP-NATIVE
R 1.1.1.0 [120/1] via 10.1.12.1, 00:00:12, FastEthernet0/0
R 10.1.13.0 [120/1] via 10.1.12.1, 00:00:12, FastEthernet0/0
C 10.1.12.0 is directly connected, FastEthernet0/0
R2 looks good. Now let me check R3:
R3#sh ip route list OSPF-NATIVE
O IA 4.4.4.0/24 [110/11] via 10.1.34.4, 00:01:18, FastEthernet0/1
O 10.1.24.0 [110/20] via 10.1.34.4, 00:12:55, FastEthernet0/1
C 10.1.34.0 is directly connected, FastEthernet0/1
R3#sh ip route list RIP-NATIVE
O E2 1.1.1.0 [110/20] via 10.1.34.4, 00:00:30, FastEthernet0/1
C 10.1.13.0 is directly connected, FastEthernet0/0
O E2 10.1.12.0 [110/20] via 10.1.34.4, 00:00:30, FastEthernet0/1
Hmm… OSPF looks OK as expected, but something is wrong with RIP. I’m not learning any RIP routes anymore, but instead learning all of these routes through OSPF routing domain from R4 (interface 10.1.34.4). If I look at one of the RIP advertised routes 4.4.4.0 on R3:
R3#sh ip route 4.4.4.0
Routing entry for 4.4.4.0/24
Known via “ospf 1″, distance 110, metric 11, type inter area
Last update from 10.1.34.4 on FastEthernet0/1, 00:17:49 ago
Routing Descriptor Blocks:
* 10.1.34.4, from 10.4.4.4, 00:17:49 ago, via FastEthernet0/1
Route metric is 11, traffic share count is 1
… I see that now this route has an AD of 110 instead of 120 as previously, which is the reason why R3 is not learning any RIP route. R2 redistributes RIP to OSPF, R3 install only the OSPF routes because cause of the lower AD of 110.
The quickest and easiest way to fix this problem is to apply a distance command on R3 that lowers the AD of RIP routes to something below OSPF 110. In our example I’ll use 109 for all neighbors using the previous defined ACL RIP-NATIVE.
R3(config)#router rip
R3(config-router)#distance 109 0.0.0.0 255.255.255.255 RIP-NATIVE
Verify:
R3#sh ip route list RIP-NATIVE
R 1.1.1.0 [109/1] via 10.1.13.1, 00:00:04, FastEthernet0/0
C 10.1.13.0 is directly connected, FastEthernet0/0
R 10.1.12.0 [109/1] via 10.1.13.1, 00:00:04, FastEthernet0/0
All RIP native routes are learn through RIP on R3.
If you configure mutual redistribution on R3 make sure to apply the same distance command on R2 to prevent this same problem.
Hopefully with this example I was able to show you a good methodology of how to prevent problems when redistributing RIP and OSPF that could be applied to a bigger and more complex redistribution problem in the lab.
Recent Comments