Layer 2 Vpn Architectures [Electronic resources] نسخه متنی

Layer 2 Interworking Technology Overview

Previous chapters dealt with a diverse variety of AToM and L2TPv3 examples on what is sometimes referred to as like-to-like attachment circuits. As the name implies, like-to-like means that the two attachment circuits use the same Layer 2 technology (that is, either two Ethernet VLAN attachment circuits or two Frame Relay attachment circuits). This section offers you a mechanism and the underlying theory to configure any-to-any IW pseudowires. IW functions perform the translation and adaptation necessary to interconnect disparate attachment circuits by means of a native service processor (NSP) function. The NSP requires knowledge of the semantics of the payload to be adapted. It resides between the pseudowire termination and the attachment circuit.

Following are the two types of Layer 2 VPN IW:

Bridged (Ethernet) Internetworking Ethernet frames that are extracted from the attachment circuit are sent over the pseudowire. In the case of 802.1q, the VLAN tag is removed. The pseudowire functions in Ethernet (VC type 0x0005) like-to-like mode, and the IW function at the NSP performs the required adaptation based on the attachment circuit technology. Non-Ethernet frames are dropped.

Routed (IP) Internetworking IP packets that are extracted from the attachment circuit are sent over the pseudowire. The pseudowire functions in IP Layer 2 Transport (VC type 0x000B) like-to-like mode, and the IW function (NSP) performs the required adaptation based on the attachment circuit technology. Non-IPv4 packets are dropped.

In general, you use Layer 2 IW to connect different Layer 2 technologies at both attachment circuits by means of a pseudowire. The actual type of IW typically depends on the end-to-end application type, such as bridged or routed. If you want to interconnect different attachment circuit technologies and carry protocols other than IP, the only current option is bridged IW.

Note

Although the real use of any-to-any is to connect dissimilar attachment circuit types, no rule states that the circuit types need to be different. You can configure a bridge IW pseudowire between two ATM virtual circuit (VC) attachment circuits. However, just because you can do it does not mean you should, because not using the native VC type has disadvantages, as you learn in the next sections. Specifically, only a subset of the possible packets received in the attachment circuit can be transported.

In the IW case, the pseudowire consists of two endpoints with the same VC type. With Ethernet IW, the two pseudowire endpoints advertise a VC type of 5 for Ethernet. In contrast, with IP IW, the two pseudowire endpoints advertise a VC type of 11 for IP Layer 2 Transport. The attachment circuits can be different, however, so an IW function deals with processing the native service. The consequence is of paramount importance: Unlike the like-to-like case in which the attachment circuit is transported transparently and unmodified, in the IW case, the attachment circuits are terminated locally. The behavior of locally terminating attachment circuits imposes some limitations, as you learn in the next two sections.

Another consequence is that the maximum transmission unit (MTU) considerations for IW scenarios differ from the like-to-like ones, not only because the PDU that is transported is different, but also because various interface types might have diverse default MTU values.

Bridged Interworking

In the Ethernet IW case, Ethernet frames are bridged across the pseudowire. The customer edge (CE) devices can either be running native Ethernet bridging or using Integrated Routing and Bridging (IRB) or Routed Bridge Encapsulation (RBE), for example, on ATM subinterfaces. This scenario shows you one of the usages for bridged IW: when a customer wants to bridge between two sites with LAN segments but the service provider access technology in one of the sites is either ATM or Frame Relay.

Bridged IW has some Layer 2-specific encapsulation behaviors, specifically when carrying bridged protocols over ATM or Frame Relay. With Ethernet over ATM, two translations by the NSP are supported when using Logical Link Control (LLC) of 0xAA-AA-03, indicating a Subnetwork Access Protocol (SNAP) header and an Organizationally Unique Identifier (OUI) of 0x00-80-C2, which means bridged protocols. The same two translations by the NSP are supported for Ethernet over Frame Relay using Control of 0x03; Pad of 0x00; Network Layer Protocol Identifier (NLPID) of 0x80, indicating a SNAP header; and an OUI of 0x00-80-C2, indicating bridged protocols:

PID 0x0007 802.3/Ethernet without preserved frame check sequence (FCS)

PID 0x000E Bridge protocol data unit (BPDU), as defined by 802.1 or 802.1(g).

Figure 14-1 shows the bridged Ethernet/802.3 frame encapsulation over Frame Relay and ATM.

Figure 14-2 shows the BPDU encapsulation over Frame Relay and ATM.

The encapsulation of bridged Ethernet over Frame Relay and ATM is defined in RFC 2427 (which obsoletes RFC 1490 and RFC 1294), "Multiprotocol Interconnect over Frame Relay," and RFC 2684 (which obsoletes RFC 1483), "Multiprotocol Encapsulation over ATM Adaptation Layer 5," respectively.

Routed Interworking

In the routed IW case, only IPv4 packets are sent over the pseudowire. Any non-IPv4 packets are dropped. Depending on the Layer 2 technology being used, IPv4 packets are identified by a specific upper layer protocol identification field: either Ethertype (0x0800), PPP dynamic link library (DLL) (0x0021), or NLPID (0xCC) for Ethernet, PPP, and Frame Relay, respectively. Because Layer 2 technologies encapsulate IP datagrams differently, the NSP IW function is required to perform translation.

Only IP packets are transported; therefore, address resolution packets are dropped. Address resolution is handled differently in diverse Layer 2 technologies:

Ethernet Using Address Resolution protocol (ARP)

Frame Relay and ATM Using Inverse ARP

PPP Using Internet Protocol Control Protocol (IPCP)

These address resolution packets are dropped, because they are not IPv4 packets. The protocol type in all cases is as follows:

ARP Ethertype 0x0806 defined in RFC 826

Inverse ARP Ethertype 0x0806 defined in RFC 2390

IPCP PPP DLL Protocol number 0x8021 defined in RFC 1332

In consequence, you need to give specific considerations to address resolution. Following are some tips for routed IW:

General consideration Because the address resolution mechanisms and packets are different, no direct translation is possible other than an NSP function involving address resolution termination and signaling.

Ethernet With native Ethernet, the provider edge (PE) device acts as a proxy-ARP to all ARP requests received from the CE.

Point-to-point ATM and Frame Relay Inverse ARP does not run by default in point-to-point Frame Relay or ATM subinterfaces, because the IP address and subnet mask define the connected prefix. Therefore, no configuration is required in the CE devices.

Multipoint ATM and Frame Relay Inverse ARP is enabled and runs by default in multipoint ATM and Frame Relay subinterfaces. Because routed IW simply drops inverse ARP packets and does not support inverse ARP, the IPv4 address at the remote end of an ATM or Frame Relay permanent virtual circuit (PVC) cannot be discovered dynamically. Therefore, in this case, manual configuration of static IPv4 to PVC mapping is needed in the CE devices.

PPP For PPP attachment circuits, manual configuration of the remote CE's IPv4 address for IPCP negotiation is needed in the PE device configuration.

Note

The address resolution considerations are applicable to routed IW because address resolution packets are not transported end-to-end over the pseudowire.

Interworking MTU Considerations

As you learned in Chapter 6, "Understanding Any Transport over MPLS," in all Layer 2 VPN IW using AToM cases except the transport of ATM cells, MTUs need to match in both attachment circuits for the pseudowire to come up. The MTU value is advertised in the MTU interface parameter.

This prerequisite takes a new meaning with IW because different interface types have different default MTU values. The default MTU values in Cisco IOS are shown in Table 14-1.

Interface Type

Default MTU

When you are configuring pseudowires between interfaces that have default MTU values (such as Packet over SONET [POS] to Ethernet), the MTU values need to match. Frame Relay has a special circumstance that is covered in the case studies.