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 192.168.250.0 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.
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.
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 192.168.250.0 255.255.255.0 10.131.245.100
Also the VPN device is on Vlan 245 (interface 1/0/41) as well.
Is there a way round this without creating separate vlans ?
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:
redistribute static route-map STATICS-to-RIP metric 1
redistribute ospf 1 route-map OSPF-to-RIP metric 1
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.
I applied the metric commands :-
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 192.168.250.0 and 192.168.255.0 networks into RIP.
Please post the output from typing
show ip route 192.168.250.0
show ip route 192.168.255.0
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.
It looks to me like there are two issues here, and possibly a third.
I understand you want to advertise 192.168.250.0/24 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 192.168.250.0/24 is 10.131.245.100, 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 192.168.250.0/24 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.
Ok , I have managed to get this working using the 'no ip split-horizon' under the vlan 245 interface and applying network 192.168.250.0 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 192.168.250.0 will be advertised from switch A and DMZ 192.168.255.0 will be advertised from switch B.
next hop for 192.168.250.0/24 is 10.131.245.100
next hop for 192.168.255.0/24 is 10.134.245.100
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 192.168.250.0 to come in from the branch office via switch A and vice versa any requests for 192.168.255.0 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 ?