Redistribute OSPF into RIP

Unanswered Question
Mar 13th, 2008

The following config is applied on one of our Services switch (switch A in diagram)

We are running RIP on the VPN and OSPF on the internal LAN.

I am trying to redistribute static DMZ network into RIP from OSPF. The route is already advertised in OSPF but not in RIP.

The access-list has a deny statement that prevents the route being injected into RIP. If I remove this statement it still does not work. I've tried everything from removing the RIP configs to access-list and rebooting but still cant get this to work.

Any ideas how I can get this to work and what may be causing this ?

Is this split horizon that is preventing the route being injected into RIP as the the firewall and VPN are connected on the same switch ?.

Attached is the switch config and a diagram.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Richard Burts Thu, 03/13/2008 - 05:21


I do not think that you have given us enough information to be able to answer your question. It appears that the only interface where you are running RIP is VLAN 245. But you have not told us what address and subnet is on that interface. If the next hop in the static route is in VLAN 245 then your theory about split horizon is probably correct. But since we have no information about interfaces and addresses and subnets we can not be sure.



jayamistry Thu, 03/13/2008 - 05:55

Hi Rick,

I have attached switch config with interface info.

The next hop for the static is the Nokia firewall which is on Vlan 245. (interface 1/0/47)

ip route

Also the VPN device is on Vlan 245 (interface 1/0/41) as well.

Is there a way round this without creating separate vlans ?

Edison Ortiz Thu, 03/13/2008 - 06:03

When you redistribute any routes into RIP and you don't specify the metric for those routes, it will automatically tag those routes with a metric of 16.

Please specify the metric on the commands, for instance:

router rip

redistribute static route-map STATICS-to-RIP metric 1

redistribute ospf 1 route-map OSPF-to-RIP metric 1




jayamistry Thu, 03/13/2008 - 08:26

Will this definately work ? as I think I may have tried this and still did not work.

Edison Ortiz Thu, 03/13/2008 - 08:29

Will this definately work ?

Nothing is definite in life but I give it a 75% chance.

Richard Burts Thu, 03/13/2008 - 08:34


Unless you are positive that you tried this and it did not work then I would suggest that you give it a try. Failure to supply default metrics is a pretty frequent source of problems when redistributing.

I suspect that there may still be an issue that the next hop of the static route is out that interface. But first we should eliminate the possibility that the default metric is causing a problem.

It may be that running debug for RIP would shed some light on this issue.



jayamistry Thu, 03/13/2008 - 09:10

ok I will give this ago although its may take me few days to test and come back with an answer.

jayamistry Wed, 04/02/2008 - 02:55

Hi Edison,

I applied the metric commands :-

router rip

redistribute static metric 1 route-map STATICS-to-RIP

redistribute ospf 1 metric 1 route-map OSPF-to-RIP

This still failed to redistribute the statics and networks into RIP.

Edison Ortiz Wed, 04/02/2008 - 06:33

Please post the output from typing

show ip route

show ip route

on the router performing the redistribution.

Also, post the portion of the route-map config.

Additionally, you don't need a metric on the redistribute ospf command, you only need it for RIP.




Kevin Dorrell Wed, 04/02/2008 - 04:08

It looks to me like there are two issues here, and possibly a third.

First issue:

I understand you want to advertise out of interface vlan 245. I presume that, because Vlan245 is the only interface you are sending RIP advertisments to at all.

(I have this idea that perhaps you don't mean no-passive on VLAN245. That perhaps you mean passive on 245 and no-passive everywhere else. That is, tell everyone about vlan 245, but don't send updates on vlan 245 itself. Could that be so?)

The next-hop for is, which is on .... Vlan245. So ut appears you are trying to send a RIP advertisment to an interface that already owns the next hop. The only way you can do that is to put no ip split-horizon on the Vlan245 interface.

Secondly, I'm not really sure what you are trying to do. If you have in OSPF, and you are trying to get it into RIP from there, then it will not do it because it is not in the OSPF-to-RIP access list.

However, I would expect it to get into RIP through the STATICS-to-RIP route-map and access lists, specifically through RIP-HOP-1.

In this case, it does not matter that you have no default metric in your rip process because you have specified the ,metric in your route-map. But beware, if you do it this way you must do an clear ip route * after you set the metric, otherwise the process will not learn the new metric you have just typed in. (This is bitter experience!)

So, I think your issue here is the split-horizon thing.

Be aware of one more issue that you don't have here, but you are close to having. Normally, when redistributing OSPF to RIP, it silently includes the OSPF connecteds. But if you specify so much as one connected, or a static to an interface, to be redistributed into RIP, then the connecteds are no longer silently included - you have to specify them individually.

Kevin Dorrell


jayamistry Wed, 04/02/2008 - 06:34

Hi Kevin,

I have tried all the above and it still fails to update.

I think my last resort is to move the VPN onto a diferent Vlan ?.

jayamistry Wed, 04/02/2008 - 14:57

Ok , I have managed to get this working using the 'no ip split-horizon' under the vlan 245 interface and applying network under router rip.

This still worked without the metric 1 applied on redistibute static under router rip :-

redistribute static metric 1 route-map STATICS-to-RIP

My question is in reference to DiagramA posted earlier.

We have 2 sites with similar configurations for resiliency :-

DMZ will be advertised from switch A and DMZ will be advertised from switch B.


next hop for is

next hop for is


If a remote office needs to reach a device on either of these networks then they will come in via either switch A or B for these networks.

The deny statements under the VPN-ROUTES prevent these network being inject back into OSPF preventing a loop.

Is there any preference order required on the VPN to force requests for to come in from the branch office via switch A and vice versa any requests for to come in via switch B ? or will this work fine ?


Also by configuring the 'no split-horizon' on vlan 245 interface is this likely to cause any issues with other interfaces on the same vlan ?


This Discussion