Alternate to RRI

I am currently trying to advertise routes to our VPN connected sites using EIGRP on our 55xx firewalls. For most sites RRI is our first option since it provides the most dynamic routing in the event of a failover for the remote sites.
The problem is that some of our remote sites are not manned and its my understanding that if the tunnel drops after a certain time the reverse route will drop and routing will not come back up unless initiated by the remote side.
I am looking for something more permanent, other than a static route on the local router, that will "hold" this route in place in case the VPN needs to be brought up from the local side.
Our goal is removal of all static routes on the internal LAN.
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Jimmy Larsson, CISSP, CEHNetwork and Security consultantCommented:
RRI should work fine. I guess you use this on the hub site? That means that there is always a static route inserted (and probably redistributed) pointing out tne network(s) at the remote site. Is this full L2L-tunnels with static ip (set peer in hub sites crypto map)? Then either end can initiate the tunnel and the tunnel will go up and down automatically. Anyway, the static route inserted with the reverse-route should never disappear. Does it?

Anyway, there are not many options in ASA compared to IOS-routers. It is more flexible and dynamic to use GRE-tunnels in which you can run your eigrp-routing thru the vpn, but that is not an option with ASA.

Sorry, I dont really understand your problem. It is probably me but can you please expand your question?

jasonbranch10Author Commented:
Actually you seem to have a pretty good grasp of it.

this is the hub site we are talking about.

 I was under the impression that if the VPN went down so would the route which added to the flexiblity and ease of failover to a different head-end server. If thats not the case and the route is always there , that kinda throws a wrench in my failover plans but atleast I know the remote site will always be accessible no matter who initiates the connection.
Hello jasonbranch10,

If you have the remote router participating in the EIGRP routing process then they should have interesting traffic that keeps the tunnels from going down. If you want another method to generate interesting traffic from the remote sites to the main site to keep the tunnels up i have seen "sla monitor" used with good effect. See for a description of the method.

Really all you need to do is set up something like this:

sla monitor 123
 type echo protocol ipIcmpEcho interface outside !--- use an address the firewall can ping that is inside the hub
 num-packets 3
 frequency 10 !--- I would change this to 30

!--- Configure a new monitoring process with the ID 123.  Specify the
!--- monitoring protocol and the target network object whose availability the tracking
!--- process monitors.  Specify the number of packets to be sent with each poll.
!--- Specify the rate at which the monitor process repeats (in seconds).

sla monitor schedule 123 life forever start-time now

!--- Schedule the monitoring process.  In this case the lifetime
!--- of the process is specified to be forever.  The process is scheduled to begin
!--- at the time this command is entered.  As configured, this command allows the
!--- monitoring configuration specified above to determine how often the testing
!--- occurs.  However, you can schedule this monitoring process to begin in the
!--- future and to only occur at specified times.

hope this helps,


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Big Business Goals? Which KPIs Will Help You

The most successful MSPs rely on metrics – known as key performance indicators (KPIs) – for making informed decisions that help their businesses thrive, rather than just survive. This eBook provides an overview of the most important KPIs used by top MSPs.

jasonbranch10Author Commented:
I don't necessarily need the tunnel to stay up...just for the route to be there from an eigrp perspective.

The remote sites are not participating in eigrp.
it is my understanding that the dynamic route will only be available as long as the tunnel is up, to have the route you will need the tunnel.
jasonbranch10Author Commented:
that was my understanding as its either a static on the router...RRI without traffic to keep it up so you lose the route once it drops.... or RRI with an SLA to keep the route in place and the VPN up which would still function properly in the case of a hard outage (hardware or circuit) in which case it would fail to the DR site.
Jimmy Larsson, CISSP, CEHNetwork and Security consultantCommented:
RRI is static, it will not disappear when the tunnel is down.

I think we have some confusions here. We are talking about 2 different scenarios:

1) routing protocol traffic thru tunnel. If you do that the EIGRP updates will keep the tunnel up and the routes will always be there. This is by far the most effective way to do it. However, this is not supported on ASA since crypto maps cannot handle multicast/broadcast traffic.

2) RRI. This is a local thing in each router. Since there is no automatic way to distribute what exists on the remote end of the vpn tunnel all reverse-route does is to look in the crypto access-list and create a static route local in the router/firewall based on the remote networks specified in the proxy acl. They will always be there, there is no way for RRI to "know" if the tunnel is up or down. Since they are only created as static routes you then need to redistribute static routes as needed in your local routing protocol.

Of course SLA can be configured to keep the tunnel always up if needed, but that is not needed to make RRI work.

jasonbranch10Author Commented:

I confirmed your point this morning. We currently have a backup VPN configured to one of our sites and even though the tunnel is down the routes are still being advertised out of the ASA.

So my question now is what is the difference between RRI and just redistributing the static routes themselves?

A cleaner approach?
I offer that it is a question of the function of the approach. RRI can be used in 4 different use cases from lan to lan to a client rri or nem where the remote address space is not known.

both RRI and static routes add routes into the local routing table to be redistributed in the case of RRI it is the result of inference, static is just that, static.

this has been a good thread to follow, thanks for the question!

Jimmy Larsson, CISSP, CEHNetwork and Security consultantCommented:
There is no difference in functionality.

The most common scenario is that VPN is done over internet to which you already have a default route. If that is the case you dont have to care at all.

RRI is just a way to say "whatever is at the remote end of the tunnel should be statically routed to the interface where the crypto map is". If you change your VPN acl you dont have to modify your static routes manually, it is taken care of with RRI. If you (for som weird reason) move the crypto map to another interface, RRI will automatically modify the routes.

But the most important things:
1) RRI-injected static routes remains until the crypto map is reconfigured.
2) If you already have a default route pointing towards the interface where your crypto map is applied you dont have to use RRI.
3) You must redistribute statics into routing protocol if you need to "spread the word" about the remote networks. Same thing here, if you already have a default route pointing to your ASA in your inside environment you dont have to redistribute statics about the remote networks since they are part of the default route and in the same direction.

Good luck!
(I would appreciate some points, but maybe it is to late for that?)


the question is closed and points awarded, but I opened up another one related to where this thread was going...

Have a similar issue, and it doesn't matter if you're using RRI or not...If the SA's time out, then the only way to re-establish the VPN  (configured wity a dynamic VPN map at the head end) is to initiate some interesting traffic at the remote end.

A simple way to do this is have the remote end do a sntp/ntp time request to a ttime source at the head end (or beyond) on a fequency that is a bit less than the SA life-time value specified at the remote end.   That time request traffic need to be included in the remoet ends definition of "interesting traffic".

We do this for 380+ remote VPN sites.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.