RRI is a good solution for topologies that require encrypted traffic to be diverted to a VPN router and all other traffic to a different router. In these scenarios, RRI eliminates the need to manually define static routes on devices.
RRI is not required if a single VPN router is used, and all traffic passes through the VPN router during its path in to and out of the network.
If you choose to manually define static routes on the VPN router for remote proxies and have these routes permanently installed in the routing table, RRI should not be enabled on the crypto map instance that covers the same remote proxies. In this case, there is no possibility of user-defined static routes being removed by RRI.
Routing convergence can affect the success of a failover based on the routing protocol used to advertise routes (link state versus periodic update). We recommend that a link state routing protocol such as OSPF be used to help speed convergence time by ensuring that routing updates are sent as soon as a change in routing state is detected.
In the following example, RRI is enabled for mymap 1, but not for mymap 2. Upon the application of the crypto map to the interface, a route is created based on access-list 101 analogous to the following:
IP route 172.17.11.0 255.255.255.0 FastEthernet 0/0crypto map mymap 1 ipsec-isakmp set peer 172.17.11.1 reverse-route set transform-set my-transform-set match address 101crypto map mymap 2 ipsec-isakmp set peer 10.1.1.1 set transform-set my-transform-set match address 102access-list 101 permit ip 192.168.1.0 0.0.0.255 172.17.11.0 0.0.0.255 access-list 102 permit ip 192.168.1.0 0.0.0.255 10.0.0.0 0.0.255.255interface FastEthernet 0/0 crypto map mymap