Tunnel Overlay for Layer 2 VPNs

A Layer 3 VPN might not be an adequate solution for an enterprise network for several reasons, including the following:

• An enterprise might use legacy applications that rely on protocols that cannot be natively transported at Layer 3. A Layer 2 VPN is a good way of letting the rest of the network move to IP by isolating the legacy components.

• A second example is the desire to avoid deploying routers at sites where there had been none before. A Layer 2 VPN avoids this extra cost.

• Some applications are not tolerant of the latency characteristics of a Layer 3 network and need Layer 2 transport (for example, for cluster computation message exchange or data center replication).

Layer 2 VPNs offer an alternative approach. Their defining characteristic is that they transport Layer 2 (typically Ethernet but also ATM and Frame Relay) frames between sites. This is both a good and bad thing. The benefit comes from the fact that a Layer 2 VPN is agnostic about the higher-layer protocols used on the network and is less demanding of the devices placed at the edge of the LANs. The disadvantage is the absence of a Layer 3 control plane to manage reachability and segment broadcast domains across the VPN.

In many enterprise scenarios, the CPE are Ethernet switches and, obviously, any broadcasts generated on one site network must be transported to all other sites. Just like with any other VPN, a forward-looking network administrator would want redundant paths between sites. In a Layer 3 VPN, we can use sophisticated routing protocols to manage multiple paths. In an Ethernet Layer 2 VPN, we have . . . STP.

You can build Layer 2 VPNs using p2p and multipoint topologies. Because of the scalability characteristics outlined previously, it is much simpler to build p2p topologies than to create a multi-access network across a wide-area infrastructure.

The next two sections look at alternative p2p implementations, first using L2TPv3 and then using MPLS. Then we look at a multipoint solution for Ethernet, called Virtual Private LAN Services (VPLS). In both cases, the Layer 2 service is delivered over a Layer 3 core network.

Layer 2 P2P Overlay Using L2TPv3

An L2TPv3-based Layer 2 VPN uses p2p pseudowires between customer located equipment (CLE) to transport Layer 2 frames between switches. The Layer 2 frames can be 802.1q, Frame Relay, ATM, or High-Level Data Link Control (HDLC). The customer edge (CE) router is a switch, and the provider edge (PE) router is an L2TPv3 device.

Figure 5-6 shows L2TPv3 tunnels used to build a hub-and-spoke network. Site 3 is the hub. Sites 1, 2, and 4 are spokes. An L2TPv3 control channel sits between every hub-spoke pair, which peer routers use to negotiate unique session and cookie IDs for each VLAN or port bound to the L2TPv3 tunnel. Very advantageously, the VPN and its topology is totally transparent to the CLE, which has exactly the same configuration on a LAN with a direct physical link to its Layer 2 next hop.

Figure 5-6. L2TPv3 Overlay Network

The CLE in the network in Figure 5-6 runs a spanning tree across the VPN. Note that some commercial Layer 2 VPN services are not bridge protocol data unit (BPDU) transparent, so a spanning tree cannot run across the WAN links.

The L2TPv3 core network, which runs IP, provides path redundancy between sites. If the core can reconverge quickly enough, a tunnel could even change its path without dropping sessions. In any event, the customer STP does not need to calculate alternative paths across the VPNthe L2TPv3 transport handles this.

The Layer 3 overlays presented previously in this chapter used the IP control plane to create a hub-and-spoke topology. Spokes have default routes to the hub, which has routes for each prefix used at the different spoke sites. Most Layer 2 protocols do not work like that. Ethernet, for example, expects to be able to flood packets to all peers. No mechanism at either the Ethernet layer (nor in L2TPv3) enables the creation of a hierarchy without using address learning (and flooding) between switches.

Consider again Figure 5-6 and suppose that Host1 on Site 1 needs to reach Host2 on Site 2. These sites are connected through Site 3. Both hosts are in VLAN A, which is also configured on Site 4.

• When Host1 sends its Address Resolution Protocol (ARP) request, this is broadcast to all sites on the VLAN, and so all the switches create an entry in their mac-address table to map the respective MAC addresses to the correct port (pseudowire).

• Host 2 sends a unicast reply, which allows the Site 1 switch to update its mac-address table with that information, too.

• When another host on the same VLAN sends data, the same process happens, with flooding and learning across the VLAN.

The topology in Figure 5-6 has no loops for STP to contend with, and you could disable spanning tree across the VPN links. However, if there were redundant links between CLE devicesa pseudowire between Sites 1 and 2, for exampleSTP would be required to disable one of the trunk ports (trunk ports are those that connect the CLE to the WAN).

So far, we have concentrated on the control plane across Layer 2 VPNs, but, before moving on to the next topic, a quick word about the data plane is in order.

A VPN is usually required to be transparent to the protocol it transports. Quality of service (QoS) settings, signaling information, and so forth should be preserved as packets or frames go from one place to the next. The L2TPv3 RFCs, discussed in Chapter 4, define encapsulation rules that allow peers to exchange Ethernet frames. For example, the cyclic redundancy check (CRC) field is removed before the frame enters the pseudowire and is recalculated at egress. Type of Service (TOS) bit settings are not changed. Other encapsulation rules enable the transport of Frame Relay (or ATM and so on) and define how to carry congestion notification and Local Management Interface (LMI) signaling.

Layer 2 P2P Overlay Using MPLS

MPLS offers an alternative way to build up Layer 2 VPNs.

MPLS link switched paths (LSPs) are also p2p tunnels where labels rather than session IDs are used to multiplex user traffic on trunk interfaces. In a way, that is analogous to the L2TPv3 scenario, an MPLS-based Layer 2 VPN, which is shown in Figure 5-7, uses a control-plane protocol to exchange label values for user VLANs or ports that are bound to pseudowires (yes, it is the same term as L2TPv3, which borrowed it from MPLS) on PE routers.

Figure 5-7. MPLS-Based Layer 2 VPN

To understand how MPLS Layer 2 VPNs work, there are two questions to answer here:

• How are labels exchanged between PE routers?

• How are packets forwarded across the core?

Label exchange is implementation dependent. Most vendors use directed Label Distribution Protocol (LDP), but at least one uses BGP. Chapter 4 explained that labels have link local (or device local) significance, and different label values are used by each link switching router (LSR) along an LSP. The LDP runs between each LSR to announce prefix-to-label mappings. In a Layer 2 VPN, a LDP session runs directly between PE routers. LDP was chosen over other signaling protocols used in MPLS networks (BGP, Resource Reservation Protocol [RSVP]) because it is well suited to p2p setup and the majority of Layer 2 VPN deployments use a p2p topology.

When an interface is bound to a pseudowire, the PE creates a label value for that port (or VLAN) and sends it to the remote PE. On Cisco devices, the remote PE address is configured with the xconnect statement introduced in Chapter 4.

LSPs are unidirectional, so there can be different label values at either end of a pseudowire for a particular VLAN. Compare this to L2TPv3, which negotiates a common session and cookie ID.

Note

Without wanting to start a "my protocol is best" debate, there are other differences between the two protocols. For example, the session+cookie address space is much bigger than the 20-bit label space, which makes spoofing that much harder. L2TP has its own control plane, which it can use to set up and tear down sessions according to traffic needs, and which can list failover destinations for tunnels. MPLS uses the IP control plane, and the cost of maintaining a LSP is essentially nothing, so there is not much need to remove labels until and unless the prefix (or Layer 2 port) is no longer reachable.

When a frame is received on a PE, it is encapsulated in MPLS, and the label value that identifies the VLAN or port on the remote PE is imposed on the label stack. But this is not enough. The next-hop LSR expects a label that identifies the Forwarding Equivalence Class (FEC) classification for this packet, and that lets it find the outgoing label in its LSP forwarding information base (LFIB). Therefore, a second label, corresponding to the IP address of the remote PE, is pushed onto the packet's label stack. This label will be swapped at each hop and popped at the penultimate hop before the packet exits the MPLS network.

A large set of RFCs, collectively and affectionately referred to as draft-martini, defines the different "Layer x over MPLS" encapsulation rules and the control-plane functionality required to transport Frame Relay, Ethernet, PPP, ATM, or HDLC over MPLS networks. However, interoperability issues still exist between vendors.

A significant portion of Chapter 4 was devoted to device virtualization, so it is natural to ask how devices are virtualized for Layer 2 VPNs. The answer (for Ethernet) is simple: VLANs. The LSPs or L2TP tunnels behave like interfaces bound to an 802.1q VLAN.

Note

The hub-and-spoke scenarios had no device virtualization when using a single address space. If each site has multiple virtual networks, however, each tunnel can be bound to VRFs.

Ethernet Layer 2 VPN services are commercialized using service definitions based on definitions made by the Metro Ethernet Forum. These include variations on p2p, such as Ethernet Relay and Ethernet Wire services. One has full Layer 2 transparency (and therefore carries BPDUs, for example), whereas the other only transports data frames. Some service descriptions are intended for router CPE, others for bridges. Interested readers are directed to the Metro Ethernet Forum website for more information (http://www.metroethernetforum.org/).

Layer 2 VPN MP2MP Using MPLS (VPLS)

We already touched on VPLS to introduce the concept of VPN forwarding instances (VFIs) in Chapter 4. From an architecture perspective, VPLS uses a full mesh of p2p MPLS pseudowires to emulate an Ethernet switch.

Service providers have long wanted a value-added service to connect the countless Ethernet segments on customer networks. The ideal solution allows a customer to plug any Ethernet device into a WAN port and the service provider network then transparently forwards frames to their destination. Commercial offerings based on ATM exist, often called something like Transparent LAN service. Managed multipoint Layer 2 VPN services have not succeeded in becoming universal.

Some inherent properties of Ethernet are a real challenge to duplicate using a p2p infrastructure. VPLSwhich is a mp2mp service built on top of p2p pseudowirestries to mitigate these in the following way:

• Auto-provisioning Devices can be added to an Ethernet network without any prior configuration. VPLS implements auto-provisioning much like an Ethernet switch does. Every new MAC address is flooded on all pseudowires in a virtual switch interface (VSI). The ARP reply information is used to create an entry on the PE to map a MAC address to a pseudowire.

• Auto-discovery In the context of a VPN, the problem is to provide a mechanism for every PE to discover its VLAN "peers." The standard proposals for VPLS have not yet addressed auto-discovery. One vendor's implementation uses BGP (draft-kompella) to announce VLAN membership between PEs. Other ideas include doing a lookup in a central repository using RADIUS or Domain Name System (DNS) protocols.

• Multicast support Multicast and broadcast are treated in the same way: Frames are flooded across all pseudowires.

Some of the other issues that arise with VPLS relate to scale. A full mesh of connections is expensive, of course, but many WAN traffic patterns are still client/server in nature, for which hub-and-spoke topologies can be a better fit.

In addition, Ethernet addresses cannot be aggregated. Every address on the LAN must be stored in a VFI table, which can place an obvious strain on PE memory. Using a router as the CPE can help mitigate this problem because only the router addresses need to be advertised across the VPLS networkbut this approach invites the question of why not use a Layer 3 VPN service in the first place.

Layer 2 VPN Summary

This section showed how you can use L2TPv3 and MPLS to build p2p Layer 2 VPNs across a Layer 3 network. Regardless of the protocol, the architecture is the same. Managing loops and redundant paths is more challenging than in an equivalent p2p Layer 3 VPN because of well-understood characteristics of the Layer 2 control plane. Both protocol- and implementation-related details affect how Layer 2 protocols are carried across the Layer 3 cloud (these are often arcane, but exist nevertheless).

VPLS is a Layer 2 mp2mp architecture that emulates an Ethernet switch, using a full mesh of Layer 2 pseudowires, all which run over an MPLS network (with its IP control plane). VPLS, like LAN Emulation (LANE) before it, often appears compelling because of the attractiveness of any-to-any reachability offered by the service.

However, VPLS is a complex beast and, in our opinion, Layer 3 VPNs offer a much more scalable and robust solution that similarly moves the burden of routing from the CE into the provider network. When true Layer 2 connectivity is required, a sparse mesh of p2p circuits is often enough for most designs.