Introduction
This document describes issues with RRI and recursive routelookups in certain IOS codes
Core Issue
In normal site-to-site VPN deployments, we usually create a static/default route to define the exit path for traffic which is part of the encryption domain. This forces the interesting traffic to exit from the interface on which the crypto map is defined thus either initiating the IKE exchange or causing the the packet to get encrypted using an existing Security Association(SA). In some scenarios however, like when one(or both) side of a VPN tunnel is doing HSRP or using other such HA protocols, sometimes static routes cannot be used to define exit paths for the remote network. Instead in these cases we need to rely on a mechanism called Reverse Route Injection to inject routes into our routing table for the remote networks However, since IOS v15.0(1)M, there is a change in behavior in RRI when "reverse-route" is configured and when the crypto map is applied to a multi-access interface (eg., ethernet). For this configuration to work, the router will try to arp for the crypto peer address to populate the CEF adjacency for the remote protected network. As a result, if the upstream router does not have proxy arp enabled (very common in provider environment), then arp will fail and the egress traffic toward the peer will be dropped due to incomplete CEF adjacency.
The symptoms can be observed with debug arp and show adj output:
hub#
*Apr 23 15:46:11.627: IP ARP: creating incomplete entry for IP address: 20.1.1.1 interface Ethernet0/0
*Apr 23 15:46:11.627: IP ARP: sent req src 10.1.1.1 aabb.cc01.1800,dst 20.1.1.1 0000.0000.0000 Ethernet0/0
*Apr 23 15:46:13.471: IP ARP: creating incomplete entry for IP address: 1.1.1.2 interface Ethernet1/0
hub#sh adj
Protocol Interface Address
IP Ethernet0/0 10.1.1.2(11)
IP Ethernet0/0 20.1.1.1(5) (incomplete)
IP Ethernet1/0 1.1.1.2(7)
Resolution
In order to fix this issue, one can use the gateway option while enabling reverse-route injection. This can be done using the optional remote-peer keyword. When this keyword is used, it indicates two routes: one for the tunnel endpoint, with the next hop being the interface to which the crypto map is bound. If it is used with the optional ip-address argument, then the next hop is determined by the user-added value for the ip-address argument.
Command Syntax: reverse-route remote-peer [static] | remote-peer ip-address [static]
The static keyword at the end can be used to make the routes persistent. In some cases, e.g. cases where there is no default gateway defined or the default gateway uses an interface which does not have the correct crypto-map enabled , using this keyword is necessary so that even when the tunnel is not up, the router is aware of how to reach the remote protected network. Otherwise, the router will never be able to initiate the tunnel, even though once the tunnel is up the router will be capable of routing traffic.
Related Information
- Reverse Route Injection
- CSCtg41606
