لطفا منتظر باشید ...
Reverse Route Injection
Reverse Route Injection (RRI) is a mechanism used to integrate route availability to IPSec state. Without RRI, routing decisions are made independent of the IPSec peer state. A route to the secure subnet of the remote peer must exist. The route might be statically configured or derived through some form of end-to-end dynamic routing exchange. Coupling the IPSec security association state with the viability of a route path simplifies the end-to-end fault recovery process. The Cisco RRI process inserts a static route associated with an IPSec peer into the forwarding information base. The availability of the route in the forwarding information base may be propagated to adjacent routers by redistributing the static routes. In this section, you'll review two scenarios for RRI:
Static IPSec peers
Dynamic IPSec peers
A static IPSec peer is one in which the crypto maps and the corresponding IPSec security policies and proxies are pre-defined (site-to-site). In the static IPSec peer case, an IPSec session can be initiated either from the hub or the spoke. A dynamic IPSec peer is one in which the spoke side or client initiates IPSec (telecommuter) session and the receiver's IPSec proxies are not pre-defined.
Figure 3-5 shows an application for RRI for static IPSec peers.
Figure 3-5. Application of RRI in the Context of IPSec
[View full size image]
In Figure 3-5, VPN-GW1-EAST is the head-end router, which terminates IPSec from SPOKE- 1-EAST. With RRI configured on VPN-GW1-EAST, the remote subnet protected by SPOKE-1-EAST (that is, 10.0.68.0/24) is inserted into VPN-GW1-EAST's forwarding table as a static route. These subnets can be advertised further by redistributing the static route to the routing protocol of choice; in example 3-4, it is redistributed into OSPF. Example 3-4 shows VPNGW1-EAST's configuration along with a snapshot of the routing table.
Example 3-4. RRI Configuration
vpn-gw1-east
!
version 12.2
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname vpn-gw1-east
!
logging queue-limit 100
!
ip subnet-zero
!
!
ip domain name cisco.com
!
!
crypto isakmp policy 1
authentication pre-share
crypto isakmp key cisco address 9.1.1.146
crypto ipsec security-association idle-time 120
!
crypto ipsec transform-set test esp-3des esp-sha-hmac
!
crypto map vpn 1 ipsec-isakmp
set peer 9.1.1.146
set transform-set test
match address 100
reverse-route remote-peer 9.1.1.33
!
!
interface FastEthernet0/0
ip address 9.1.1.35 255.255.255.248
speed 100
full-duplex
no cdp enable
crypto map vpn
!
interface FastEthernet0/1
ip address 10.1.1.2 255.255.255.0
speed 100
full-duplex
no cdp enable
!
router ospf 1
log-adjacency-changes
network 10.1.1.0 0.0.0.255 area 0
redistribute static subnets
!
ip classless
ip route 0.0.0.0 0.0.0.0 9.1.1.33
!
!
access-list 100 permit ip 10.1.1.0 0.0.0.255 10.0.68.0 0.0.0.255
!
!
line con 0
line aux 0
line vty 0 4
login
!
end
vpn-gw1-east#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is 9.1.1.33 to network 0.0.0.0
9.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 9.1.1.32/29 is directly connected, FastEthernet0/0
S 9.1.1.146/32 [1/0] via 9.1.1.33
10.0.0.0/24 is subnetted, 2 subnets
C 10.1.1.0 is directly connected, FastEthernet0/1
S 10.0.68.0 [1/0] via 9.1.1.146
S* 0.0.0.0/0 [1/0] via 9.1.1.33
Note
The behavior of RRI injecting a route into the routing table has changed as of Cisco IOS Software Release 12.3(14)T onwards. A new option has been added in the RRI command reverse-route remote-peer <ip address> static. Without the static keyword, a route is injected into the routing table only after successful establishment of IPSec SA. The "static" keyword is required if the static route has to be injected into the routing table without an SA being established in advance (which was the legacy behavior discussed in example 3-4).
RRI functionality for dynamic peers behaves exactly the same way as the static IPSec peers, except that the route to the spoke subnet is injected only after the IPSec SAs are successfully established.
RRI also gives the option of adding a route to the destination tunnel endpoint address, which is important in case the interface where the crypto map is applied is a broadcast interface, such as Ethernet. If an IP address is not specified, the route will point to the interface where the crypto map is bound. For remote access clients (for example, telecommuter clients) that use dynamic crypto maps, the route injection is tightly coupled with creation of IPSec security associations. In this case, a route will be dynamically created based on the source proxy ID and mask passed by the client during Quick Mode.
Today, when the physical link of an IPSec gateway (hub) goes down, SAs are not cleared until the IPSec SA timer expires (idle timeout or IPSec SA lifetime). For dynamic IPSec peers, RRI routes are purged from the routing table when the SAs are cleared; if a redundant hub site is present, the spokes automatically initiate IKE/IPSec toward the new hub, and all is fine. However, on static IPSec peers, the failure of a link on the IPSec gateway causes some issues with RRI.
You saw earlier that for static peers (with the static keyword), the RRI routes are injected into the routing table irrespective of whether SAs are established. This means that even if the SAs time out, the RRI route is never purged from the original hub's routing table. Since the RRI route is never purged, traffic destined to the RRI-injected subnet is always drawn to the original hub where the SAs no longer exist. If the IPSec SAs cannot be reestablished by the original hub for the destination spoke, the traffic will be "black-holed" at this hub. This issue is resolved by combining RRI with the Cisco Hot Standby Routing Protocol (HSRP), which is discussed in the next section.
RRI and HSRP
HSRP is commonly used to provide failover between routers. HSRP tracks the state of router interfaces and provides a failover mechanism between primary and secondary devices. This functionality can be exploited to provide IPSec redundancy. A simple mechanism to provide IPSec redundancy using HSRP is illustrated in Figure 3-6.
Figure 3-6. IPSec Redundancy Using HSRP
Chapter 6, "Designing Fault-Tolerant IPSec VPNs." Example 3-5 illustrates how you would map the standby IP address to the crypto map on VPN-GW1-EAST followed by the configuration on SPOKE-1- EAST. The configuration would be the same on VPN-GW2-EAST, aside from the IP address on the physical interface and the HSRP standby priority.
Example 3-5. IPSec and HSRP Configuration
vpn-gw1-east
crypto isakmp policy 1
authentication pre-share
crypto isakmp key cisco address 9.1.1.146
crypto isakmp keepalive 60 3
!
!
crypto ipsec transform-set test esp-3des esp-sha-hmac
!
crypto map vpn 1 ipsec-isakmp
set peer 9.1.1.146
set transform-set test
match address 100
reverse-route remote-peer 9.1.1.33
!
!
interface FastEthernet0/0
ip address 9.1.1.35 255.255.255.248
duplex full
random-detect
standby delay minimum 30 reload 60
standby ip 9.1.1.34
standby priority 105
standby preempt
standby name ipsec
standby track FastEthernet2/0
crypto map vpn redundancy ipsec
!
interface FastEthernet2/0
ip address 10.1.1.2 255.255.255.0
duplex full
standby 1 ip 10.1.1.1
standby 1 priority 105
standby 1 preempt
standby 1 name ip
standby 1 track FastEthernet0/0
!
router ospf 1
log-adjacency-changes
redistribute static subnets
network 10.1.1.0 0.0.0.255 area 0
!
ip classless
ip route 0.0.0.0 0.0.0.0 9.1.1.33
no ip http server
!
access-list 100 permit ip 10.1.1.0 0.0.0.255 10.0.68.0 0.0.0.255
!
!
line con 0
stopbits 1
line aux 0
stopbits 1
line vty 0 4
login
!
end
spoke-1-east:
crypto map vpn 1 ipsec-isakmp
set peer 9.1.1.34
set transform-set test
match address 100
!
interface Serial0/0
ip address 9.1.1.146 255.255.255.252
crypto map vpn
!
interface Ethernet0/1
ip address 10.0.68.1 255.255.255.0
half-duplex
!
ip classless
ip route 0.0.0.0 0.0.0.0 9.1.1.145
!
access-list 100 permit ip 10.0.68.0 0.0.0.255 10.1.1.0 0.0.0.255
Note
HSRP runs only over Ethernet interfaces. Although it cannot run over serial interfaces, it can track the state of any interface.
HSRP's interaction with RRI IPSec provides a good IPSec high-availability solution. The state of several important interfaces associated with routing and crypto on VPN-GW1-EAST may be mutually tracked such that a failure on any of the interfaces is synchronized; the routes and crypto termination are all revoked on VPN-GW1-EAST such that the responsibility may be transferred to the secondary router, VPN-GW2-EAST. One thing this solution does not provide is IPSec statefulness. This means that, from the perspective of SPOKE-1-EAST, it has to initiate a completely new IKE and IPSec security association to VPN-GW2-EAST's HSRP address because VPN-GW2-EAST has no IKE or IPSec SA to SPOKE-1-EAST. Also, the spoke won't re-initiate the IKE/IPSec SAs with the standby router until IKE or DPD times out.
A better high-availability solution is one in which the connection state can be shared between the IPSec gateways VPN-GW1-EAST and VPN-GW2-EAST. The principle benefit to the stateful failover model is that the remote spoke (VPN-SPOKE1-EAST) doesn't need to renegotiate an IPSec security association with a standby peer because a valid security association already exists. Stateful failover is further discussed in the next section.
