VPN 3000 and Reverse route Injection using OSPF

[cchristou]

I have been trying to get the RRI feature working on the VPN 3000 for a long time now and have tested this feature extensively.

Although it works (either with OSPF using RRI OR Network Autodiscovery using RIP) and the VPN routes are injected into RIP or OSPF, I cannot seem to get the router gateway sitting behind the concentrators to lose the VPN route when connectivity is lost to the remote vpn peer!! This means that the VPN 3000's still advertise the VPN routes even when connectivity is lost to the remote vpn peer and the vpn session has timed out!

The only way I can get the concentrator to stop advertising the VPN routes is to either shut down its public interface or shut the whole thing down itself!

Anyone have any thoughts on this?

[gfullage]

If you have a static L2L tunnel configured with RRI, then the concentrator will ALWAYS advertise the remote networks out into the local network, regardless of whether the tunnel is up or not. The theory is that since this is a static L2L tunnel, you're always going to want to send traffic for the remote network to the local concentrator, so it may as well advertise the route. More importantly, since tunnels are built only when traffic is seen, if we didn't advertise the route when the tunnel was down, further traffic would never get to the concentrator again and the tunnel would never be built.

Having said that, for VPN client connections, since these are dynamic, the routes for the negotiated VPn addresses are only advertised when the tunnel is up to that client. This can be modified under the Config - System - IP Routing - RRI section.

[cchristou]

Thanks for your reply,

I understand what you are saying; however, if there are two concentrators, one advertising routes via OSPF and the other using static routing and sitting behind them is a router gateway listening on OSPF and configured with a floating static route then the router gateway will never be able to choose a backup route if a LAN-to-LAN tunnel goes down on the primary concentrator.

What is the point of running dynamic routing protocols on the concentrators if they are not DYNAMIC??