Unanswered Question
Nov 20th, 2009
User Badges:

Couple of questions.

the key server ip address should be public ??? or actuall tunnel interface on the hub?

also, what should the ACL for encryption look like to encrypto traffic between tunnels? or actuall traffic between sites.

lets say tunnel network is

where is a hub is a spoke is a spoke

and is network behind hub ans is network behind spokes


  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (1 ratings)
Laurent Aubert Sun, 11/22/2009 - 20:12
User Badges:
  • Cisco Employee,


Why do you need GET VPN on top of DMVPN ???



mprescher Mon, 02/01/2010 - 10:37
User Badges:

Not sure what the original poster's reasoning was but we have a similar need.

We want to extend MPLS VRF's to hundreds of branch locations. However, using AT&T AVPN MPLS services we can't do this without using DMVPN as they won't PASS-THROUGH tags through their cloud.  Too bad because one of the criteria for us to to maintain control over the tagging.  This is the old carrier-in-carrier issue. DMVPN solves these issues for us.

However, DMPVN in voice environments over WAN doesn't have the performance to support VoIP spoke to spoke (also on the road map for us) so we are stuck with Hub and Spoke-only deployments. I guess we can live with that.

However, GETVPN may very well be the better choice long term, once it is VRF aware. Also we already have lots of WAN sites using GETVPN. Further, if we switch to DMVPN with encryption and move away from GET for the interim, in a couple years we may find ourselves wanting to got back to GETVPN. Not a big deal with 5 sites, but with hundreds, each change is a multi-month project, training, re-training, documenting, etc...

So, the ideal solution seems to be, Introduce DMVPN WITH GETVPN. Do this until GET is VRF-aware so we can maintain the GET facility we have today while also allowing MPLS transport of our own tags through a service provider.  Once GET is VRF-aware (this is an assumption on my part) we then peel off the DMVPN and just use GET. And, we might end up gaining spoke-to-spoke routing capability at the same time.

NOTE 1: early feedback is, headend multicast replication penalty when using DMVPN would be eliminated as well. Haven't looked at this aspect in detail myself.

NOTE 2: we just found out that ATT has a plan to increase their current MTU of 1500 within their MPLS AVPN cloud to 2000 some time later this year. This makes control of our own tag stack possible and in turn, faster less expensive move add change sequences.)

So, if anybody knows if this is even possible, holler.

Much appreciated,


P.S. Post, posting note: we aren't alone in seeing the need. Here is a link to somebody else who took it out for a spin:


This Discussion

Related Content