This topic is to discuss the following lesson:
very nice lesson and well explained. I would just need a clarification here.
In all FlexVPN examples, the tunnel mode you are using is the default one. This means GRE. I tried the labs with a small change under the tunnel interfaces and virtual-templates:
tunnel mode ipsec ipv4
This leads to a direct IPSec encapsulation avoiding the GRE overhead. However, the spoke to spoke direct connectivity is not working. The NHRP redirection fails completely. Hub and spoke communication and spoke to spoke via the hub is fine though.
I am wondering if this is related to my specific software image or it is a normal behavior. Maybe NHRP is only working with GRE encapsulation like we do with classic DMVPN? Any thoughts on this would be much appreciated?
Unfortunately, NHRP only works with GRE tunnels and doesn’t function with IPsec. Take a look at this Cisco Community thread which details this fact.
The reason is that NHRP can be thought of as a Layer 2 protocol. When encapsulated within a GRE tunnel, it is tunneled as is. With native IPSec tunneling, it attempts to send a Layer 2 protocol over an infrastructure designed for Layer 3, so it fails.
I hope this has been helpful!
Many thanks Laz. Indeed very helpful!
None of the above commands solves it immediately. If you find a way that deletes the virtual-access interface(s) right away (except for a reboot), let me know.
Hello, admin shutting the remote (static) VTIs brings down the virtual-access interface straight away allowing you to make changes and “unshutting” the static VTIs when you are done applying changes to the DVTI
Great, thanks for sharing your findings with us! I will let Rene know.
why we don’t use
virtual-template 1 under crypto ikev2 profile in spokes?
When configuring a crypto ikev2 profile, the minimum requirements that must be configured are the authentication method and a match statement of some kind. This is confirmed by the message that is displayed when creating an IKEv2 profile:
R1(config)#crypto ikev2 profile MY_PROFILE IKEv2 profile MUST have: 1. A local and a remote authentication method. 2. A match identity or a match certificate or match any statement. R1(config-ikev2-profile)#
The virtual template contains parameters that can be cloned and used multiple times by the crypto IKEv2 profile, including QoS, NetFlow, or ACLs. However, it is not a mandatory configuration parameter. The following is the configuration of the crypto IKEv2 profile in Spoke 1. Notice that the prerequisites are all fulfilled:
crypto ikev2 profile IKEV2_PROFILE match identity remote fqdn HUB.FLEXVPN.LAB match identity remote fqdn SPOKE2.FLEXVPN.LAB identity local fqdn SPOKE1.FLEXVPN.LAB authentication remote pre-share authentication local pre-share keyring local IKEV2_KEYRING aaa authorization group psk list FLEXVPN_LOCAL IKEV2_AUTHORIZATION
Note that a dynamic VTI is being configured on the spokes, so the virtual template is being created and then referenced by the Tunnel 0 interface.
I hope this has been helpful!