The simplest deployment model for connecting MANs and campus networks that have been segmented by means of RFC 2547/MPLS VPNs is to use MPLS over Layer 2 circuits. You can also use this method for branch aggregation, however, the use of Layer 2 circuits for branch aggregation is becoming less and less common. The goal is basically to build one large MPLS network in which the WAN simply provides Layer 2 connectivity but does not participate in the IP routing of the enterprise. This model requires the enterprise to have Layer 2 connectivity between the different sites either via a legacy WAN (Frame Relay/ATM) or via a Layer 2 VPN service from a provider. The solution involves converting the edge devices into provider (P) or provider edge (PE) devices and making the WAN part of the MPLS MAN/campus network. Figure 7-7 shows a legacy Layer 2 WAN service and a Layer2 VPN service. The router roles have been labeled with the prefixes E and P for enterprise and provider, respectively. For example, E-PE is enterprise PE; whereas P-PE is provider PE. Figure 7-7. Layer 2 WAN Offerings: Legacy and L2VPN![]() The LANs and MANs to be interconnected are already MPLS enabled and configured with enterprise-deployed RFC 2547 VPNs. As shown in Figure 7-7, the WAN edge router used for interconnecting MANs/LANs plays the role of an E-P device. That is, it is a P router in the enterprise MPLS network. From a control-plane perspective, the following protocols run over the Layer 2 links:
Configuring this solution simply involves expanding the enterprise core to include the WAN. From the RFC 2547 VPN perspective, the following must be configured on the E-P routers:
From a forwarding perspective, irrespective of the Layer 2 service (legacy or Layer 2 VPN), the enterprise-edge device label switches packets like a normal P router, and the service provider should transparently forward the labeled packets across its network. When the different MANs or LANs are in different autonomous systems, the extension of MPLS over the WAN is not as straightforward as discussed so far. When faced with multiple autonomous systems, it is necessary to interconnect these autonomous systems appropriately. Generally, you can interconnect separate autonomous systems to support end-to-end VPNs in three ways. The different options are defined in RFC 2547bis and discussed in detail in the MPLS-specific literature; therefore, this text is limited to briefly introducing the different inter-autonomous system models. VRF-to-VRF Connections at the Autonomous System Border RoutersThis model, which is also known as back-to-back VRFs, is equivalent to connecting two totally separate MPLS clouds back to back on a pair of PE routers. This procedure involves two PEs (one from each autonomous system) connected back to back through several subinterfaces (one subinterface per VPN). In this model, the PEs see each other as multi-VRF CEs. External Border Gateway Protocol (eBGP) is used to exchange routing information between one autonomous system and another. MP-eBGP Exchange of Labeled VPN-IPv4 Routes Between Adjacent ASBRsIn this model, the PE routers use multiprotocol internal BGP (MP-iBGP) to redistribute labeled VPN-IPv4 routes to an Autonomous System Border Router (ASBR) either directly or through an RR. The ASBR then uses multiprotocol external BGP (MP-eBGP) to redistribute those labeled VPN-IPv4 routes to an ASBR in a neighboring autonomous system, which in turn distributes them via MP-iBGP to the PE routers in that autonomous system. Multihop MP-eBGP Between Remote Autonomous SystemsThis model enables the direct multihop MP-eBGP peering of PEs in one autonomous system with PEs in another. Thus, no VPN routes in the ASBRs interconnect the two autonomous systems. The ASBRs still have to exchange labeled VPN-IPv4 routes to provide reachability and label information to the PEs in either autonomous system; however, these updates do not contain VPN-specific routes. Using MPLS over Layer 2 Circuits for Segmented Branch AggregationThis model assumes that the enterprise has existing Layer 2 services for connecting branches. MPLS must be enabled over these Layer 2 links to provide segmentation through MPLS VPNs. Because such Layer 2 connectivity is typically hub and spoke or partial mesh, the MPLS overlay also inherits the same connectivity characteristics. Spoke-to-spoke communication then happens through the hub site. The branch aggregation router becomes an E-P router, as shown in Figure 7-8. The branch routers become E-PE routers with VRF interfaces facing the branch and MPLS-enabled interfaces facing the headend. The E-P router at the headend label switches all interbranch traffic and all traffic between the branches and the MPLS-enabled MAN or campus network. Figure 7-8. Branch MPLS Segmentation over Layer 2 Circuits![]() Because the branch routers are converted into E-PE devices, they extend the reach of the campus network/MAN MPLS cloud. As with any PE router, each remote-branch PE router maintains an LDP session and an IGP session with its neighboring P routers (in this case, the headend aggregator). The PEs also maintain MP-iBGP sessions with the RRs (or other PEs), which typically reside behind the headend aggregating device. The configuration of the headend is identical to that discussed earlier in this section for an E-P router. Because the branch router is an E-PE router, it is configured as follows:
Note See the section "RFC 2547bis the MPLS way" in Chapter 6 for further information about the last two configuration items. When segmentation is not required at certain branches, those branch routers do not need to have their WAN connection MPLS enabled. At the headend, this is not a problem when using separate p2p connections for each branch because each interface can be configured independently. When using multipoint connections, it is recommended that different multipoint connections be used for MPLS-enabled and non-MPLS-enabled branches. Note that when non-MPLS enabled branches are present, the headend device must also act as a PE device to terminate the VPNs to which the non-MPLS branches will be connected. In general, these Layer 2 circuit meshes can be considered private enough to not require encryption. However, if encryption is required, one option is to create an overlay of encrypted GRE tunnels and deploy MPLS on top of these encrypted tunnels. This configuration is necessary because encryption is not natively supported on label switched paths (LSPs). Benefits and DrawbacksThe decision to deploy MPLS over a Layer 2 infrastructure is largely based on the type of WAN service agreements and circuits the enterprise has in place. The enterprise's relationship with the service providers could determine the enterprise's ability to select a Layer 2 or an IP service. When a choice can be made, it is important to understand the benefits and drawbacks of the different approaches. Benefits of deploying MPLS over a Layer 2 infrastructure include the following:
Drawbacks include the following:
|