Date created: Thursday, July 30, 2015 10:35:04 AM. Last modified: Sunday, December 3, 2023 4:44:41 PM

Pseudowires (PWE3) - Cisco

References
Cisco Press Layer 2 VPN Architectures (Pages 33, 154, 155)

Pseudowire MTU Sizing

The MTU for PE-to-PE/P router links must take into account the overhead of the service provider core and the attachment circuit requirements:

  • Core Ethernet headers (SA/DA/Ethertype) = 14 octets
  • MPLS Transport Label (remote PE loopback) = 4 octets
  • VC Label (remote PE attachment circuit) = 4 octets
  • PWE3 Control Word = 4 octets
  • Customer Ethernet headers (SA/DA/Ethertype) = 14 Octets
  • Customer VLAN Tag (optional, maybe double) = 4 Octets
  • Customer 1500 octet Ethernet payload = 1500 octets
  • Total (minimum SP MTU required) = 1544 octets

 

This requirement will vary by hardware/software vendor. For classical Cisco IOS and IOS-XE the core Ethernet headers do no need to be accounted for. For IOS-XR and Juniper's Junos they must be included. So the above example means an IOS/IOS-XE interface must be configured with a minimum of 1530 but Junos and IOS-XR require a minimum setting of 1544.

The MTU size of the attachment circuits must also match which again means that the configuration will vary by vendor. For IOS and IOS-XE a VLAN tagged sub-interface which supports a 1500 octet Ethernet payload does not require the sub-interface or physical interface to be configured to 1504 bytes, the layer 2 headers are included automatically. As long as both PE AC's are configured as 1500 the pseudowire will establish. With Junos and IOS-XR both ends would need to be configured as 1504.

 

VC Types
EoMPLS can operate in two modes: port-tunneling mode and VLAN-tunneling mode. Port-tunneling is also referred to as port-to-port transport. VLAN tunneling expects tagged frames to enter the AC however in port mode untagged, single tagged, double tagged etc can all enter and are transported as is (unless the PE is configured otherwise, such as tag pop/swap/push).

Within classical Cisco IOS VLAN tunneled interfaces use VC type 4, or, 0x0004, and port-tunneled interfaces use VC type 5, or 0x0005 (as specified in the draft-martini). Cisco devices support both VC types.
Note that newer Cisco implementations provide for auto-sensing of the VC type.

In VLAN-tunneling mode, the ingress information for the VLAN is contained within the dot1Q header of the packet. By looking at the VLAN ID in the dot1Q header, the network processor (NP) can determine the next step in processing, described in the "Label Imposition" below.

In port-tunneling mode, the packet does not have ingress port information. For inclusion of ingress information, the port-tunneled interface is put into the QinQ mode. A hidden VLAN is then created and added onto the packet. A hidden VLAN is a VLAN that is numbered outside the allowed range for VLAN IDs. This is how the NP learns the ingress information. The hidden VLAN concept applies to a switch platform (that is, 6500 and 7600 platforms). In contrast, VLAN-tunneled mode does not require a hidden VLAN. The NP can discern the ingress information from the packet's dot1Q header.

A similar concept applies to routers (VLAN stacking method). It involves the use of sub-interfaces. Another difference between the port-tunneling mode and VLAN-tunneling mode is in the handling of VLAN IDs. In port-tunneling mode, the VLAN ID is transparently passed from the ingress PE to the egress PE over MPLS in a single VLAN. In VLAN-tunneling mode, however, the VLAN ID at each end of the EoMPLS tunnel can be different. To overcome this, the egress side of the tunnel that is mapped to a VLAN rewrites the VLAN ID in outgoing dot1Q packets to the ID of the local VLAN.

 

Label Imposition
Label imposition is performed on the label imposition router (an ingress PE). Routers receive a Layer 2 packet and encapsulates it for the MPLS backbone. Depending on whether the port-tunneling or VLAN-tunneling mode is used, the interfaces that receive the Layer 2 packets can be either Ethernet port interfaces or VLAN interfaces (or sub-interfaces).

To impose labels on packets the ingress PE router maintains a table which associates an EoMPLS tunnel with an interface/FEC. This table keeps the information needed for sending the packet, such as the outgoing interface and encapsulation.

The label imposition process involves the following:


1. A two-level label stack, both labels are learnt via LDP (using draft Martini which is the default for Cisco) for each VC (the IGP label/transport label and VC label via a targeted LDP session). A NP also provides a MAC rewrite that contains the outgoing Layer 2 encapsulation in addition to the label stack that changes the encapsulation of the packet to comply with the outgoing interface.

2. The label stack and the output MAC encapsulation are prepended to the packet, and the
packet is forwarded to the egress interface for transmission.

3. The outgoing VC label's TTL field is set to 2.

After label imposition, the packets travel across the MPLS core network via standard label switching and arrive at the egress PE. At that point, it might already have the tunnel label removed and be left with only the VC label (due to PHP).

 

Label Disposition
Label disposition refers to label removal from a packet. It is performed at the egress PE, or the label disposition router. This router receives a packet, strips the bottom (VC) label (and the top [PSN] label if it exists, in cases such as explicit-null, [think PHP]), and sends the remaining Layer 2 frame out of the egress attachment circuit interface.

When the egress PE receives the packet with the VC label, it needs to select an appropriate form of disposition. For this the egress PE checks the label forwarding information base (LFIB). The LFIB contains information about the binding between the outgoing interface and a given VC ID, which was initially inserted into the LFIB with the VC label. The LFIB lookup informs the PE that EoMPLS disposition will be performed and finds the corresponding egress interface for the VC. The VC label is then popped, the VLAN ID is rewritten (if needed), and the frame is transmitted to the proper outgoing interface.

 

Pseudowire Control-Word
When creating LDP signalled pseudowires on Cisco IOS/XE/XR devices the control word is included automatically. The same is also true for BGP signaled L2VPNs such as BGP signalled VPLS. For Juniper it has to be specifically enabled for BGP signaled VPLS, for LDP signaled pseudowires it is enabled by default and can be disabled if required.

! Cisco IOS
pseudowire-class PWE3C-Test
 encapsulation mpls
 no control-word

interface Gi0/1
 no ip address
 xconnect 1.1.1.1 123 encapsulation mpls pw-class PWE3C-Test


# Junos
set interfaces ge-0/0/1 encapsulation ethernet-ccc
set interfaces ge-0/0/1 unit 0 family ccc
set protocols l2circuit neighbor 1.1.1.2 interface ge-0/0/1.0 virtual-circuit-id 123
set protocols l2circuit neighbor 1.1.1.2 interface ge-0/0/1.0 no-control-word

Previous page: PPP Session Establishment
Next page: Pseudowires (PWE3)