DMVPN with mgre and IKEv2

[Mr Brightside]

Hello,

Wondering if there is a good document with some examples  on DMVPN using IKE v2.

Thanks!

[Marcin Latosiewicz]

Farhad,

Quite frankly, if you're considering IKEv2 you should be thinking FlexVPN not DM. DMVPN is great and it will work great with IKEv2 instead of IKEv1, but Flex gives you much more.

M.

[Mr Brightside]

Thanks for the prompt reponse, Marcin.

I am wondering if flex supports mgre, I am planning dual hub scenario.

[Javier Portuguez]

Farhad,

Flex VPN offers a routable interface as well. I think you may expect pretty much the same features offered by DMVPN plus more.

Thanks.

Portu.

[Mr Brightside]

Alright, does it support mGRE?

I need spoke to be able to talk EIGRP to two hubs at the same time.

[Javier Portuguez]

Yes it does.

Further information:

Cisco IOS FlexVPN Data Sheet

Thanks.

Portu.

[Marcin Latosiewicz]

Portu, Farhad,

Well mGRE is not really needed for Flex.

mGRE is what made DMVPN so awesome, but it also came to limit it.

mGRE was introduced to have one interface terminating multiple logical connections - but it came to limit per-spoke features.

By using VTs instead of tunnel interfaces interfaces, we're still able to have same functionality as DMVPN plus more.

Bottom line, instead of using one interface for every connection in flex, we're using one virtual-template to spawn virtual access interfaces for connections as needed. (Typical DMVPN-like spoke will require a tunnel interface + VT if you want spoke-to-spoke tunnels and features).

M.

[Javier Portuguez]

Marcin,

I really appreciate the  input.

I have been testing and learning from this new and great technology as I go.

I think people should start migrating to this new VPN tech since it offers a new way to standarize the entire VPN deployment, instead of having a mix of tunnels.

Portu.

[Jeffrey Behrns]

"mGRE is what made DMVPN so awesome, but it also came to limit it."

Can you elaborate on these limits of multipoint GRE?  If presented with two options for a hub:

1) single multipoint GRE interface

2) virtual-tempalte with many spawned virtual-access interfaces

It sounds like you endorse #2.  I am curious to know why because I am facing a migration to new tunneling methodology.

[Marcin Latosiewicz]

Jeffrey,

(it's around 1AM for me some please forgive typos / ambiguities).

With mGRE you have one logical interfaces to apply features to.

I.e. everything that was applied to the tunnel interface applies to all the sessions.

A typical problem is QoS; Per-tunnel QoS solves SOME of those problems, but we can do so much more if we use VAs.

If you forgive a shameless plug I can demonstrate with a document I wrote for a specific use case:

http://www.cisco.com/en/US/products/ps12922/products_tech_note09186a0080bf9d4e.shtml

In this document I demonstrate how to apply different features based on particular IKE identity using local attributes. 

mGRE/DMVPN is still a valid choice, if you want to have A policy applied to most of your sessions, having multiple VAs, allows you to have flexability to apply policies as needed. 

As a note DMVPN does mix with IKEv2. It's Flex/Multiple VAs which are adding the benefit.

M.

[Michael Sullenberger]

Just to make things clear for others that may find this thread.   Marketing and Development position FlexVPN as a Remote-access and possibly a simple hub-and-spoke only site-site solution.  DMVPN is positioned as the site-site solution including everything from hub-and-spoke only to complex single and hierarchical VPN with spoke-spoke tunnels.  In the future NHRP may be removed from FlexVPN.

FlexVPN is useful in those cases where you need to treat the spoke endpoints with individual policy or when the spoke devices are not Cisco.  This matches with a remote-access style of network where one entity may not own all of the VPN endpoints.

DMVPN is useful in those cases where all of the devices are using the same policy (don't need to be treated individually) and are all Cisco.  This really fits when you are doing spoke-spoke tunnels, since all the spokes need to be treated with the same policy.  If you try to truly treat them with different policy then you run into a nightmare of having to distribute this differentiated policy to every VPN node in the network.  Note, QoS is currently the only exception to this and that is why per-tunnel QoS was created.