The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This document describes the Multiprotocol Label Switching (MPLS) based L2 Virtual Private Network (L2VPN) pseudowires.
The signalling of the pseudowire and packet analysis in Cisco IOS®, IOS®-XE in order to illustrate the behavior is covered.
Layer 2 (L2) transport over MPLS and IP already exists for like-to-like attachment circuits, such as Ethernet-to-Ethernet, PPP-to-PPP, High-Level Data Link Control (HDLC), and so on
L2VPNs employ L2 services over MPLS in order to build a topology of point-to-point connections that connect end you sites in a VPN. These L2VPNs provide an alternative to private networks that have been provisioned by means of dedicated leased lines or by means of L2 virtual circuits that employ ATM or Frame Relay. The service provisioned with these L2VPNs is known as Virtual Private Wire Service (VPWS).
• Point-to-point • Referred to as Pseudowires (PWs)
• Multipoint
• xEVPN family introduces next generation solutions for Ethernet services
a. BGP control-plane for Ethernet Segment and MAC distribution and learning over MPLS core
b. Same principles and operational experience of IP VPNs
• No use of Pseudowires
a. Uses MP2P tunnels for unicast
b. Multi-destination frame delivery via ingress replication (via MP2P tunnels) or LSM
• Multi-vendor solutions under IETF standardization
• Combines scale tools from PBB (aka MAC-in-MAC) with BGP-based MAC learning from EVPN
EVPN and Provider Backbone Bridging EVPN (PBB-EVPN) are next-generation L2VPN solutions based on BGP control plane for MAC distribution/learning over the core, designed to address these requirements:
L2VPNs are built with Pseudowire (PW) technology
Notice that egress PE advertises label 3, which indicated that PHP is used.
The label mapping message that is advertised on the TLDP session contains some TLV :
Pseudowire identifier (PW ID) FEC TLV: Identifies the Pseudowire that the label is bound to
Label TLV <- LDP uses to advertised the MPLS label.
The PW ID FEC TLV contains :
1. C-bit: If set to 1 means that the control word is present.
2. PW type: Represent the type of pseudowire.
3. Group ID: Identifies the group of the pseudowire. Same group ID to all AC on the same interface. The PE can use the group ID to withdraw all the VC labels that are associated with that Group ID in one LDP label withdrawal message. This is referred to wildcard label withdrawal.
4. PW ID: PW ID is VC ID
5. Interface Parameters: Identifies the MTU of the interface towards the CE router, requested VLAN ID.
If MTU parameter does not match, then PW does not signal. Because LSP is unidirectional, a PW can be formed only if another LSP exists in the opposite direction between the same pair of PE routers.
The PW ID FEC TLV is used to identify and match the two opp LSP between a pair of PE routers,
The control word has these five functions:
Because the MPLS header has no length that indicates the length of the frames, the control word holds a length field that indicates the length of the frame.
If the received AToM packet in the egress PE router has a control word with a length that is not 0, the router knows that padding was added and can correctly remove the padding before forwarding the frames.
The first packet sent onto the PW has a sequencenumber of 1 and increments for each subsequent packet by 1 until it reaches 65535
If such out of seq detected they are dropped, re-ordering for out of sequence AToM packet is not done.
Sequencing is disabled by default.
Routers perform MPLS payload inspection. Based on that router decides how to LB the traffic.
The router looks at the firstnibble,if the first nibble = 4 then its an IPV4 packet. The generic control word starts with a nibble with vale 0, and the control word used the OAM data starts with value 1.
May be used to indicate payload fragmentation
00 = unfragmented
01 = 1st fragment
10 = last fragment
11 = intermediate fragment
As the ingress PE received the frame from the CE, it forwards the frame across the MPLS backbone to the egress LSR with two labels:
1. Tunnel label (top label) – It tells all LSR and Egress PE to where the Frame must be forwarded.
2. VC label (bottom label) – It identified the egress AC on the egress PE.
In an AToM network, each pair of PE router must run a targeted LDP session between them.
The TLDP session signals chart of the pseudowire and most importantly advertises the VC label.
Step 1. Ingress PE router first pushes the VClabel onto the frame. And then pushes the tunnel label.
Step 2. The tunnel label is the label that is associated with theIGPprefix that identifies the remote PE. The prefix is a specified bit the configuration AToM.
Step 3. TheMPLSpacket is then forwarded according to the tunnel label, hop by hop until the packet reaches the egressPE2.
Step 4. When the packet reached to the egress PE the tunnel label has already been removed. This is because of thePHPbehaviour between the last P router and the egress PE.
Step 5.
The egress PE then looks up the VC label in the forwarding information base strip off the VC label, and forwards the frame onto the correct AC.
After PE routers have set up the pseudowire, the PE can signal the Pseudowire status to the remote PE. There are two methods:
Step 1. Select the encapsulation type.
Step 2. Enable specifying the connect command on the CE facing interface.
xocnnect peer-router-id vcid encapsulation mpls
Peer-router-id: LDP router id for the remote PE router.
VCID: identifier that you assigned to the PW.
Step 3. As soon as xconnect in both the PE router configured, the targeted LDP session is established between the PE router.
Let's Initiate a Pseudowire ping from Ingress PE to Egress PE.
MPLS Echo Request and Reply packets sent over point-to-point Pseudowire.
Let's ping from PE1 to PE2:
R1#ping mpls pseudowire 10.6.6.6 100
Sending 5, 100-byte MPLS Echos to 10.6.6.6,
timeout is 2 seconds, send interval is 0 msec:
Type escape sequence to abort.
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 48/61/80 ms
Observations made:
1. ECHO Request:
Carries 2 Labels - VPN and Transport
Sent as Labeled Packet that carry PW LABEL. This can be label switched (with Transport Label)
LABELS : 2
SRC IP : LOOPBACK IP (USED IN TARGETED LDP NEIGHBORSHIP)
DST IP : 127.0.0.1
L4 TYPE : UDP
SRC PORT : 3503
DST PORT : 3505
TOS BYTE : OFF
MPLS EXP : OFF
DF BIT : ON
IPv4 OPTIONS Field is in USE: ROUTER ALERT OPTIONS FIELD ( Punt to CPU)
UDP PAYLOAD can be MPLS LABEL SWITCHING ECHO REQUEST
Overview:
Layer 2/Labels:
L3/L4:
The actual MPLS payload:
2. Echo Reply:
can carry 1 Label – Transport
Sent as UNICAST PACKET. This can be label switched (with Transport Label) because of LDP in a core.
LABELS:1
SRC IP: EXIT INTERFACE IP ADDRESS (10.1.6.2 in our case)
DST IP: SOURCE IP SEEN IN ECHO REQUEST - LOOPBACK OF SOURCE ROUTER
L4 TYPE: UDP
SRC PORT:3503
DST PORT:3505
TOS BYTE: OFF
MPLS EXP: OFF
DF BIT: ON
UDP PAYLOAD can be MPLS LABEL SWITCHING ECHO REPLY
MPLS EXP is ON and SET to 6
DF BIT is ON
VC details for reference:
R1#sh mpls l2transport vc detail
Local interface: Fa2/0 up, line protocol up, Ethernet up
Destination address: 10.6.6.6, VC ID: 100, VC status: up
Output interface: Fa0/1, imposed label stack {24 28}
Preferred path: not configured
Default path: active
Next hop: 10.1.1.2
Create time: 2d17h, last status change time: 2d17h
Last label FSM state change time: 2d17h
Signaling protocol: LDP, peer 10.6.6.6:0 up
Targeted Hello: 10.1.1.1(LDP Id) -> 10.6.6.6, LDP is UP
Status TLV support (local/remote) : enabled/supported
LDP route watch : enabled
Label/status state machine : established, LruRru
Last local dataplane status rcvd: No fault
Last BFD dataplane status rcvd: Not sent
Last BFD peer monitor status rcvd: No fault
Last local AC circuit status rcvd: No fault
Last local AC circuit status sent: No fault
Last local PW i/f circ status rcvd: No fault
Last local LDP TLV status sent: No fault
Last remote LDP TLV status rcvd: No fault
Last remote LDP ADJ status rcvd: No fault
MPLS VC labels: local 28, remote 28
Group ID: local 0, remote 0
MTU: local 1500, remote 1500
Remote interface description:
Sequencing: receive enabled, send enabled
Sequencing resync disabled
Control Word: On (configured: autosense)
Dataplane:
SSM segment/switch IDs: 4097/4096 (used), PWID: 1
VC statistics:
transit packet totals: receive 1027360, send 1027358
transit byte totals: receive 121032028, send 147740215
transit packet drops: receive 0, seq error 0, send 0
L2VPN Interworking builds on this functionality by allowing disparate attachment circuits to be connected. An interworking function facilitates the translation between different Layer 2 encapsulations. In earlier releases, the Cisco series router supported only bridged interworking, which is also known as Ethernet interworking.
Up to this point in this, the AC on both the sides has been the same encapsulation type, which is also referred to as like-to-like functionality.
L2VPN interworking is AToM feature allows different encapsulation type at both sides of the AToM network
1. IP/Routed:MAC header is removed (and replaced with MPLS labels) at one end of the MPLS cloud and a new MAC header is constructed at the other PE. The IP header is retained as it is.
2. Ethernet/Bridged: MAC header is not removed at all. The MPLS labels are imposed on top of the MAC header and the MAC header is delivered as is to the other end of the MPLS cloud.
a. FR to Ethernet
b. FR to PPP
c. FR to ATM
d. Ethernet to VLAN
e. Ethernet to PPP
Revision | Publish Date | Comments |
---|---|---|
2.0 |
16-Nov-2022 |
Updated to remove PII, Title errors, Introduction errors, machine translation, style requirements, gerunds and formatting. |
1.0 |
19-Apr-2018 |
Initial Release |