We're looking for alternatives to RRI which to us seems broken for L2L VPN's with ASA5510's. Here's our problem:
We have two ASA5510's (8.4(1)) each connected to a different ISP at different ends of the plant. Internally they are on the same subnet along with a HSRP group that services internal hosts.
Either ASA's can initate L2L VPN's to remote peers. If a RRI path on the ASA's appeared only when a VPN L2L was actually up and disappeared when the VPN was down (as it does with VPN clients) our routing issues would be solved. Unfortunately, RRI doesn't seem to work this way so it's no use to us. Is there a reason RRI works this way over L2L VPN's?
Given this, and the fact we can't use routing protocols across the VPN's (but can use OSPF internally), is there any way we can actually get routing information into the network? For example, a remote peer could create a L2L VPN with either ASA. When this VPN traffic reaches one of our servers, how can we tell which ASA it's come from in order to re-route traffic back to the originating ASA? We have no control over which ASA will be selected by the remote peer (and the remote site will often switch ASA's for testing). If RRI worked logically the relevant ASA would have distributed the route to our routers, then removed it when the VPN went down. At other times one of our ASA's may initiate the VPN (although in this scenario we'd have a good idea of which one it was)
We've tried to come up with a few alternatives, like NATing incoming VPN traffic from a particular ASA, or SLA route tracking with uninteresting traffic to try and probe which VPN is up on an ASA, but these all seem like riduculous hacks to us.
So, are we missing something obvious? Surely our scenario isn't uncommon nowadays, is there an elegant solution that doesn't involve routing protocols across the VPN's with uncooperative peer administrators? I did read somewhere that RRI can work the way we want in later router IOS's by the use or not of the "Static" keyword, but initiating VPN's from internal routers is not an option for us.
So, any ideas would be much appreciated, bearing in mind we are obviously not Cisco routing aficionados
Thanks
