VRFs Interconnected by a GRE or DMVPN Overlay
| This model simply leverages 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 group. 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 spokes (which should also be configured with mGRE). This subset of the DMVPN functionality is discussed in detail in Chapter 5, "Infrastructure Segmentation Architectures: Theory." Most enterprises have only a partial-mesh 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 generally a combination of GRE and mGRE at the spokes, as illustrated in Figure 7-18. Figure 7-18. Multi-VRF Interconnected with mGRE/DMVPN The hub device, while aggregating the branches, also hosts 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 user 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 components:
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 DrawbacksDMVPN 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:
The main drawback with this solution is that it has limited scalability because of the proliferation 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 increases, you should consider other approaches. |
EAN: 2147483647
Pages: 128