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.
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
I've attached a drawing to assist with what I'm doing and clarify what I'm needing assistance with.
The DMVPN has no encryption. Just plain tunnels.
mGRE on ASR-1 and ASR-2 to all spokes.
The spokes are doing p2p gre to the ASRs (no mGRE on the spokes).
No dynamic spoke2spoke tunnels.
All spoke2spoke traffic transits the ASR.
No IGP in the DMVPN cloud. Only BGP.
MPLS configured on the tunnel interfaces.
All spokes are PEs.
The DMVPN is not end-to-end in the entire topology. It's restricted to AS 65002.
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.
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.
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.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...