02-13-2010 07:18 PM - edited 02-21-2020 04:30 PM
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.
02-13-2010 07:47 PM
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.
02-14-2010 06:20 AM
I've attached a drawing to assist with what I'm doing and clarify what I'm needing assistance with.
-Kwame
02-14-2010 09:15 AM
Thank you, let me check it out.
02-14-2010 11:42 AM
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:
Federico.
02-22-2010 06:44 AM
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
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: