DMVPN- I MUST use "shared" protection on 2 tunnels with same source?

[jmaxwellUSAF]

Hello.

Because the "tunnel protection ipsec profile MYPROFILE shared " technology is complicating things more than simplifying things, I want to NOT use this command.

The below thread and linked literature states that I MUST use the shared command...

Separate IPSec Profiles for DMVPN Tunnel Protection - Cisco Community

Sharing IPSec with Tunnel Protection  [Support] - Cisco Systems

• All tunnels with the same tunnel source interface must use the same IPsec profile and the shared keyword with the tunnel protection command. The only exception is when only point-to-point generic route encapsulation (GRE) tunnel interfaces are configured with the same tunnel source in the system and associated with unique tunnel destination IP addresses. Shared tunnel protection can be used when the same local address between point-to-multipoint and point-to-point GRE interfaces are shared only if the device is an initiator of the point-to-point tunnels and not a responder.

>> But it seems to me that this literature implies that I intend (want) to use this "shared" command. I do NOT want to use this shared command with my same interface DMVPN tunnels.

QUESTION: With 2 or more DMVPN tunnels using the same interface, can I just use separate tunnel protection profiles, with different separate transform sets? ,or not use tunnel protection at all? (My intent is NOT to use the shared command.)

Thank you.

---

EDIT-- I just checked a production device that proves that 2 DMVPN (at least hub) tunnels can exist on eth same interface without using "shared" tunnel protection. (see below config.) BUT, the first tunnel is using an "ip policy route map". Is this route map necessary for a config to work without using "shared"?

interface Tunnel200
bandwidth 100000
ip address 192.168.12.1 255.255.255.0
no ip redirects
ip mtu 1400
no ip next-hop-self eigrp 10
no ip split-horizon eigrp 10
ip nhrp authentication MYPASSWORD
ip nhrp network-id 200
ip nhrp redirect
ip tcp adjust-mss 1360
ip policy route-map PIZZA
tunnel source GigabitEthernet0/1
tunnel mode gre multipoint
tunnel key 200
tunnel protection ipsec profile MYPROFILE1
end

--------
interface Tunnel201
ip address 192.168.14.1 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp authentication MYPASSWORD
ip nhrp network-id 201
ip nhrp redirect
ip tcp adjust-mss 1360
tunnel source GigabitEthernet0/1
tunnel mode gre multipoint
tunnel key 201
tunnel protection ipsec profile MYPROFILE2
end

[MHM Cisco World · Accepted solution]

no need shared keyword if you use different profile under each tunnel.

[Aref Alsouqi]

May I ask why you don't want to use a share protection profile? the requirement to use a shared protection profile when the source interface is the same would only be applicable if the protection profile is the same, and the reason of this is to avoid any potential wrong association of the IPsec SAs to the wrong tunnel interface. But as already mentioned by @MHM Cisco World if you use different protection profile then you don't have to worry about the "shared" command as it wouldn't apply in that case.

[gajownik]

If you use GRE multipoint interfaces using the same tunnel source and you apply IPsec encryption on top of that then you must use the same tunnel protection ipsec profile with a shared option.

We have seen cases when VPN tunnel is initiated to the box and traffic ends up on the wrong tunnel and gets dropped if the shared keyword is not used.

Of course without "shared" option it might work in some scenarios, but this type of configuration is not supported by Cisco and if you open a case with TAC you will be informed to correct your design before we can continue troubleshooting.