DMVPN issue with dual IPS links at branch end

[Erik Jacobsen]

I have a setup (see drawing) where I have

dual ISP links at branch end, with with wireless and another with 3G,

Wireless should always be the primary path, when it is working (it is a ship so when it is in harbor)

If I use OSPF then it works fine the failover, but as soon as I enable IPSEC on the tunnel, then it will only failover once, and it will not failover to the primary again, without rebooting the router, and then it works for one failover again.

I'm using tracking also, since there is no interfaces there is going down

Are there anyone there have a working config, where ec. in the headend (normal setup) there is dual ISP links to the same router or ofcause the same as I have.

I'm willing to use any kind of protocols to get it to work, so RIPv2 (preferred), EIGRP, OSPF, tracking, IP SLA

[Erik Jacobsen]

Hi Laurent,

I have now reconfiged my setup with RIP v2 instead, because this is actually what is running with the customer, and it looks like it is working correct.

will you not agree that the traffic is going over the primary link here, the reason why I'm asking is because I can see that both tunnels are choosen in the "sh ip route vrf dmvpn"

But with the "sh ip route" it look correct.

I have tried to failover and it look fine. I just want to make sure when the primary is up, as it is with below show commands, that the traffic is also going this way.

remote#sh 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, su - IS-IS summary, 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 192.168.1.1 to network 0.0.0.0

     88.0.0.0/24 is subnetted, 1 subnets
C       88.1.1.0 is directly connected, Vlan50
C    192.168.1.0/24 is directly connected, FastEthernet0
S*   0.0.0.0/0 [1/0] via 192.168.1.1
remote#

remote#sh ip route vrf dmvpn

Routing Table: dmvpn
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, su - IS-IS summary, 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 10.1.2.1 to network 0.0.0.0

     10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
R       10.3.0.0/16 [120/1] via 10.1.2.1, 00:00:07, Tunnel1
                    [120/1] via 10.1.1.1, 00:00:10, Tunnel0
C       10.1.2.0/24 is directly connected, Tunnel1
C       10.1.1.0/24 is directly connected, Tunnel0
C       10.111.0.0/24 is directly connected, Vlan60
R*   0.0.0.0/0 [120/1] via 10.1.2.1, 00:00:07, Tunnel1
               [120/1] via 10.1.1.1, 00:00:10, Tunnel0
remote#

router rip
offset-list 5 out 3 FastEthernet2
!
address-family ipv4 vrf dmvpn
  redistribute static
  network 10.0.0.0
  no auto-summary
  version 2
exit-address-family

access-list 5 permit 88.1.1.0 0.0.0.255

It don't look like the "offset-list" command is actually doing anything, so I could probably just remove this.

Best regards,

Erik Jacobsen

[Laurent Aubert]

I'm glad we finaly make it works !!

As we already talked about, in reality only one tunnel will be UP at a time (Did you remove the ACL on router 3 and 4 ?) so you will not face this situation where you are load-balancing over the two tunnels. It also means the offset is not actually required.

Unfortunately, I have no plan to participate to the Networkers but we never know so thanks for the invite and will let you know if I can make it.

Laurent.

[Erik Jacobsen]

Hi Laurent,

BUT without IPSEC it works well everything. so if anyone else is looking for a similar setup, here are the configurations from my hub and remote, and the test to prove it works.

Life would be so much easier without IPSEC, and maybe not as secure :-)

Best regards

Erik Jacobsen

[kav]

your setup fails with IPSec because in "tunnel protection"-mode every IPSec packet will be proccessed in context of one of your tunnels on hub where encrypted packet will arrive and if tunnel key does not match, packet will be droped

recomendation - use exclusive tunnel source address or tunnel source interface for every tunnel interface

P.S.: in "crypto map" setups encrypted packet will be proccessed in context of all tunnels with matching source/destination addresses

and in "crypto map" setups GRE-keepalive feature will also work

don't ever use "tunnel key", it's useless in tunnel protection and leads to context-switching of CPU for every packet

P.P.S.: i have same task and working on to solve it. i'll try to not forget to post here a results

[Erik Jacobsen]

Thanks for your help,

Laurent have just given me the working solution, so check my response to him, here is a working configuration.

Best regards,

Erik Jacobsen

[kav · Accepted solution]

here is working, "multiple spokes/hubs with multiple ISPs to multiple spokes/hubs with multiple ISPs" example ( MSHWMI-2-MSHWMI :] )

techs used: dmvpn, ipsec, vrf, bgp (mostly for inter-vrf route redistribution (route-leaking)) (you can also use some IGP routing and redistribute its routes with BGP-inter-vrf-only for zero-touch configuration)

because of BGP is only routing protocol i used here, it is not 'zero-touch'-configurable, sorry. BGP - the best!

[Erik Jacobsen]

Hi Alex,

I totally agree with you, that BGP could also have done the trick. The problem was not the routing protocol, but the IPSEC, and I can see in your configuration, you also have 2 different IPsec profiles, and this is doing the trick.

But thanks for your input.

Best regards,

Erik Jacobsen