Jun 052013
 

R4 advertises loopback 0 into RIP, which is further redistributed by R2 into OSPF. R3 then redistributes OSPF back to RIP with a metric of 1 which causes 2 problems.

First problem is that R2 has 2 paths to reach the loopback of R4 one from R4 itself and other being redistributed by R3. Second problem is that link between R1 and R2 will not be advertised to R4 because of the distance vector problem (a router will only advertise a route if it has the protocol activated on the link or if it learns the route from a remote source via the same routing protocol).

R4#sh run | sec rip
router rip
 version 2
 network 4.0.0.0
 network 10.0.0.0
 no auto-summary
 
R2#sh run | sec router
router ospf 1
 router-id 2.2.2.2
 log-adjacency-changes
 redistribute rip subnets
 network 12.0.0.2 0.0.0.0 area 0
 
router rip
 version 2
 network 10.0.0.0
 no auto-summary
 
R3#sh run | sec router
router ospf 1
 router-id 3.3.3.3
 log-adjacency-changes
 
router rip
 version 2
 redistribute ospf 1 metric 1
 network 10.0.0.0
 no auto-summary
 

Solution to the first problem would be to filter the 4.4.4/24 network at R3 from being advertised back to RIP. When there are multiple points of redistribution, and the network which is being redistributed could only be reached via one path, then the initial router which is exchanging routes to another routing domain (redistributing) must not choose any other path other than the one from which it initially learned.

For this problem   we could do either filtering at R3 or at R2. The below example demonstrates to filters the route at R3 by setting the metric to 16.

R3(config)#route-map FILTER_R4_LOOPBACK
R3(config-route-map)#match ip address R4_LOOPBACK
R3(config-route-map)#set metric 16
 
R3(config)#ip access-list standard R4_LOOPBACK
R3(config-std-nacl)#permit 4.4.4.0
 
R3(config)#router rip
R3(config-router)#redistribute ospf 1 metric 1 route-map FILTER_R4_LOOPBACK
 
Debug ip routing shows that the 4.4.4.0/24 network via R3 gets deleted from RIB.
R2#debug ip routing
 
RT: del 4.4.4.0/24 via 10.0.23.3, rip metric [120/1]
RT: NET-RED 4.4.4.0/24

 

Solution to the second problem does not relate to redistribution rather a normal distance vector protocol behavior. Even if R2 receives the 12/8 network via RIP from R3, it does not use that RIP update as it has the network directly attached. To resolve this issue redistribute either OSPF or connected at R2 into RIP.  In this particular case R2 could also generate a default route.

R2(config)#router rip
R2(config-router)#redistribute ospf 1 metric 3
 
R4#debug ip routing
RT: SET_LAST_RDB for 12.0.0.0/8
  NEW rdb: via 10.0.24.2
RT: add 12.0.0.0/8 via 10.0.24.2, rip metric [120/3]
RT: NET-RED 12.0.0.0/8

To conclude, if a route 'X' could only be originally learned from one particular source, the same route 'X' must not be relearned from any other source. DV protocols only advertise a network, if the network is added under the corresponding routing process using the network command or if it has a route in the RIB learned via the same routing protocol.