jasonbranch10
asked on
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.
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.
ASKER
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.
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.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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.
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.
ASKER
that was my understanding as well....so 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.
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.
/Kvistofta
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.
/Kvistofta
ASKER
Kvistofta
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 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!
-t
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!
-t
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?)
/Jimmy
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?)
/Jimmy
Jimmy-
the question is closed and points awarded, but I opened up another one related to where this thread was going...
https://www.experts-exchange.com/questions/26411645/rri-question-as-a-follow-up-on-Q-26409434.html
cheers!
the question is closed and points awarded, but I opened up another one related to where this thread was going...
https://www.experts-exchange.com/questions/26411645/rri-question-as-a-follow-up-on-Q-26409434.html
cheers!
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.
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.
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?
/Kvistofta