GETVPN over 2547oDMVPN

Unanswered Question
Feb 13th, 2010
User Badges:

Is this possible? I'm working on a project involving more than 500 remote sites coming in over ATT's MPLS cloud. The plan is to deploy dmvpn over the ATT MPLS cloud and enable MPLS over the tunnels so we can service multiple vrfs at the remote sites without deploying multiple pvcs from ATT. Hence we're doing this to avoid deploying vrf-lite with multiple pvcs since such a design does not scale for us. We requested CsC service from ATT but that was turned down hence the 2547oDMVPN approach but without IPSEC. In place of IPSEC we plan on using GETVPN for encryption and so far we've not been successful. We have GETVPN deployed on our current p2p WAN circuits (these circuits are being replaced with the ATT MPLS service) so it makes sense for us to continue offering this service to the units we provide services for.


In this deployment, every remote site router (c2811) is a PE. The PE's peer with ATT. There are two ASR 1006 routers. These are the dmvpn hubs. A multipoint gre tunnel from the hub connect to all the remote sites. This is a dual hub and dual dmvpn cloud setup for redundancy. The dmvpn hubs and the remotes are all in one AS. The dmvpn hubs then peer with the campus network. The campus network is one AS. The DMVPN cloud is running BGP with mpls enabled on the tunnels.


Would appreciate any help in getting GETVPN to work in this deployment environment. Will send diagrams and configs if asked for.


-Kwame.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Federico Coto F... Sat, 02/13/2010 - 19:47
User Badges:
  • Green, 3000 points or more

Hi,


As far as the GETVPN portion of the configuration is concerned, we simply need to decide what traffic is going to be encrypted. DMVPN is based on encapsulating with GRE, so we only need to worry about GRE between the group members. This is done with an ACL on the key server like so:
access-list 101 permit gre any any
!
crypto gdoi group dmvpn
server local
sa ipsec 1
match address ipv4 101


In a standard DMVPN implementation the GRE tunnels are encrypted using tunnel protection with an IPsec profile. Since GETVPN has already taken care of the encryption we can simply remove (or not include) the tunnel protection command. Here is a sample tunnel configuration for the hub.


interface Tunnel0
bandwidth 1000
ip address 192.168.1.1 255.255.255.0
ip mtu 1400
no ip next-hop-self eigrp 1
ip nhrp map multicast dynamic
ip nhrp network-id 1
no ip split-horizon eigrp 1
tunnel source Loopback0
tunnel mode gre multipoint
tunnel key 1


What exactly do you need assistance with?


Federico.

rpeasah Sun, 02/14/2010 - 06:20
User Badges:

I've attached a drawing to assist with what I'm doing and clarify what I'm needing assistance with.

  1. The DMVPN has no encryption. Just plain tunnels.
  2. mGRE on ASR-1 and ASR-2 to all spokes.
  3. The spokes are doing p2p gre to the ASRs (no mGRE on the spokes).
  4. No dynamic spoke2spoke tunnels.
  5. All spoke2spoke traffic transits the ASR.
  6. No IGP in the DMVPN cloud. Only BGP.
  7. MPLS configured on the tunnel interfaces.
  8. All spokes are PEs.
  9. The DMVPN is not end-to-end in the entire topology. It's restricted to AS 65002.
  10. I want to use GETVPN to encrypt traffic from PC-1 in vrf 102 and in AS 65001 to PC-2 also in vrf 102 but in AS 65002.
  11. The key server, KS-1, is in the global table in AS 65001. This could be a problem but the thinking is to position the KS-Server in manner such that it can be used for other vrfs if needed rather than limiting it to one vrf. Is that possible? Don't know. Part of the investigation as to what's feasible and what's not.


-Kwame

Federico Coto F... Sun, 02/14/2010 - 11:42
User Badges:
  • Green, 3000 points or more


Basically, your goal is to extend the GETVPN through the MPLS cloud so that communication between PC1 and PC2 is encrypted, correct?

A141 should be a GM for GETVPN with reachability to the KS server.


Typically the KS is installed in the data center of the customer network.

It is also recommended to have more than one KS server in separate locations for redundancy.

GETVPN it's also the ideal solution over an MPLS cloud because of the source and destination address preservation which leads to optimum routing and full-mesh behavior and scalability.


Basic steps are:
For KS
1. Configure ISAKMP Policy
2. Configure authentication (either PSKs or PKI)
3. Configure IPsec parameters
4. Configure GDOI Group
5. Configure ACL Policies
Then for the GM
1. Configure IKE Phase 1
2. Configure the GDOI Group
3. Configure Crypto Map
4. Enable GETVPN


Take into account that GETVPN GM is VRF-aware but the GETVPN KS is not. This means that GMs should register to a distinct set of KS's per group. (A KS set per VRF is recommended)


Here's a good link:


http://www.cisco.com/en/US/prod/collateral/vpndevc/ps6525/ps9370/ps7180/GETVPN_DIG_version_1_0_External.pdf


Federico.

gjstem Mon, 02/22/2010 - 06:44
User Badges:

I would just consider converting your architecture over to 2547oDMVPN with IPsec.  If you are going to build the hub and spoke tunnel overlay anyway then it will be much cleaner from a architecture perspective to use the native DMVPN encryption capabilities rather than try to layer it with GETVPN.  Your building the tunnels anyway, couldn't you just consider enabling the tunnel protection as part of the implementation.  As you cutover traffic into the new VRFs that will be mapped  into the DMVPN overlay, you can remove the GETVPN statements and let traffic flow in the clear into the new encrypted tunnels.


-Greg

Actions

This Discussion