MPLS over GRE


Another alternative to interconnect enterprise MPLS VPN networks over a WAN IP service is to create a mesh of GRE tunnels over the WAN IP cloud and enable label switching on the GRE interfaces. This setup achieves two benefits:

  • Bypasses the provider P and PE nodes that we have no control over and on which we cannot enable MPLS or other segmentation techniques

  • Provides a logical topology that can be MPLS enabled and therefore become part of the enterprise's MPLS VPN core

As shown in Figure 7-12, in this scenario, the WAN edge router plays the role of an E-P device.

Figure 7-12. MPLS over GRE


A p2p GRE tunnel is set up between each edge router pair if a full mesh is desired. From a control-plane perspective, the following protocols are expected to be run within the GRE tunnels:

  • An IGP such as EIGRP or OSPF for MPLS device reachability (this makes the E-PE, E-P, and RRs reachable to each other)

  • LDP, to allow the formation of LSPs over which traffic is forwarded

  • MP-iBGP for VPN route and label distribution between the E-PE devices

After the GRE tunnels have been established, the configuration of this solution exactly matches that used to deploy MPLS over Layer 2 circuits. The only difference is that instead of enabling label switching on the WAN interfaces, it is enabled on the tunnel interfaces. Therefore, the command-line interface (CLI) should look like this:

 interface Tunnel0  description GRE tunnel to E-P2  bandwidth 1000  ip address 172.16.100.2 255.255.255.0  ip mtu 1400  tag-switching ip  ip ospf network broadcast  ip ospf priority 0  tunnel source Loopback0  tunnel destination 10.126.100.254 


After the route/label distribution has been completed in the control plane, the enterprise edge device acts like a label switching router (LSR/P) where it treats the GRE interfaces as normal access interfaces. Figure 7-13 shows end-to-end packet flow between campus networks/MANs.

Figure 7-13. MPLS over GRE Packet Flow


The figure shows how the MPLS label (LDP2) is maintained constant between the E-P routers. The LDP2 label remains constant because the GRE tunnel overlay makes the two E-P routers appear as directly connected. The figure also shows the encapsulating GRE header used as the packet traverses the service provider cloud. Note that the header is imposed by the E-P routers and that the tunnels are established based on the IP reachability in the provider cloud. The latter is represented by the IP2 portion of the header.

The traffic inside the service provider cloud may or may not be MPLS switched, thus the service provider LDP and service provider VPN labels are present only if the service is an MPLS VPN. However, this should be of no concern to the enterprise and is mentioned here only for completeness.

Figure 7-14 shows an interesting variation of the use of VPNs over GRE tunnels. In this scenario, the WAN edge devices are also acting as E-PE devices. Note that this is equivalent to having the PE routers connected back to back. Because of PHP, no LDP label or even an LSP is formed between the E-PEs. In other words, no label swapping occurs, and there is no need for a LDP. The only use for labels in this scenario is to identify the VRF for which the traffic in the tunnel is destined. The VPN labels are used for multiplexing and demultiplexing traffic between the tunnel and the appropriate VRFs.

Figure 7-14. RFC 2547 VPNs over GRE Packet Flow


Clearly, this network is not using label switching, nor does it need label switching functionality. However, support for RFC 2547 VPNs is still required. Therefore, this type of overlay model is usually referred to as 2547 over X. In this particular scenario, it would be 2547 over GRE. Note that this differs from MPLS over GRE because no support exists in the solution for label switching. Therefore, if the edge devices support 2547 over GRE but not MPLS over GRE, these cannot be used as label switching P routers. It is not uncommon to find enterprise-grade platforms that can support 2547 over GRE but not support full MPLS over GRE. The difference in functionality, although apparently subtle, is critical to the design of the network. The network architect must clearly understand the type of VPN role required at the WAN edge to make the right choice of hardware.

Note

At of the time this writing, support for 2547 over X is more common than support for MPLS over X.


2547 over GRE has been superseded by 2547 over mGRE, which incorporates all the flexibility of dynamic multipoint tunnel interfaces. The technical details and configuration of this approach are identical to those of the 2547 over L2TPv3 implementation. The sole difference is the encapsulation being used; all other architectural and configuration details are comparable. Therefore, we defer this discussion to the next section as we discuss 2547 over L2TPv3.

Benefits and Drawbacks

Deploying MPLS (or RFC 2547) over a mesh of GRE tunnels allows the enterprise to extend their MPLS network over almost any IP network. As always, there are both challenges and benefits with this type of WAN extension.

The benefits of deploying MPLS over GRE tunnels include the following:

  • The solution is independent from the provider.

  • GRE tunnels can be easily encrypted with IPsec.

  • The edge routers can perform as P or PE routers, potentially allowing a single MPLS network to be deployed across the MAN/campus/WAN frontier.

The drawbacks include the following:

  • Maintaining the GRE tunnel mesh can be cumbersome.

  • Any-to-any connectivity requires a full mesh of tunnels.

  • Maximum transmission unit (MTU) considerations must be made in the WAN core, especially as more MPLS services are added. The WAN core is not controlled by the enterprise, so MTU size must be limited at the edges.

The extension of MPLS VPNs over GRE tunnels is useful in scenarios that require the aggregation of a limited number of sites in a hub-and-spoke logical topology. Any-to-any connectivity for many sites is better addressed by dynamic mechanisms, such as CsC or RFC 2547 over DMVPN. DMVPN-based mechanisms are discussed in some of the following sections.




Network Virtualization
Network Virtualization
ISBN: 1587052482
EAN: 2147483647
Year: 2006
Pages: 128

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net