This document explains two common problems with redistributing routes between RIP and OSPF or IGRP and EIGRP. RIP and IGRP will not advertise routes out an interface if those routes are on the same major network, but have a different mask than that particular interface. For more information on RIP and IGRP updates, refer to Behavior of RIP and IGRP When Sending and Receiving Updates.
There are no specific requirements for this document.
This document is not restricted to specific software and hardware versions.
The information presented in this document was created from devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If you are working in a live network, ensure that you understand the potential impact of any command before using it.
For more information on document conventions, refer to Cisco Technical Tips Conventions.
In the network diagram for this problem, Router GW-2 is redistributing between RIP and OSPF. The OSPF domain has a different mask (longer in this case) than the RIP domain, and they are on the same major network. Therefore, RIP will not advertise routes learned from OSPF and redistributed into RIP.
The subnet mask of the OSPF domain is difficult to change, so instead, add a static route in Router GW-2 that points to the OSPF domain with a mask of 255.255.255.0, but with a next hop of null0. Then, redistribute static routes into RIP. Here is the configuration to accomplish this task:
ip route 18.104.22.168 255.255.255.0 null0
default metric 1
This allows 22.214.171.124 to be advertised through RIP out the E2/0 interface of Router GW-2. However, Router GW-2 still has more specific routes learned from OSPF in its routing table, so the best routing decisions are made.
In the network diagram for this problem, the RIP domain has a mask of 255.255.255.248 and OSPF domain has a mask of 255.255.255.240. RIP will not advertise routes learned from OSPF and redistributed into RIP.
We can add a static route in Router GW-2 that points to the OSPF domain with a mask of 255.255.255.248. However, because this is a more specific mask than the original OSPF mask, the next hop must be an actual next hop or interface(s). Also, we need multiple static routes in order to cover all of the addresses in the OSPF domain. This way static routes are redistributed into RIP.
In the code below, the first two static routes cover the range 126.96.36.199 255.255.255.240 in the OSPF domain. The second two static routes cover the range 188.8.131.52 255.255.255.240 in the OSPF domain. And the last four static routes cover the range 184.108.40.206 255.255.255.240, which are known via two interfaces in the OSPF domain.
ip route 220.127.116.11 255.255.255.248 E0/0
ip route 18.104.22.168 255.255.255.248 E0/0
ip route 22.214.171.124 255.255.255.248 E1/0
ip route 126.96.36.199 255.255.255.248 E1/0
ip route 188.8.131.52 255.255.255.248 184.108.40.206
ip route 220.127.116.11 255.255.255.248 18.104.22.168
ip route 22.214.171.124 255.255.255.248 126.96.36.199
ip route 188.8.131.52 255.255.255.248 184.108.40.206
default metric 1
The solutions presented in this document also work when you use EIGRP instead of OSPF, and IGRP instead of RIP. This problem should not happen if the masks of both protocols are the same or if all the protocols you use support Variable Length Subnet Mask (VLSM). This fix is only considered a patch to cover the RIP and IGRP (VLSM) limitation. For more information on the RIP and IGRP VLSM limitation, refer to Why Don't RIP and IGRP Support VLSM?.