RFC 2547 VPNs over DMVPN
Instead of deploying a separate DMVPN overlay for each customer VN, you can use a single DMVPN overlay and
segments (VNs) over this single DMVPN. The VNs are multiplexed into the tunnel by using VPN labels in the same way it is done for 2547 over GRE deployments. This model,
in Figure 7-19, is recommended
for branch aggregation where most communication is between the hub and the branches, but not between branches. Because DMVPN is a widely deployed solution for branch aggregation,
that currently use the technology will find the capability to multiplex segments into their existing DMVPN extremely useful.
Figure 7-19. RFC 2547 over mGRE/DMVPN
This model provides the flexibility of dynamic tunnel creation along with enhanced scalability without some of the scalability limitations of the multi-VRF-based solutions described in the previous section. The scalability is improved because no one-to-one mapping occurs between the tunnel overlay and the VRFs. Instead, a single tunnel overlay can be shared for transporting many VNs.
The control plane for an RFC 2547 VPN environment running over DMVPN must include the following:
The tunnel source addresses (physical interface addresses) for the branches and headend must be advertised into the provider network. These can be advertised dynamically or statically.
A static GRE tunnel must be configured between the branch PE and the headend. The headend acts as a PE router.
An IGP running in the enterprise global space over the GRE overlay is necessary to provide connectivity between PEs and between PEs and the RRs.
MP-iBGP sessions are required with RR from PEs, where the branch router's BGP source address is the tunnel interface address. This forces the BGP
-hop lookup for the VPN route to be associated with the tunnel interface.
NHRP must be configured between the hub and the
The spokes can use a p2p GRE tunnel only if spoke-to-spoke communication is not required;
, they need to use mGRE. In addition, you can use IPsec to encrypt the GRE/mGRE tunnels because the encryption occurs after the GRE encapsulation.
The configuration is
straightforward. The following sample configuration for a hub PE shows a few interesting details:
The GRE mode
from that used for 2547 over mGRE.
Tunnel interface is label switched (
The hub is an NHRP server (details in Chapter 6).
ip address 10.1.1.1 255.255.255.0
no ip redirects
ip nhrp authentication test
ip nhrp map multicast dynamic
ip nhrp network-id 100
tunnel source 18.104.22.168
tunnel mode gre multipoint
tunnel key 123
tunnel protection ipsec profile mpls
As illustrated in Figure 7-20, when forwarding packets, the branch router attaches the appropriate VPN label for the destination. It then encapsulates the labeled packet in a GRE tunnel with the hub P as the destination before sending it to the provider. Because the service provider provides Layer 3 VPN service in this example, it further prepends its own VPN and LDP labels for transport within its network. The hub PE receives a GRE-encapsulated labeled packet. It decapsulates the tunnel headers and selects the appropriate VRF to do an IP lookup and forward the packet.
Figure 7-20. RFC 2547 over mGRE/DMVPNForwarding Plane
Benefits and Drawbacks
One of the most attractive features of an RFC 2547 over DMVPN deployment is the possibility of leveraging an existing DMVPN overlay and simply enabling VPN labeling over the existing DMVPN. The VNs traveling over the DMVPN inherit all the benefits of the DMVPN but also the shortcomings.
The benefits of this method include the following:
Enterprises can leverage their existing DMVPN infrastructure to aggregate branches.
Dynamic spoke-to-spoke tunnels provide direct communication between branches.
Built-in encryption provides privacy for traffic in transit over the WAN.
The drawbacks include the following:
This method is best suited for hub-and-spoke connectivity requirements. Any-to-any connectivity is better addressed by other techniques such as CsC.
Scaling limits are much lower than those
in any-to-any connectivity solutions.