- Finding Feature Information
- Contents
- Prerequisites for L2VPN Interworking
- Restrictions for L2VPN Interworking
- Information About L2VPN Interworking
- How to Configure L2VPN Interworking
- Configuration Examples for L2VPN Interworking
- Frame Relay DLCI-to-Ethernet VLAN 802.1Q Using Bridged Internetworking: Example
- ATM AAL5-to-Ethernet VLAN 802.1Q Using Bridged Internetworking: Example
- ATM AAL5-to-Ethernet Port Using Routed Interworking: Example
- Frame Relay DLCI-to-Ethernet Port Using Routed Interworking: Example
- Ethernet-to-VLAN over AToM—Bridged: Example
- VLAN-to-ATM AAL5 over AToM (Bridged): Example
- Ethernet/VLAN-to-PPP over AToM (Routed): Example
- ATM VC-to-VC Local Switching (Different Port): Example
- ATM VP-to-VP Local Switching (Different Port): Example
- Additional References
- Feature Information for L2VPN Interworking
L2VPN Interworking
Interworking is a transforming function that is required to interconnect two heterogeneous attachment circuits (ACs). Several types of interworking functions exist. The function that is used would depend on the type of ACs being used, the type of data being carried, and the level of functionality required. The two main Layer 2 Virtual Private Network (L2VPN) interworking functions supported in Cisco IOS XE software are bridged and routed interworking.
Layer 2 (L2) transport over multiprotocol label switching (MPLS) and IP already exists for like-to-like ACs, such as Ethernet-to-Ethernet or Point-to-Point Protocol (PPP)-to-PPP. L2VPN Interworking builds on this functionality by allowing disparate ACs to be connected. An interworking function facilitates the translation between different L2 encapsulations.
Finding Feature Information
Your software release may not support all the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the "Feature Information for L2VPN Interworking" section.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Contents
•
Prerequisites for L2VPN Interworking
•Restrictions for L2VPN Interworking
•Information About L2VPN Interworking
•How to Configure L2VPN Interworking
•Configuration Examples for L2VPN Interworking
•Feature Information for L2VPN Interworking
Prerequisites for L2VPN Interworking
Before you configure L2VPN interworking on a router you must enable Cisco Express Forwarding.
Restrictions for L2VPN Interworking
The following sections list the L2VPN Interworking restrictions:
•General Restrictions for L2VPN Interworking
•Routed Interworking Restrictions
•PPP Interworking Restrictions
•Ethernet/VLAN-to-ATM AAL5 Interworking Restrictions
•Ethernet/VLAN-to-Frame Relay Interworking Restrictions
General Restrictions for L2VPN Interworking
This section lists general restrictions that apply to L2VPN interworking. Other restrictions that are platform-specific or device-specific are listed in the following sections.
•MTU configured on the AC should not exceed the MTU in the core of the network because fragmentation is not supported.
•The interworking type on one provider edge (PE) router must match the interworking type on the peer PE router.
•IP Interworking with native VLANs is not supported.
•Only the following quality of service (QoS) features are supported with L2VPN interworking:
–Static IP type of service (ToS) or MPLS experimental bit (EXP) setting in tunnel header
–One-to-one mapping of VLAN priority bits to MPLS EXP bits
Routed Interworking Restrictions
Routed interworking has the following restrictions:
•Multipoint Frame Relay (FR) is not supported.
•QoS classification on IP ToS, DSCP and other IP header fields is not supported.
•Security access control list (ACL) and other features based on IP header fields parsing are not supported.
•In routed mode, only one customer edge (CE) router can be attached to an Ethernet PE router.
•There must be a one-to-one relationship between an AC and the pseudowire. Point-to-multipoint or multipoint-to-point configurations are not supported.
•You must configure routing protocols for point-to-point operation on the CE routers when configuring an Ethernet to non-Ethernet setup.
•In the IP interworking mode, the IPv4 (0800) translation is supported. The PE router captures Address Resolution Protocol (ARP) (0806) packets and responds with its own MAC address (proxy ARP). Everything else is dropped.
•The Ethernet must contain only two IP devices: PE router and CE router. The PE router performs proxy ARP and responds to all ARP requests it receives. Therefore, only one CE router and one PE router should be on the Ethernet segment.
•If the CE routers are doing static routing, you can perform the following tasks:
–The PE router needs to learn the MAC address of the CE router to correctly forward traffic to it. The Ethernet PE router sends an Internet Control Message Protocol (ICMP) Router Discovery Protocol (RDP) solicitation message with the source IP address as zero. The Ethernet CE router responds to this solicitation message. To configure the Cisco CE router's Ethernet interface to respond to the ICMP RDP solicitation message, issue the ip irdp command in interface configuration mode. If you do not configure the CE router, traffic is dropped until the CE router sends traffic toward the PE router.
–To disable the CE routers from running the router discovery protocol, issue the ip irdp maxadvertinterval 0 command in interface configuration mode.
•When you change the interworking configuration on an Ethernet PE router, clear the ARP entry on the adjacent CE router so that it can learn the new MAC address. Otherwise, you might experience traffic drops.
PPP Interworking Restrictions
The following restrictions apply to PPP interworking:
•There must be a one-to-one relationship between a PPP session and the pseudowire. Multiplexing of multiple PPP sessions over the pseudowire is not supported.
•Only IP (IPv4 (0021) interworking is supported. Link Control Protocol (LCP) packets and Internet Protocol Control Protocol (IPCP) packets are terminated at the PE router. Everything else is dropped.
•By default, the PE router assumes that the CE router knows the remote CE router's IP address.
•Password Authentication Protocol (PAP) and Challenge-Handshake Authentication Protocol (CHAP) authentication are supported.
Ethernet/VLAN-to-ATM AAL5 Interworking Restrictions
The Ethernet/VLAN to ATM AAL5 Any Transport over MPLS (AToM) has the following restrictions:
•Only the following translations are supported; other translations are dropped:
–Ethernet without LAN FCS (AAAA030080C200070000)
–Spanning tree (AAAA030080C2000E)
•The ATM encapsulation type supported for bridged interworking is aal5snap. However, ATM encapsulation types supported for routed interworking are aal5snap and aal5mux.
•The existing QoS functionality for ATM is supported, including setting the ATM CLP bit.
•Only ATM AAL5 VC mode is supported. ATM VP and port mode are not supported.
•SVCs are not supported.
•Individual AAL5 ATM cells are assembled into frames before being sent across the pseudowire.
•Non-AAL5 traffic, (such as Operation, Administration, and Maintenance (OAM) cells) is punted to be processed at the route processor (RP) level. A VC that has been configured with OAM cell emulation on the ATM PE router (using the oam-ac emulation-enable CLI command) can send end-to-end F5 loopback cells at configured intervals toward the CE router.
•When the pseudowire is down, an F5 end-to-end segment alarm indication signal/remote defect indication (AIS/RDI) is sent from the PE router to the CE router.
•If the Ethernet frame arriving from the Ethernet CE router includes a 802.1Q header (VLAN header), due to the type of endpoint attachment (Ethernet port mode), the VLAN header stays in the frame across the pseudowire (Figure 1).
Figure 1 Protocol Stack for ATM-to-Ethernet AToM Bridged Interworking—with VLAN Header
Ethernet/VLAN-to-Frame Relay Interworking Restrictions
The Ethernet/VLAN-to-Frame Relay AToM has the following restrictions:
•Only the following translations are supported; other translations are dropped:
–Ethernet without LAN FCS (0300800080C20007)
–Spanning tree (0300800080C2000E)
•The PE router automatically supports translation of both Cisco and IETF Frame Relay encapsulation types coming from the CE router, but translates only to IETF when sending to the CE router. This is not a problem for the Cisco CE router, because it can manage IETF encapsulation upon receipt even if it is configured to send a Cisco encapsulation.
•The PVC status signaling works the same way as in the like-to-like case. The PE router reports the PVC status to the CE router based upon the availability of the pseudowire.
•The AC maximum transmission unit (MTU) must be within the supported range of MTUs when connected over MPLS.
•Only Frame Relay DLCI mode is supported. Frame Relay port mode is not supported.
•If the Ethernet frame includes a 802.1Q header (VLAN header), due to the type of endpoint attachment (Ethernet port mode), the VLAN header stays in the frame across the pseudowire (Figure 2).
•Frame Relay encapsulation types supported for routed interworking are Cisco and IETF for incoming traffic. However, IETF is also supported for outgoing traffic traveling to the CE router.
Figure 2 Protocol Stack for Frame Relay-to-Ethernet AToM Bridged Interworking—with VLAN Header
Information About L2VPN Interworking
The following sections provide an introduction to L2VPN interworking.
•Overview of L2VPN Interworking
•Ethernet/VLAN-to-ATM AAL5 Interworking
•Ethernet/VLAN-to-Frame Relay Interworking
•PPP-to-Ethernet AToM-Routed Interworking
•Static IP Addresses for L2VPN Interworking for PPP
Overview of L2VPN Interworking
L2 transport over MPLS and IP already exists for like-to-like ACs, such as Ethernet-to-Ethernet or PPP-to-PPP. L2VPN Interworking builds on this functionality by allowing disparate ACs to be connected. An interworking function facilitates the translation between the different L2 encapsulations.
Only the following interworking combinations are supported in Cisco IOS XE Release 3.3S:
•ATM-to-Ethernet - Routed interworking
•ATM-to-Ethernet - Bridged interworking
•Frame relay-to-Ethernet - Bridged interworking
•PPP-to-Ethernet - IP interworking
L2VPN Interworking Modes
L2VPN interworking works in either Ethernet (bridged) mode or IP (routed) mode. You specify the mode by issuing the interworking {ethernet | ip} command in pseudowire-class configuration mode.
The interworking command causes the ACs to be terminated locally. The two keywords perform the following functions:
•The ethernet keyword causes Ethernet frames to be extracted from the AC and sent over the pseudowire. Ethernet end-to-end transmission is resumed. AC frames that are not Ethernet are dropped. In the case of VLAN, the VLAN tag is removed, leaving an untagged Ethernet frame.
•The ip keyword causes IP packets to be extracted from the AC and sent over the pseudowire. AC frames that do not contain IPv4 packets are dropped.
The following sections explain more about Ethernet and IP interworking modes.
Ethernet or Bridged Interworking
Ethernet interworking is also called bridged interworking. Ethernet frames are bridged across the pseudowire. The CE routers could be natively bridging Ethernet or could be routing using a bridged encapsulation model, such as Bridge Virtual Interface (BVI) or Routed Bridge Encapsulation (RBE). The PE routers operate in Ethernet like-to-like mode.
This mode is used to offer the following services:
•LAN services—An example is an enterprise that has several sites, where some sites have Ethernet connectivity to the service provider (SP) network and others have ATM connectivity. If the enterprise wants LAN connectivity to all its sites, traffic from the Ethernet or VLAN of one site can be sent through the IP/MPLS network and encapsulated as bridged traffic over an ATM VC of another site.
•Connectivity services—An example is an enterprise that has different sites that are running an Internal Gateway Protocol (IGP) routing protocol, which has incompatible procedures on broadcast and nonbroadcast links. The enterprise has several sites that are running an IGP, such as Open Shortest Path First (OSPF) or Intermediate System-to-Intermediate System (IS-IS), between the sites. In this scenario, some of the procedures (such as route advertisement or designated router) depend on the underlying L2 protocol and are different for a point-to-point ATM connection versus a broadcast Ethernet connection. Therefore, the bridged encapsulation over ATM can be used to achieve homogenous Ethernet connectivity between the CE routers running the IGP.
IP or Routed Interworking
IP interworking is also called routed interworking. The CE routers encapsulate the IP on the link between the CE router and PE router. A new VC type is used to signal the IP pseudowire in MPLS. Translation between the L2 and IP encapsulations across the pseudowire is required. Special consideration needs to be given to the address resolution and routing protocol operation, because these are handled differently on different L2 encapsulations.
This mode is used to provide IP connectivity between sites, regardless of the L2 connectivity to these sites. It is different from a Layer 3 VPN because it is point-to-point in nature and the service provider does not maintain any customer routing information.
Address resolution is encapsulation dependent:
•Ethernet uses ARP
•ATM uses inverse ARP
•PPP uses IPCP
Therefore, address resolution must be terminated on the PE router. End-to-end address resolution is not supported. Routing protocols operate differently over broadcast and point-to-point media. For Ethernet, the CE routers must either use static routing or configure the routing protocols to treat the Ethernet side as a point-to-point network.
In routed interworking, IP packets that are extracted from the ACs are sent over the pseudowire. The pseudowire works in the IP Layer 2 transport (VC type 0x000B) like-to-like mode. The interworking function at network service provider's (NSP) end performs the required adaptation based on the AC technology. Non-IPv4 packets are dropped.
In routed interworking, the following considerations are to be kept in mind:
•Address resolution packets (ARP), inverse ARP, and IPCP are punted to the routing protocol. Therefore, NSP at the PE router must provide the following functionality for address resolution:
–Ethernet—PE device acts as a proxy-ARP server to all ARP requests from the CE router. The PE router responds with the MAC address of its local interface.
–ATM and Frame Relay point-to-point—By default, inverse ARP does not run in the point-to-point Frame Relay or ATM subinterfaces. The IP address and subnet mask define the connected prefix; therefore, configuration is not required in the CE devices.
•Interworking requires that the MTUs in both ACs match for the pseudowire to come up. The default MTU in one AC should match with the MTU of other AC. Table 1 lists the range of MTUs that can be configured for different ACs.
Table 1 Range of MTUs for Different ACs
|
|
|
|---|---|
ATM |
64 to 17940 |
Gigabit Ethernet |
1500 to 4470 |
POS |
64to 9102 |
Fast Ethernet |
64to 9192 |
Note The MTU configured on the AC should not exceed the MTU in the core network. This ensures that the traffic is not fragmented.
•The CE routers with Ethernet attachment VCs running OSPF must be configured with the ospfIfType option so that the OSPF protocol treats the underlying physical broadcast link as a P2P link.
Ethernet/VLAN-to-ATM AAL5 Interworking
The following topics are covered in this section:
•ATM AAL5-to-Ethernet Port AToM—Bridged Interworking
•ATM AAL5-to-Ethernet VLAN 802.1Q AToM—Bridged Interworking
•ATM-to-Ethernet—Routed Interworking
ATM AAL5-to-Ethernet Port AToM—Bridged Interworking
This interworking type provides interoperability between the ATM attachment VC and Ethernet attachment VC connected to different PE routers. Bridged encapsulation corresponding to the bridged (Ethernet) interworking mechanism is used.
The interworking function is performed at the PE router connected to the ATM attachment VC based on multiprotocol encapsulation over ATM AAL5 (Figure 3).
Figure 3 Network Topology for ATM-to-Ethernet AToM Bridged Interworking
The advantage of this architecture is that the Ethernet PE router (connected to the Ethernet segment) operates similarly to Ethernet like-to-like services.
On the PE router with interworking function, in the direction from the ATM segment to MPLS cloud, the bridged encapsulation (ATM/subnetwork access protocol (SNAP) header) is discarded and the Ethernet frame is encapsulated with the labels required to go through the pseudowire using the VC type 5 (Ethernet) (Figure 4).
In the opposite direction, after the label disposition from the MPLS cloud, Ethernet frames are encapsulated over AAL5 using bridged encapsulation.
Figure 4 shows the protocol stack for ATM-to-Ethernet AToM bridged interworking. The ATM side has an encapsulation type of aal5snap.
Figure 4 Protocol Stack for ATM-to-Ethernet AToM Bridged Interworking—without VLAN Header
ATM AAL5-to-Ethernet VLAN 802.1Q AToM—Bridged Interworking
This interworking type provides interoperability between the ATM attachment VC and Ethernet VLAN attachment VC connected to different PE routers. Bridged encapsulation corresponding to the bridged (Ethernet) interworking mechanism is used.
The interworking function is performed in the same way as for the ATM-to-Ethernet port case, implemented on the PE router connected to the ATM attachment VC. The implementation is based on multiprotocol encapsulation over ATM AAL5 (see Figure 3).
For the PE router connected to the Ethernet side, one major difference exists due the existence of the VLAN header in the incoming packet. The PE router discards the VLAN header of the incoming frames from the VLAN CE router, and the PE router inserts a VLAN header into the Ethernet frames traveling from the MPLS cloud. The frames sent on the pseudowire (with VC type 5) are Ethernet frames without the VLAN header.
Encapsulation over ATM AAL5 is shown in Figure 5.
Figure 5 Protocol Stack for ATM -to-VLAN AToM Bridged Interworking
ATM-to-Ethernet—Routed Interworking
To perform routed interworking, both the ATM PE router and Ethernet PE router must be configured. Figure 6 shows the routed interworking between ATM to Ethernet. The IP encapsulation over the pseudowire is performed on the ATM packets arriving from the ATM CE router.
The address resolution is done at the ATM PE router; it is required when the ATM CE router does an inverse ARP. It is not required when the ATM CE router is configured using Point-to-Point (P2P) subinterfaces or static maps.
When packets arrive from the Ethernet CE router, the Ethernet PE router removes the L2 frame tag, and then forwards the IP packet to the egress PE router, using IPoMPLS encapsulation over the pseudowire. The Ethernet PE router makes the forwarding decision based on the L2 circuit ID, the VLAN ID, or port ID, of the incoming L2 frame. At the ATM PE router, after label disposition, the IP packets are encapsulated over the AAL5 using routed encapsulation based on RFC 2684.
The address resolution at the Ethernet PE router can be done when the Ethernet CE router configures the static ARP, or by the proxy ARP on the Ethernet PE router. If the proxy ARP is used, the IP address of the remote CE router can be learned dynamically.
Routing protocols need to be configured to operate in the P2P mode on the Ethernet CE router.
Figure 6 Protocol Stack for ATM-to-Ethernet—Routed Interworking
Ethernet/VLAN-to-Frame Relay Interworking
The following topics are covered in this section:
•Frame Relay DLCI-to-Ethernet Port AToM—Bridged Interworking
•Frame Relay DLCI-to-Ethernet VLAN 802.1Q AToM—Bridged Interworking
•Frame Relay DLCI-to-Ethernet VLAN Qot1Q/QinQ AToM - Bridged Interworking
Frame Relay DLCI-to-Ethernet Port AToM—Bridged Interworking
This interworking type provides interoperability between the Frame Relay attachment VC and Ethernet attachment VC connected to different PE routers. Bridged encapsulation corresponding to the bridged (Ethernet) interworking mechanism is used.
For an FR-to-Ethernet port case, the interworking function is performed at the PE router connected to the FR attachment VC based on multiprotocol interconnect over Frame Relay (Figure 7). The interworking is implemented similar to an ATM-to-Ethernet case.
Figure 7 Network Topology for FR-to-Ethernet AToM Bridged Interworking
The advantage of this architecture is that the Ethernet PE router (connected to the Ethernet segment) operates similar to Ethernet like-to-like services: a pseudowire label is assigned to the Ethernet port and then the remote Label Distribution Protocol (LDP) session distributes the labels to its peer PE router. Ethernet frames are carried through the MPLS network using Ethernet over MPLS (EoMPLS).
On the PE router with interworking function, in the direction from the Frame Relay segment to the MPLS cloud, the bridged encapsulation (FR/SNAP header) is discarded and the Ethernet frame is encapsulated with the labels required to go through the pseudowire using the VC type 5 (Ethernet) (Figure 8).
In the opposite direction, after the label disposition from the MPLS cloud, Ethernet frames are encapsulated over Frame Relay using bridged encapsulation.
The following translations are supported:
•Ethernet without LAN FCS (0300800080C20007)
•Spanning tree (0300800080C2000E)
The PE router automatically supports translation of both Cisco and IETF Frame Relay encapsulation types coming from the CE, but translates only to IETF when sending to the CE router. This is not a problem for the Cisco CE router, because it can handle IETF encapsulation on receipt even if it is configured to send Cisco encapsulation.
The existing QoS functionality for Frame Relay is supported. The PVC status signaling works the same way as in the like-to-like case. The PE router reports the PVC status to the CE router, based on the availability of the pseudo wire.
The AC MTU must match when connected over MPLS. Only Frame Relay DLCI mode is supported; Frame Relay port mode is not supported in the bridged interworking.
The Figure 8 shows the protocol stack for FR-to-Ethernet bridged interworking.
Figure 8 Protocol Stack for FR-to-Ethernet AToM Bridged Interworking—without VLAN Header
Frame Relay DLCI-to-Ethernet VLAN 802.1Q AToM—Bridged Interworking
This interworking type provides interoperability between the Frame Relay attachment VC and Ethernet VLAN Attachment VC connected to different PE routers. The bridged encapsulation corresponding to the bridged (Ethernet) interworking mechanism is used.
The interworking function is performed in the same way as it is done for the Frame Relay to Ethernet port case; it is implemented on the PE router connected to the Frame Relay attachment VC, based upon a multiprotocol interconnect over Frame Relay (see Figure 8).
As in the ATM-to-VLAN case, one difference exists on the Ethernet side due the existence of the VLAN header in the incoming packet. The PE router on the VLAN side discards the VLAN header of the incoming frames from the VLAN CE router, and the PE router inserts a VLAN header into the Ethernet frames traveling from the MPLS cloud. The frames sent on the pseudowire (with VC type 5) are Ethernet frames without the VLAN header.
The Figure 9 shows the protocol stack for FR-to-VLAN AToM bridged interworking.
Figure 9 Protocol Stack for FR-to-VLAN AToM Bridged Interworking
Frame Relay DLCI-to-Ethernet VLAN Qot1Q/QinQ AToM - Bridged Interworking
This interworking type provides interoperability between the Frame Relay Attachment VC and Ethernet VLAN Attachment VC connected to different PE routers. The bridged encapsulation corresponding to bridged (Ethernet) interworking mechanism is used.
The interworking function is done in the same way as it is done for FR-to-Ethernet port case; it is implemented on the PE router connected to the Frame Relay attachment VC, based on RFC 2427(Multiprotocol Interconnect over Frame Relay).
When compared with Frame Relay DLCI-to-Ethernet port AToM, there is one major difference on the Ethernet access side, due the existence of the VLAN header in the incoming packet. The PE router on the VLAN side will discard the VLAN header of the incoming frames form the VLAN CE router, and it will insert a VLAN header into the Ethernet frames coming from the MPLS cloud. So the frames sent on the pseudo wire (with VC type 5) will be Ethernet frames without the VLAN header.
The following translations are supported on the Frame Relay PE router:
•Ethernet without LAN FCS (0300800080C20007)
•Spanning tree (0300800080C2000E)
Frame Relay encapsulation types supported for bridged interworking: Cisco and IETF for incoming traffic, IETF only for outgoing traffic towards CE router.
ATM Local Switching
•ATM like-to-like local switching allows switching data between two physical interfaces where both the segments are of ATM type. The two interfaces must be on the same PE router. Table 2 lists the supported ATM local switching combinations.
Table 2
ATM local switching - supported combinations
The following topics are covered in this section:
VC-to-VC Local Switching
VC-to-VC local switching transports cells between two ATM attachment VCs on the same or different port on the PE router. The cells coming to the PE router can be AAL0 or AAL5 encapsulated ATM packets. ATM VC-to-VC local switching can be configured either on point-to-point interface or on multipoint interface.
There are two operation modes for managing OAM cells over ATM local switching interfaces:
•OAM transparent mode: In this mode, the PE router transports F5 OAM cells transparently across local switching interfaces.
•OAM local emulation mode: In this mode, the PE router does not transport OAM cells across local switching interfaces. Instead, the interfaces locally terminate and process F5 OAM cells.
In ATM single cell relay AAL0, the ATM virtual path identifier/virtual channel identifier (VPI/VCI) values of the ingress and egress ATM interfaces of a router must match. If L2 local switching is desired between two ATM VPIs and VCIs, which are on two different interfaces and have values that do not match, ATM AAL5 should be selected. However, if ATM AAL5 uses OAM transparent mode, the VPI and VCI values must match.
ATM OAM can be configured on ATM VC mode local switching AC using the oam-ac emulation-enable and oam-pvc manage commands. When emulation is enabled on the AC, all OAM cells going through the AC are punted to RP for local processing. The ATM common component processes OAM cells and forwards the cells towards the local CE router. This helps to detect the failures on the PE router by monitoring the response at the CE router end. When the oam-pvc manage command is enabled on the AC, the PVC generates end-to-end OAM loopback cells that verify connectivity on the VC.
The following example shows a sample configuration on the ATM PE router:
configure terminal
interface atm 4/0.50 multipoint
no ip address
no atm enable-ilmi-trap
pvc 100/100 l2transport
encapsulation aal5
oam-ac emulation-enable
oam-pvc manage
interface atm 5/0.100 multipoint
no ip address
no atm enable-ilmi-trap
pvc 100/100 l2transport
encapsulation aal5
oam-ac emulation-enable
oam-pvc manage
connect atm_ls atm 4/0 100/100 atm 5/0 100/100
VP-to-VP Local Switching
VP-to-VP local switching transports cells between two VPs on the same port or different ports on the PE router. The cells coming to the PE router can be AAL0 encapsulated ATM packets only. ATM VP-to-VP local switching can be configured only on multipoint interfaces.
There are two operation modes for managing OAM cells over ATM local switching interfaces:
•OAM transparent mode: In this mode, the PE router transports F4 OAM cells transparently across local switching interfaces.
•OAM local emulation mode: In this mode, the PE router do not transport OAM cells across local switching interfaces. Instead, the interfaces locally terminate and process F4 OAM cells.
In ATM single cell relay AAL0, the ATM VPI values of the ingress and egress ATM interfaces on a router must match. If L2 switching is desired between two ATM VPIs which are on two different interfaces and have values that do not match, ATM AAL5 should be selected. If ATM AAL5 uses OAM transparent mode, the VPI value must match. Currently, the ATM VP-to-VP local switching supports only AAL0 encapsulation.
ATM OAM can be configured on the ATM VP mode local switching AC using the oam-ac emulation-enable command. When emulation is enabled on the AC, all OAM cells going through the AC are punted to RP for local processing. The ATM common component processes the OAM cells and forwards the cells towards the local CE router. This helps to detect failures on the PE router by monitoring the response at the CE router's end.
The following example shows a sample configuration on the ATM PE router:
configure terminal
interface atm 4/0.100 multipoint
no ip address
no atm enable-ilmi-trap
atm pvp 100 l2transport
encapsulation aal5
oam-ac emulation-enable
interface atm 5/0.100 multipoint
no ip address
no atm enable-ilmi-trap
atm pvp 100 l2transport
encapsulation aal5
oam-ac emulation-enable
connect atm_ls atm 4/0 100 atm 5/0 100
PPP-to-Ethernet AToM-Routed Interworking
In this interworking type, one of the ACs is Ethernet and the other is PPP. Each link is terminated locally on the corresponding PE routers and the extracted layer 3 (L3) packets are transported over a pseudowire.
The PE routers connected to Ethernet and PPP ACs terminate their respective L2 protocols. The PPP session is terminated for both the LCP and the Network Control Protocol (NCP) layers. On the ingress PE router, after extracting L3 packets, each PE router forwards the packets over the already established pseudowire using MPoMPLS encapsulation. On the egress PE router, after performing label disposition, the packets are encapsulated based on the corresponding link layer and are sent to the respective CE router. This interworking scenario requires the support of MPoMPLS encapsulation by the PE routers.
In PPP-to-Ethernet AToM routed interworking mode IPCP is supported. Proxy IPCP is automatically enabled on the PE router when IP interworking is configured on the pseudowire. By default, the PE router gets the IP address it needs to use from the CE router. The PE router accomplishes this by sending an IPCP confreq with the IP address 0.0.0.0. The local CE router has the remote CE router's IP address configured on it. The following example shows a sample configuration on the PPP CE router:
interface serial2/0
ip address 168.65.32.13 255.255.255.0
encapsulation ppp
peer default ip address 168.65.32.14 *
If the remote CE router's IP address cannot be configured on the local CE router, then the remote CE router's IP address can be configured on the PE router using the ppp ipcp address proxy ip address command on the xconnect PPP interface of PE router. The following example shows a sample configuration on the PPP PE router:
pseudowire-class mp
encapsulation mpls
protocol ldp
interworking ip
!
int se2/0
encap ppp
xconnect 10.0.0.2 200 pw-class mp
ppp ipcp address proxy 168.65.32.14
Static IP Addresses for L2VPN Interworking for PPP
If the PE router needs to perform address resolution with the local CE router for PPP, configure the remote CE router's IP address on the PE router. Use the ppp ipcp address proxy command with the remote CE router's IP address on the PE router's xconnect PPP interface. The following example shows a sample configuration:
pseudowire-class ip-interworking
encapsulation mpls
interworking ip
interface Serial2/0
encapsulation ppp
xconnect 10.0.0.2 200 pw-class ip-interworking
ppp ipcp address proxy 10.65.32.14
You can also configure the remote CE router's IP address on the local CE router with the peer default ip address command if the local CE router performs address resolution.
How to Configure L2VPN Interworking
This section describes how to configure the following L2VPN interworking features:
•Configuring L2VPN Interworking
•Configuring Ethernet/VLAN-to-ATM AAL5 Interworking
•Configuring Ethernet/VLAN-to-Frame Relay Interworking
Configuring L2VPN Interworking
L2VPN interworking allows you to connect disparate ACs. Configuring L2VPN interworking feature requires that you add the interworking command to the list of commands that make up the pseudowire. The steps for configuring the pseudowire for L2VPN interworking are included in this section. You use the interworking command as part of the overall AToM configuration. For specific instructions on configuring AToM, see the Any Transport over MPLS document.
SUMMARY STEPS
1. enable
2. configure terminal
3. pseudowire-class name
4. encapsulation {mpls | l2tpv3}
5. interworking {ethernet | ip | vlan}
6. end
DETAILED STEPS
Verifying the L2VPN Configuration
You can verify L2VPN configuration using the following steps:
•You can issue the show arp command between the CE routers to ensure that data is being sent:
Router# show arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 10.1.1.5 134 0005.0032.0854 ARPA FastEthernet0/0/0
Internet 10.1.1.7 - 0005.0032.0000 ARPA FastEthernet0/0/0
•You can issue the ping command between the CE routers to ensure that data is being sent:
Router# ping 10.1.1.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
•You can verify the AToM configuration by using the show mpls l2transport vc detail command.
Configuring Ethernet/VLAN-to-ATM AAL5 Interworking
This section explains the following AToM configurations:
•ATM AAL5-to-Ethernet Port on a PE2 Router
•ATM AAL5-to-Ethernet VLAN 802.1Q on a PE1 Router
•ATM AAL5-to-Ethernet VLAN 802.1Q on a PE2 router
ATM AAL5-to-Ethernet Port
You can configure the ATM AAL5-to-Ethernet Port feature on a PE1 router using the following steps:
SUMMARY STEPS
1. enable
2. configure terminal
3. mpls label protocol ldp
4. interface type number
5. ip address ip-address mask
6. pseudowire-class [pw-class-name]
7. encapsulation mpls
8. interworking {ethernet | ip | vlan}
9. interface atm slot/subslot/port.subinterface number
10. pvc [name] vpi/vci 12transport
11. encapsulation aal5snap
12. xconnect ip-address vc-id pw-class pw-class-name
13. end
DETAILED STEPS
ATM AAL5-to-Ethernet Port on a PE2 Router
You can configure the ATM AAL5-to-Ethernet Port feature on a PE2 router using the following steps:
SUMMARY STEPS
1. enable
2. configure terminal
3. mpls label protocol ldp
4. interface type number
5. ip address ip-address mask
6. pseudowire-class [pw-class-name]
7. encapsulation mpls
8. interworking {ethernet | ip | vlan}
9. interface type slot/subslot/port
10. xconnect ip-address vc-id pw-class pw-class-name
11. end
DETAILED STEPS
Note When configuring bridged interworking, the PE2 router configuration does not include the interworking ethernet command because it is treated as like-to-like, and also because the AC is already an Ethernet port. However, when configuring routed interworking, the interworking ip command is required.
ATM AAL5-to-Ethernet VLAN 802.1Q on a PE1 Router
You can configure the ATM AAL5-to-Ethernet VLAN 802.1Q feature on a PE1 router using the following steps:
SUMMARY STEPS
1. enable
2. configure terminal
3. mpls label protocol ldp
4. interface type number
5. ip address ip-address mask
6. pseudowire-class [pw-class-name]
7. encapsulation mpls
8. interworking {ethernet | ip | vlan}
9. interface atm slot/subslot/port.subinterface-number
10. pvc [name] vpi/vci 12transport
11. encapsulation aal5snap
12. xconnect ip-address vc-id pw-class pw-class-name
13. end
DETAILED STEPS
ATM AAL5-to-Ethernet VLAN 802.1Q on a PE2 router
You can configure the ATM AAL5-to-Ethernet VLAN 802.1Q feature on a PE2 router using the following steps:
SUMMARY STEPS
1. enable
2. configure terminal
3. mpls label protocol ldp
4. interface type number
5. ip address ip-address mask
6. pseudowire-class [pw-class-name]
7. encapsulation mpls
8. interworking {ethernet | ip | vlan}
9. interface type slot/subslot/port.subinterface-number
10. encapsulation dot1q vlan-id
11. xconnect ip-address vc-id pw-class pw-class-name
12. end
DETAILED STEPS
Note In the case of ATM AAl5-to-VLAN, the PE2 router configuration includes the interworking command for both bridged and routed interworking.
Note To verify the L2VPN interworking status and check the statistics, refer to the "Verifying L2VPN Interworking" section.
Configuring Ethernet/VLAN-to-Frame Relay Interworking
This section explains the following AToM configurations and provides examples. Figure 7 illustrates different AToM configurations.
•Frame Relay DLCI-to-Ethernet Port on a PE1 Router
•Frame Relay DLCI-to-Ethernet Port on a PE2 router
•Frame Relay DLCI-to-Ethernet VLAN 802.1Q on a PE1 Router
•Frame Relay DLCI-to-Ethernet VLAN 802.1Q on a PE2 Router
Frame Relay DLCI-to-Ethernet Port on a PE1 Router
You can configure the Frame Relay DLCI-to-Ethernet Port feature on a PE1 router using the following steps:
SUMMARY STEPS
1. enable
2. configure terminal
3. mpls label protocol ldp
4. interface type number
5. ip address ip-address mask
6. pseudowire-class [pw-class-name]
7. encapsulation mpls
8. interworking ethernet
9. interface type slot/subslot/port
10. encapsulation frame-relay
11. connect connection-name interface dlci {interface dlci | l2transport}
12. xconnect ip-address vc-id pw-class pw-class-name
13. end
DETAILED STEPS
Frame Relay DLCI-to-Ethernet Port on a PE2 router
You can configure the Frame Relay DLCI-to-Ethernet Port feature on a PE2 router using the following steps:
SUMMARY STEPS
1. enable
2. configure terminal
3. mpls label protocol ldp
4. interface type number
5. ip address ip-address mask
6. pseudowire-class [pw-class-name]
7. encapsulation mpls
8. interworking ethernet
9. interface type slot/subslot/port
10. xconnect ip-address vc-id pw-class pw-class-name
11. end
DETAILED STEPS
Note When configuring bridged interworking, the PE2 router configuration does not include the interworking ethernet command because it is treated as like-to-like, and also because the AC is already an Ethernet port. However, when configuring routed interworking, the PE2 router configuration does include the interworking ip command.
Frame Relay DLCI-to-Ethernet VLAN 802.1Q on a PE1 Router
To configure the Frame Relay DLCI-to-Ethernet VLAN 802.1Q feature on a PE1 router, use the following steps:
SUMMARY STEPS
1. enable
2. configure terminal
3. mpls label protocol ldp
4. interface type number
5. ip address ip-address mask
6. pseudowire-class [pw-class-name]
7. encapsulation mpls
8. interworking {ethernet | ip | vlan}
9. frame-relay switching
10. interface type slot/subslot/port
11. encapsulation frame-relay
12. frame-relay intf-type [dce]
13. connect connection-name interface dlci {interface dlci | l2transport}
14. xconnect ip-address vc-id pw-class pw-class-name
15. end
DETAILED STEPS
Frame Relay DLCI-to-Ethernet VLAN 802.1Q on a PE2 Router
To configure the Frame Relay DLCI-to-Ethernet VLAN 802.1Q feature on a PE2 router, use the following steps:
SUMMARY STEPS
1. enable
2. configure terminal
3. mpls label protocol ldp
4. interface type number
5. ip address ip-address mask
6. pseudowire-class [pw-class-name]
7. encapsulation mpls
8. interworking {ethernet | ip | vlan}
9. interface type slot/subslot/port.subinterface-number
10. encapsulation dot1q vlan-id
11. xconnect ip-address vc-id pw-class pw-class-name
12. end
DETAILED STEPS
Note In the case of an Frame Relay DLCI-to-VLAN, the PE2 router configuration includes the interworking command for both bridged and routed interworking.
Note To verify the L2VPN interworking status and check the statistics, refer to the "Verifying L2VPN Interworking" section.
Verifying L2VPN Interworking
To verify the L2VPN status (in the AToM configuration), use the following commands:
•show connection [all | name | id | elements | port]
•show xconnect [all | interface | peer]
•show mpls l2transport [binding | checkpoint | hw-capability | summary | vc]
•show mpls infrastructure lfd pseudowire vcid
Configuration Examples for L2VPN Interworking
The following sections show examples of L2VPN interworking:
•Frame Relay DLCI-to-Ethernet VLAN 802.1Q Using Bridged Internetworking: Example
•ATM AAL5-to-Ethernet VLAN 802.1Q Using Bridged Internetworking: Example
•ATM AAL5-to-Ethernet Port Using Routed Interworking: Example
•Frame Relay DLCI-to-Ethernet Port Using Routed Interworking: Example
•Ethernet-to-VLAN over AToM—Bridged: Example
•VLAN-to-ATM AAL5 over AToM (Bridged): Example
•Ethernet/VLAN-to-PPP over AToM (Routed): Example
•ATM VC-to-VC Local Switching (Different Port): Example
•ATM VP-to-VP Local Switching (Different Port): Example
Frame Relay DLCI-to-Ethernet VLAN 802.1Q Using Bridged Internetworking: Example
The following example shows how to configure the Frame Relay DLCI-to-Ethernet VLAN 802.1Q feature using bridged interworking:
ATM AAL5-to-Ethernet VLAN 802.1Q Using Bridged Internetworking: Example
The following example shows how to configure the ATM AAL5-to-Ethernet VLAN 802.1Q feature using bridged interworking:
ATM AAL5-to-Ethernet Port Using Routed Interworking: Example
The following example shows how to configure the ATM AAL5-to-Ethernet Port feature using routed interworking:
Frame Relay DLCI-to-Ethernet Port Using Routed Interworking: Example
The following example shows how to configure the Frame Relay DLCI-to-Ethernet Port feature using routed interworking:
Ethernet-to-VLAN over AToM—Bridged: Example
The following example shows how to configure Ethernet-to-VLAN over AToM in a PE router:
VLAN-to-ATM AAL5 over AToM (Bridged): Example
The following example shows the configuration of VLAN-to-ATM AAL5 over AToM:
Ethernet/VLAN-to-PPP over AToM (Routed): Example
The following example shows the configuration of Ethernet VLAN-to-PPP over AToM
ATM VC-to-VC Local Switching (Different Port): Example
The following example shows the configuration of ATM VC-to-VC local switching:
ATM VP-to-VP Local Switching (Different Port): Example
The following example shows the configuration of ATM VP-to-VP local switching:
Additional References
The following sections provide references related to the L2VPN Interworking feature.
Related Documents
|
|
|
|---|---|
Cisco IOS commands |
|
MPLS commands |
|
Any Transport over MPLS |
Standards
MIBs
RFCs
|
|
|
|---|---|
No new or modified RFCs are supported by this feature, and support for existing RFCs has not been modified by this feature. |
— |
Technical Assistance
Feature Information for L2VPN Interworking
Table 3 lists the features in this module and provides links to specific configuration information.
Use Cisco Feature Navigator to find information about platform support and software image support. Cisco Feature Navigator enables you to determine which Cisco IOS XE software images support a specific software release, feature set, or platform. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Note Table 3 lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.
|
|
|
|
|---|---|---|
L2VPN Interworking |
Cisco IOS XE Release 2.4 |
This feature allows disparate ACs to be connected. An interworking function facilitates the translation between the different Layer 2 encapsulations. The following sections provides information about this feature: • • • The following commands were introduced or modified: debug frame-relay pseudowire, debug ssm, interworking, mtu, pseudowire-class, show l2tun session, show l2tun tunnel, show mpls l2transport vc, show platform. |
L2VPN Interworking: Ethernet VLAN to Frame Relay |
Cisco IOS XE Release 3.3S |
This feature allows interworking of Ethernet VLANs with Frame Relay DLCIs. The following command was modified: interworking The following section provides information about this feature: |
L2VPN Interworking-Ethernet VLAN to PPP |
Cisco IOS XE Release 3.3S |
The L2VPN interworking - Ethernet VLAN-to-PPP feature allows disparate ACs to be connected. An interworking function facilitates the translation between the following Layer 2 encapsulations. • The following sections provide information about this feature: • • • |
Feedback