Layer 2 VPNs
| As enterprises virtualize their networks, some might require the support of non-IP or nonroutable traffic in these virtualized environments. To support this type of traffic, it is necessary to extend Layer 2 domains across the enterprise network. In general, the extension of Layer 2 domains is discouraged because of all the scalability issues discussed in Chapter 2. Therefore, when pervasive any-to-any connectivity is required, it is highly advisable that a routed alternative be evaluated before considering any sort of Layer 2 extension. The requirement for Layer 2 extensibility is usually limited to the interconnection of a few sites to support legacy protocols or the interconnection of server farms. It is important to maintain the scale of this requirement as small as possible. As we study the different alternatives for extending Layer 2 connectivity, it will become evident that these are practical in solving a limited connectivity requirement and will cease to scale rapidly. Instead of attempting to extend VLANs throughout the enterprise, the creation of VPNs for nonroutable traffic calls for the use of Layer 2 VPN or tunneling technologies that will provide the desired Layer 2 connectivity over the enterprise's routed core. In brief, the requirements for this type of Layer 2 connectivity are as follows:
Ethernet over MPLSThe following sections explore two of the most common MPLS-based Layer 2 VPN technologies: Ethernet over MPLS (EoMPLS) and Virtual Private LAN Services (VPLS). Providing Point-to-Point ConnectivityEoMPLS pseudowires are by definition p2p Layer 2 connections. The basic operating principle of a pseudowire is that of being able to take any traffic received on an ingress port and transparently send it over to the egress port at the other end of the pseudowire (as shown in Figure 6-14). Figure 6-14. EoMPLS Pseudowires Two types of ports can be mapped to EoMPLS tunnels:
The creation of the pseudowire is achieved by encapsulating the traffic received on the "cross-connected" ingress port and switching it to the remote end based on the encapsulation header. The use of the encapsulation header allows the traffic to remain untouched as it traverses the routed cloud. When traffic arrives at the remote end, the encapsulation headers are removed, and traffic is forwarded out the egress port without any alterations. Because all traffic received on a cross-connected port is forwarded transparently, the PEs do not learn any MAC addresses on the cross-connected ports. Thus, the pseudowires effectively behave as a link extension or a virtual wire, which is commonly referred to as a pseudowire. Therefore, in the figure above, switches Giacometti and Brancusi appear as if directly connected by an Ethernet link. An EoMPLS virtual circuit can be created between a pair of PE devices on opposite sides of the MPLS-enabled campus network or MAN to transparently carry the traffic between the two cross-connected ports. The cross-connected ports on each PE device receive and tunnel all the Ethernet frames from the Layer 2 switches at the edge. The configuration required for enabling this functionality on the PE interfaces is simple, as demonstrated in Example 6-29. Example 6-29. EoMPLS Pseudowire Configuration
The xconnect command is basically the only command required, and it is used to specify the remote PE loopback address (for example, on Brancusi it is 3.3.3.1). One restriction to be aware of is the size of the packets that can be sent over the pseudowire. Because there is no check done on the packets by the routers at the endpoints of the pseudowire, it is possible to exceed the valid MTU in the routed core by sending large packets. If the packet size is close to the MTU limit supported by the routed core, the addition of headers could generate packets of an MTU greater than what the network can support. In this case, jumbo frame support might be required in the network core. Providing Multipoint ConnectivityAs discussed, EoMPLS is a p2p technology. Any attempt to provide multi-site connectivity has to involve a combination of multiple p2p connections. When you are combining multiple Layer 2 p2p connections, a hub-and-spoke logical topology can provide multipoint connectivity by aggregating and switching all traffic at the hub. Because a hub-and-spoke topology is loop free, there is no strict requirement on the use of STP. EoMPLS circuits take all traffic on an interface and tunnel it over the MPLS core. Unfortunately, a single interface cannot be mapped to multiple EoMPLS pseudowires. Therefore, you must use a distinct physical interface at the hub site for each remote site that needs to be connected. In other words, each pseudowire requires a dedicated physical interface at each end. To switch traffic between the different sites, you must aggregate these different interfaces onto a Layer 2 bridge at the hub site; this functionality can be provided by a separate switch, as shown in the figure. If this seems awkward, it is because EoMPLS was designed with p2p wire emulation in mind, not for multipoint switched-connectivity purposes. In Figure 6-15, three physical links would be required on the hub PE to connect to the three different sites; the configuration for each of these interfaces is similar to the one displayed before, with an xconnect command on each interface to establish the EoMPLS virtual circuit with the remote PEs. Figure 6-15. Multipoint Connectivity Emulation with EoMPLS Resilient Pseudowire TopologiesTraffic entering an EoMPLS tunnel is not checked for integrity or validity. Therefore, any type of traffic can be forwarded over an EoMPLS pseudowire. This allows the transparent forwarding of Layer 2 control traffic such as STP bridge protocol data units (BPDUs), Cisco Discovery Protocol (CDP), VLAN Trunking Protocol (VTP), 802.3ad Link Aggregation Control Protocol (LACP), and so on. This allows the use of some traditional Ethernet protocols over the pseudowires to provide failure detection and failover mechanisms that enable resiliency. Multiple Tunnels and CE STPBecause the EoMPLS pseudowires transparently forward all traffic they receive, the logical topology illustrated in Figure 6-16 is equivalent to directly connecting the edge switches (Brancusi and Giacometti) with two Ethernet links. This clearly forms a Layer 2 loop. Because the pseudowires forward all traffic transparently, including STP BPDUs, it is possible to run spanning tree between Brancusi and Giacometti to block the loop and to provide a resilient path in case of failures. Figure 6-16. Resilient Pseudowires The use of the Rapid Spanning Tree Protocol (RSTP) allows optimal reconvergence and subsecond failover times in this array. However, this model does not provide any load balancing between the two pseudowires, and as a matter of fact, only half of the capacity in the network is used. The following section looks at alternatives that can provide load balancing and resiliency. However, the failover times for these alternatives are significantly slower. Multiple Tunnels and CE Link AggregationTo deploy resilient pseudowires between a pair of sites without creating a Layer 2 loop, you can bundle the two pseudowires to create a port channel. You should use a dynamic negotiation protocol to ensure that if a local link connecting to the PE fails, the remote site can detect the failure. The dynamic negotiation options include the following:
However, the timers on both these protocols provide relatively slow failure detection, in the order of 90 seconds. Using UniDirectional Link Detection (UDLD) to provide failure detection can help lower the failover time between redundant circuits. The expected failover times with UDLD in aggressive mode vary between 20 and 40 seconds depending on the hardware used and the possibility of tuning the UDLD timers. The configuration in Example 6-30 would be required on each of the switches establishing the bundle. Notice that these are not the PEs with the cross-connects, but the edge switches feeding traffic into the PEs. Example 6-30. Establishing an EtherChannel over EoMPLS Across Sites
The connections between the Layer 2 switch and the PEs are trunk links; therefore, various Layer 2 domains (VLANs) can be transparently extended using the same EoMPLS virtual circuits. VPLSAs described in Chapter 5, VPLS provides a mechanism to provide multipoint Layer 2 connectivity over an MPLS switched infrastructure. At first, this may sound like a scalable alternative to extending VLANs across the enterprise. However, it is important to keep in mind that VPLS has its own scalability limitations:
VPLS is by no means an alternative to Layer 3-based segmentation. Although it can provide any-to-any connectivity, it can only do it effectively for a limited number of hosts and sites. Note When used in a service provider setting, VPLS has different requirements than when used in an enterprise. The scalability concerns for VPLS in a service provider setting are much different. For instance, the enterprise might intend to use VPLS for Layer 2 extensibility, whereas the service provider might require a routed hop to access the VPLS cloud and therefore not extend the customer's Layer 2 domains. Because VPLS has been designed to cover a specific need in the service provider space, its availability on enterprise platforms is limited and its cost is high (when available). VPLS could provide a valid alternative for small-scale multipoint Layer 2 connectivity. However, the cost-benefit ratio may not be justifiable (and hence our focus on multipoint solutions based on EoMPLS). |
EAN: 2147483647
Pages: 128