RFC 2547 VPNs over DMVPN

RFC 2547 VPNs over DMVPN

Instead of deploying a separate DMVPN overlay for each customer VN, you can use a single DMVPN overlay and multiplex the different user 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, illustrated in Figure 7-19, is recommended mainly 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, enterprises that currently use the technology will find the capability to multiplex segments into their existing DMVPN extremely useful.

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 next -hop lookup for the VPN route to be associated with the tunnel interface.

• NHRP must be configured between the hub and the spokes .

The spokes can use a p2p GRE tunnel only if spoke-to-spoke communication is not required; otherwise , 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 fairly straightforward. The following sample configuration for a hub PE shows a few interesting details:

• The GRE mode differs from that used for 2547 over mGRE.

• Tunnel interface is label switched ( tag-switching ip ).

• The hub is an NHRP server (details in Chapter 6).

  
  interface Tunnel1
  
  
  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 7.7.7.2
  
  
  tunnel mode gre multipoint
  
  
  tunnel key 123
  
  
  tunnel protection ipsec profile mpls
  
  
  tag-switching ip
  
  !
  

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.

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 encountered in any-to-any connectivity solutions.