To create source proxy information for a crypto map entry, use the
reverse-route command in crypto map configuration mode. To remove the source proxy information from a crypto map entry, use the
no form of this command.
Effective with Cisco IOS Release 12.4(15)T
reverse-route [static | remote-peer ip-address [gateway] [static]]
no reverse-route [static | remote-peer ip-address [gateway] [static]]
Before Cisco IOS Release 12.4(15)T
reverse-route [static | tag tag-id [static] | remote-peer [static] | remote-peer ip-address [static]]
no reverse-route [static | tag tag-id [static] | remote-peer [static] | remote-peer ip-address [static]]
Syntax Description
tag
tag-id
|
(Optional) Tag value that can be used as a “match” value for controlling redistribution via route maps.
Note
|
Effective with Cisco IOS Release 12.4(15)T, the
tag keyword and
tag-id argument were removed.
|
|
remote-peer
|
(Optional) Indicates two routes: one for the tunnel endpoint, with the next hop being the interface to which the crypto map
is bound.
Note
|
The
remote-peer keyword and its variants (ip-address argument and
gateway keyword) are applicable only to crypto maps.
|
|
ip-address
|
(Optional) If this argument is used without the optional
gateway keyword, there is only one route: the protected subnet. The next hop is determined by the user-added value for the
ip-address argument.
|
gateway
|
(Optional) Used with the
ip-address argument. If the
gateway keyword is used, there are two routes: one to the protected subnet through the remote-tunnel endpoint and the other to the
remote-tunnel endpoint that is determined by the user-added value for the
ip-address argument.
Note
|
The optional
gateway keyword enables the behavior of the
reverse-route
remote-peer
ip-address command syntax used for software releases before Cisco IOS Release 12.3(14)T.
|
|
static
|
(Optional) Creates routes on the basis of crypto ACLs, regardless of whether flows have been created for these ACLs.
|
Command Default
No default behavior or values.
Command Modes
Crypto map configuration (config-crypto-map)
Command History
Release
|
Modification
|
12.1(9)E
|
This command was introduced.
|
12.2(8)T
|
This command was integrated into Cisco IOS Release 12.2(8)T.
|
12.2(11)T
|
This command was implemented on the Cisco AS5300 and Cisco AS5800 platforms.
|
12.2(9)YE
|
This command was integrated into Cisco IOS Release 12.2(9)YE.
|
12.2(14)S
|
This feature was integrated into Cisco IOS Release 12.2(14)S.
|
12.2(13)T
|
The
remote-peer keyword and
ip-address argument were added.
|
12.3(14)T
|
The
static and
tag keywords and
tag-id argument were added.
|
12.2(33)SRA
|
This command was integrated into Cisco IOS Release 12.2(33)SRA.
|
12.4(15)T
|
The
tag keyword and
tag-id argument were deleted. The
gateway keyword was added.
|
12.2SX
|
This command is supported in the Cisco IOS Release 12.2SX train. Support in a specific 12.2SX release of this train depends
on your feature set, platform, and platform hardware.
|
Usage Guidelines
Note |
Security threats, as well as the cryptographic technologies to help protect against them, are constantly changing. For more
information about the latest Cisco cryptographic recommendations, see the
Next Generation Encryption (NGE) white paper.
|
This command can be applied on a per-crypto map basis.
Reverse route injection (RRI) provides a scalable mechanism to dynamically learn and advertise the IP address and subnets
that belong to a remote site that connects through an IPsec VPN tunnel.
When enabled in an IPSec crypto map, RRI will learn all the subnets from any network that is defined in the crypto ACL as
the destination network. The learned routes are installed into the local routing table as static routes that point to the
encrypted interface. When the IPsec tunnel is torn down, the associated static routes will be removed. These static routes
may then be redistributed into other dynamic routing protocols so that they can be advertised to other parts of the network
(usually done by redistributing RRI routes into dynamic routing protocols on the core side).
The
remote-peer keyword is required when RRI is performed in a VRF-Aware IPsec scenario.
Examples
The following example shows how to configure RRI when crypto ACLs exist. The example shows that all remote VPN gateways connect
to the router via 192.168.0.3. RRI is added on the static crypto map, which creates routes on the basis of the source network
and source netmask that are defined in the crypto ACL.
crypto map mymap 1 ipsec-isakmp
set peer 10.1.1.1
reverse-route
set transform-set esp-3des-sha
match address 102
Interface FastEthernet 0/0
ip address 192.168.0.2 255.255.255.0
standby name group1
standby ip 192.168.0.3
crypto map mymap redundancy group1
access-list 102 permit ip 192.168.1.0 0.0.0.255 10.0.0.0 0.0.255.255
Note |
In Cisco IOS Release 12.3(14)T and later releases, for the static map to retain this same behavior of creating routes on the
basis of crypto ACL content, the
static keyword will be necessary, that is,
reverse-route
static.
|
The
reverse-route command in this situation creates routes that are analogous to the following static route CLI (ip route ):
ip route 10.1.1.1 255.255.255.255 192.168.1.1
ip route 10.1.1.1 255.255.255.255 vlan0.1
In the following example, two routes are created, one for the remote endpoint and one for route recursion to the remote endpoint
via the interface on which the crypto map is configured.
reverse-route remote-peer
Examples
The following configuration example shows how to configure RRI for a situation in which there are existing ACLs:
crypto map mymap 1 ipsec-isakmp
set peer 172.17.11.1
reverse-route static
set transform-set esp-3des-sha
match address 101
access-list 101 permit ip 192.168.1.0 0.0.0.255 172.17.11.0 0.0.0.255
The following example shows how RRI-created routes can be tagged with a tag number and then used by a routing process to
redistribute those tagged routes via a route map:
crypto dynamic-map ospf-clients 1
reverse-route tag 5
router ospf 109
redistribute rip route-map rip-to-ospf
route-map rip-to-ospf permit
match tag 5
set metric 5
set metric-type type1
Device# show ip ospf topology
P 10.81.7.48/29, 1 successors, FD is 2588160, tag is 5
via 192.168.82.25 (2588160/2585600), FastEthernet0/1
The following example shows that one route has been created to the remote proxy via a user-defined next hop. This next hop
should not require a recursive route lookup unless it will recurse to a default route.
reverse-route remote-peer 10.4.4.4
The previous example yields the following before Cisco IOS Release 12.3(14)T:
10.0.0.0/24 via 10.1.1.1 (in the VRF table if VRFs are configured)
10.1.1.1/32 via 10.4.4.4 (in the global route table)
And this result occurs with RRI enhancements:
10.0.0.0/24 via 10.4.4.4 (in the VRF table if VRFs are configured, otherwise in the global table)
Examples
In the following example, routes are created from the destination information in the access control list (ACL). One route
will list 10.2.2.2 as the next-hop route to the ACL information, and one will indicate that to get to 10.2.2.2, the route
will have to go via 10.1.1.1. All routes will have a metric of 10. Routes are created only at the time the map and specific
ACL rule are created.
crypto map map1 1 ipsec-isakmp
set peer 10.2.2.2
reverse-route remote-peer 10.1.1.1 gateway
set reverse-route distance 10
match address 101
Configuring RRI with Route Tags 12.4(15)T or later: Example
The following example shows how RRI-created routes can be tagged with a tag number and then used by a routing process to
redistribute those tagged routes via a route map:
crypto dynamic-map ospf-clients 1
set reverse-route tag 5
router ospf 109
redistribute rip route-map rip-to-ospf
route-map rip-to-ospf permit
match tag 5
set metric 5
set metric-type type1
Device# show ip ospf topology
P 10.81.7.48/29, 1 successors, FD is 2588160, tag is 5
via 192.168.82.25 (2588160/2585600), FastEthernet0/1