by a GRE or DMVPN Overlay
This model simply
a mesh of GRE tunnels to create dedicated back-to-back connections between VRFs. In this manner, a group of VRFs on different sites are interconnected by a logical tunnel overlay to form a VN. Of course, each VN has a dedicated tunnel overlay and dedicated VRFs at each site, thus forming totally separate logical networks for each
You can use this model over a Layer 2 or Layer 3 service from a provider. If you do so, the enterprise needs to purchase only a single VPN or a single set of Layer 2 circuits from the provider. The enterprise then uses a combination of multi-VRF and GRE tunnels to overlay its own VNs onto the purchased service.
In this model, the headend has one mGRE tunnel per VRF. The branches have either a GRE or mGRE tunnel for each VRF. P2p GRE is used if no spoke-to-spoke communication is required. mGRE is required when spoke-to-spoke communication between branches is necessary.
DMVPN provides for dynamic spoke-to-spoke communication and encryption. If you configure mGRE on certain spokes, they have the ability to create dynamic tunnels to other
(which should also be configured with mGRE). This subset of the DMVPN functionality is discussed in detail in Chapter 5, "Infrastructure Segmentation Architectures: Theory."
have only a
requirement. In other words, large sites might need to be meshed together, but the smaller sites typically connect only to the headend and form a hub-and-spoke topology. Therefore, the deployment is
a combination of GRE and mGRE at the spokes, as
in Figure 7-18.
Figure 7-18. Multi-VRF Interconnected with mGRE/DMVPN
The hub device, while aggregating the branches, also
all the different VRFs. It can be either a PE if the headend site is RFC 2547 enabled or a multi-VRF hop if h2h segmentation is used at the headend site.
An IGP instance runs within each VPN between the hub and each of the spokes. If the hub site is RFC 2547 enabled, the IPv4 addresses learned from the spokes are converted to VPNv4 addresses before being advertised into the 2547 cloud using MP-iBGP. As discussed in Chapter 6, the IGP serves a dual purpose:
This type of deployment is suitable for branch aggregation in enterprises with a small number of branches and a small number of
groups or segments. The scalability of this solution is limited not only by the capacity of the headend devices but also by the manageability of an increased number of groups and sites.
Similar considerations apply to a DMVPN-based solution. A separate DMVPN is required to interconnect each group of VRFs and form a VPN. This involves the following
mGRE tunnels per VRF at each site (the hub and all participating spokes)
An NHRP server at the hub site
NHRP client capabilities at the spokes
Dynamic encryption security associations between sites
How this all works together is described in detail throughout Chapter 5. How this can be deployed in a campus is discussed in thorough detail in Chapter 6. Similar guidelines apply to the WAN, so rather than repeating those here, we refer back to Chapter 6.
Benefits and Drawbacks
DMVPN is a branch aggregation technology familiar to many enterprises. For a limited number of groups, you can leverage DMVPN to interconnect VRFs and form VPNs over the WAN. Benefits of using this approach include the following:
Encryption is built in to this solution.
This solution uses technologies that might be familiar to the enterprise operations personnel.
The simpler hardware capabilities required by this solution might allow for a broader choice of platforms in the enterprise.
The main drawback with this solution is that it has limited scalability because of the
of DMVPN or mGRE tunnel mesh instances. Therefore, this solution is ideal for an enterprise extending a small number of groups to several branches; as the number of groups
, you should consider other approaches.