cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

1056
Views
0
Helpful
3
Replies

Redundant GREoverIPSEC tunnels

i try to implement the following configuration:
1. branch - CISCO891-PCI-K9, c890-universalk9-mz.157-3.M6.bin
2. branch has 2 ISP uplinks
3. HQ has 2 terminating gateways
4. each branch by using 2 loopbacks create 4 tunnels for redundancy:
tu1: Loopback1 - ISP1 - GW1 - Loopback1
tu2: Loopback1 - ISP1 - GW2 - Loopback1
tu3: Loopback2 - ISP2 - GW1 - Loopback2
tu4: Loopback2 - ISP2 - GW2 - Loopback2

 

         ISP1 \
        /      \   - ISP - GW1
BRANCH <         <    
        \      /   - ISP - GW2
         ISP2 /

 

 

5. ISP1 is default route with tracking, ISP2 with increased AD.

===
On the real hardware tu3 & tu4 keepalives does not work and interfaces goes to down state:
Tunnel1 172.29.44.2 YES NVRAM up up
Tunnel2 172.31.44.2 YES NVRAM up up
Tunnel3 172.29.44.22 YES NVRAM up down
Tunnel4 172.31.44.22 YES NVRAM up down

 

'Debug tunnel keepalive':

Jul 24 15:43:20.486 MSK: Tunnel1: keepalive received, 172.29.29.29->172.30.44.42 (len=24 ttl=253), resetting counter
Jul 24 15:43:20.486 MSK: Tunnel2: keepalive received, 172.31.31.31->172.30.44.42 (len=24 ttl=253), resetting counter
Jul 24 15:43:20.606 MSK: Tunnel4: sending keepalive, 172.31.31.32->172.30.44.53 (len=24 ttl=255), counter=5966
Jul 24 15:43:30.483 MSK: Tunnel1: sending keepalive, 172.29.29.29->172.30.44.42 (len=24 ttl=255), counter=1
Jul 24 15:43:30.483 MSK: Tunnel2: sending keepalive, 172.31.31.31->172.30.44.42 (len=24 ttl=255), counter=1
Jul 24 15:43:30.483 MSK: Tunnel3: sending keepalive, 172.29.29.30->172.30.44.53 (len=24 ttl=255), counter=1368
Jul 24 15:43:30.487 MSK: Tunnel1: keepalive received, 172.29.29.29->172.30.44.42 (len=24 ttl=253), resetting counter
Jul 24 15:43:30.487 MSK: Tunnel2: keepalive received, 172.31.31.31->172.30.44.42 (len=24 ttl=253), resetting counter
Jul 24 15:43:30.607 MSK: Tunnel4: sending keepalive, 172.31.31.32->172.30.44.53 (len=24 ttl=255), counter=5967
Jul 24 15:43:40.483 MSK: Tunnel1: sending keepalive, 172.29.29.29->172.30.44.42 (len=24 ttl=255), counter=1
Jul 24 15:43:40.483 MSK: Tunnel2: sending keepalive, 172.31.31.31->172.30.44.42 (len=24 ttl=255), counter=1
Jul 24 15:43:40.483 MSK: Tunnel3: sending keepalive, 172.29.29.30->172.30.44.53 (len=24 ttl=255), counter=1369
Jul 24 15:43:40.487 MSK: Tunnel1: keepalive received, 172.29.29.29->172.30.44.42 (len=24 ttl=253), resetting counter
Jul 24 15:43:40.487 MSK: Tunnel2: keepalive received, 172.31.31.31->172.30.44.42 (len=24 ttl=253), resetting counter

 

Hovewer 'show crypto session' show that sessions is UP:
#sh crypto session
Crypto session current status

Interface: GigabitEthernet0
Session status: UP-ACTIVE
Peer: GW1 port 500
Session ID: 0
IKEv1 SA: local ISP1_IP1/500 remote GW1/500 Active
IPSEC FLOW: permit ip host 172.30.44.42 host 172.29.29.29
Active SAs: 2, origin: crypto map

Interface: GigabitEthernet0
Session status: UP-ACTIVE
Peer: GW2 port 500
Session ID: 0
IKEv1 SA: local ISP1_IP1/500 remote GW2/500 Active
IPSEC FLOW: permit ip host 172.30.44.42 host 172.31.31.31
Active SAs: 2, origin: crypto map

Interface: FastEthernet8
Session status: UP-ACTIVE
Peer: GW1 port 4500
Session ID: 0
IKEv1 SA: local ISP2_IP1/4500 remote GW1/4500 Active
IPSEC FLOW: permit ip host 172.30.44.53 host 172.29.29.30
Active SAs: 2, origin: crypto map

Interface: FastEthernet8
Session status: UP-ACTIVE
Peer: GW2 port 4500
Session ID: 0
IKEv1 SA: local ISP2_IP1/4500 remote GW2/4500 Active
IPSEC FLOW: permit ip host 172.30.44.53 host 172.31.31.32
Active SAs: 2, origin: crypto map

If I shutdown ISP1 tu3&tu4 comes UP and start to work.

The same configuration in GNS3 works like a charm.

Maybe this is some kind of the platform limitation? I have no idea left what to look for.

 

1 ACCEPTED SOLUTION

Accepted Solutions

Hi,
Use Front Door VRF and configure the outside interfaces for each ISP in their own VRF

HTH

View solution in original post

3 REPLIES 3

Ok, gns3 is not stating interfaces down because, i did not create isp1 access-list that is blocking foreign ip addresses.
so the main question is how to hardcode outgoing interface for tun3&tun4crypto traffic? Because now it seems like tunnel 3 keepalive gets encrypted and sent through default route.

Hi,
Use Front Door VRF and configure the outside interfaces for each ISP in their own VRF

HTH

View solution in original post

yes, i know about FVRF but was thinking about could it be done with nonVRF configuration.