Hello Brian
Yes, that explanation makes sense. You can also add the fact that all of the IKE policies are configured not within a VRF configuration mode, but within the global configuration mode. This also reinforces the fact that these policies are global and can be accessed by any entity within the device.
Thanks for sharing that information, it’s always helpful and adds to the value of the forum.
I hope this has been helpful!
Laz
Hello,
I hope you are all doing well.
If we have crypto keepalive configured in global settings, do we still need keepalive configured under VTI interface and how this command works under tunnel interface?
Thanks for help.
Best regards,
Hello Milan
For the benefit of others reading, the crypto keepalive feature is part of what is known as the IPsec Dead Peer Detection Periodic Message Option. You can find out more about this at this NetworkLessons Note about crypto keepalive.
Now concerning the VTI keepalives, according to this Cisco documentation:
A limitation of VTI is the lack of an interface keepalive equivalent to a GRE keepalive. Many network managers prefer to use a GRE keepalive and a redistributed static route to the tunnel interface instead of using a routing protocol hello and adjacency over the interface. Although the routing protocol and GRE keepalive can be functionally equivalent, there may be less CPU overhead incurred by using a GRE keepalive.
So the keepalive on a VTI interface essentially does nothing. So you must employ the keepalive on the global crypto configuration.
I hope this has been helpful!
Laz
Hello,
It is very helpful, thank you for explanation 
Hello Rene, thanks for the class.
I have some queries:
In a DVTI solution, is Spoke to Spoke communication possible?
Why can’t I put an ip directly on the tunnel interfaces of the Spokes?
How is it possible to establish eigrp neighbor adjacencies with different network segments as it operates in this scenario?
How spoke routers can learn each other’s networks if you didn’t disable split horizon on the hub?
In which scenarios would it be convenient to use this solution?
When I want to edit a Template interface configuration, I get this message: % Virtual-template config is locked, activate vaccess present
I already did everything but nothing. Thanks again.
Hello Christan
No, the communication can only take place via the hub. This is because each spoke has a VPN tunnel to the hub. If you want to have spoke-to-spoke communication with security, you should use a different solution, such as DMVPN over IPSec.
You can. But the point here is that this configuration uses the loopback address as the IP address of the tunnel of each spoke. This is preferrable because a loopback will not go down like a physical interface in the event of a failure. You can see later on that the tunnel interfaces of R2 and R3 are unnumbered, but they’re using the IP address of their loopbacks respectively.
I assume your confusion comes from the fact that the IP addresses of the tunnels of the routers are 1.1.1.1 2.2.2.2 and 3.3.3.3. Since these are in different subnets, how can EIGRP create adjacencies? Keep in mind that when you create point-to-point tunnels, the IP addresses on the end of each one don’t really matter. By definition, point-to-point means that there is only one device on the other end of the link. Therefore, EIGRP recognizes this, and since the network command under EIGRP refers to the tunnel interface, it simply creates a neighborship with any EIGRP device on the other end.
Split horizon states that you must not send out an advertisement about a route via the same interface from which it was learned. In this case, we have two different tunnel interfaces, one to each spoke. So if R1 learns about the 192.168.2.0/24 network from R2 via one tunnel, and advertises this network to R3 via the other tunnel, it is not violating the split horizon rule. The tunnels themselves are different interfaces, even though they are using the same physical interface.
If you have a small office and you have three or four remote offices, and your traffic isn’t very heavy, then this would be a quick and secure solution. However, depending upon the speeds of your ISP connections and the volume of traffic you expect between sites, it could quickly saturate your internet connection at the hub.
The other great thing here is that you can carry your spoke router with you, say to a hotel, or a friend’s house, connect it to any internet connection, and you would automatically gain secure access to the networks at your hub and other spoke locations.
According to this Cisco documentation:
…the virtual template lock allows you to modify or delete a virtual template of type tunnel only when the virtual template is not associated with any cloned virtual access interfaces. The virtual template lock prevents dynamic command updates from virtual templates to the cloned virtual access interfaces, which can cause instability in some scenarios.
Take a look at the documentation to learn more about how you can modify an existing virtual template configuration.
I hope this has been helpful!
Laz