L2TPv3 Pseudowires: Extending Layer 2 Over IP

Not every network that needs a Layer 2 hand-off runs MPLS. Where the transport is a plain routed IP core — a WAN, a partner network, an overlay over the internet — L2TPv3 gives you the same pseudowire service that AToM gives you over MPLS: an attachment circuit on each provider edge, a virtual circuit identifier shared by both ends, and a tunnel that carries the Layer 2 frames across the IP path. This guide covers the configuration model, the choice between signalling and manual provisioning, and the verification that proves the pseudowire is actually passing customer frames.

How L2TPv3 pseudowires are put together

Three pieces: a pseudowire class that defines the encapsulation and optional protection, an attachment circuit that binds a physical or logical interface into the service, and an xconnect statement that ties the attachment circuit to a peer address and a 32-bit VC ID. The VC ID is arbitrary but must match on both ends, and the peer+VCI pair must be unique on each device.

Building the pseudowire

pseudowire-class PW-L2TPV3
 encapsulation l2tpv3
 protocol l2tpv3
 ip local interface Loopback0
!
interface GigabitEthernet0/0/1.100
 encapsulation dot1Q 100
 xconnect 10.0.3.201 1234 encapsulation l2tpv3 pw-class PW-L2TPV3
!
! peer side (mirror image)
pseudowire-class PW-L2TPV3
 encapsulation l2tpv3
 protocol l2tpv3
 ip local interface Loopback0
!
interface GigabitEthernet0/0/2.100
 encapsulation dot1Q 100
 xconnect 10.0.3.200 1234 encapsulation l2tpv3 pw-class PW-L2TPV3

Two ordering rules from the configuration guide: if you select L2TPv3 as the data encapsulation you must specify the pw-class, and the ip local interface must be reachable from the peer — using a loopback rather than a physical interface keeps the pseudowire stable when individual links flap. For a service that carries S-tagged or QinQ traffic, keep the attachment circuit as a subinterface with the customer's encapsulation rather than a trunk port; that keeps the pseudowire scoped to one customer VLAN even on shared physical hardware.

Manual provisioning versus signalling

Signalled mode (the default) negotiates the session and brings it down if the peer's parameters disagree. Manual mode (encapsulation l2tpv3 manual, with protocol none) skips the control channel entirely: you type the session parameters on both sides and the pseudowire comes up if the transport path works. Manual mode is simpler for interop with gear that does not implement the L2TPv3 control protocol, but it also removes the health checking: the pseudowire will stay up-looking while the far end is misconfigured, so it is a debugging hazard during rollout.

Verification

show l2tun session all
show l2tun tunnel all
show xconnect all
show l2tun session circuit
ping 10.0.3.201 source Loopback0
debug l2tun session

The pseudowire is healthy when show xconnect all shows the segment in the UP state on both ends and show l2tun session all reports an established session with increasing data counters. If the session is established but the customer's ping fails, the problem is inside the attachment circuit — VLAN mismatch, wrong subinterface encapsulation, or a spanning-tree topology that blocks the customer VLAN over the pseudowire. Use show interfaces counters on both attachment circuits to prove frames are entering the tunnel, and remember that a pseudowire transports BPDUs too: if the customer network runs spanning tree, the pseudowire becomes part of its topology, which is sometimes exactly what you want and sometimes a loop.

Design notes that save days later

MTU is the classic trap: the tunnel adds an L2TPv3 header, and a pseudowire path with a 1500-byte MTU will silently drop full-size frames unless the IP transport is sized up or the customer MTU is lowered. Sequencing should be enabled when the transport can reorder packets — reordering a Layer 2 stream is far more disruptive than reordering a TCP flow. And treat the pseudowire as what it is: a Layer 2 service over a Layer 3 network, so every failure domain between the two PEs (routing reconvergence, firewall policy, NAT) becomes part of your Layer 2 availability story.

Transport design: what carries the pseudowire

An L2TPv3 pseudowire is a Layer 2 service riding a Layer 3 network, so the quality of that Layer 3 network becomes the quality of the Layer 2 service. The decisions that matter are unglamorous and consequential: does the IP path have a stable MTU, does it reorder packets, and is the latency stable enough for the protocols the customer runs over the pseudowire?

A practical MTU rule: set the customer-facing attachment circuit MTU to 1500 minus the L2TPv3 and IP overhead if you cannot raise the transport, and tell the customer explicitly. Silent black-holing of large frames is the classic pseudowire incident, and it always arrives as "the application works but file transfers hang".

Control channel, sequencing and interop

pseudowire-class PW-SEQ
 encapsulation l2tpv3
 protocol l2tpv3
 sequencing both
 ip local interface Loopback0
!
pseudowire-class PW-NOSIG
 encapsulation l2tpv3 manual
 protocol none
 ip local interface Loopback0
!
show l2tun session verbose
show l2tun tunnel all | include "Local|Remote|State"
show xconnect interface GigabitEthernet0/0/1.100

Signalled mode negotiates session parameters and uses the control channel for liveness — the pseudowire's state reflects the peer's ability to speak the protocol. Manual mode (encapsulation l2tpv3 manual with protocol none) is used for interop with implementations that do not support the control protocol: you type matching parameters on both ends and the session is deemed up when the data path works. The trap in manual mode is the absence of health checking, so a one-sided change keeps the pseudowire looking up while one direction of traffic disappears.

Sequencing is a trade: it protects the Layer 2 service from reordering introduced by the IP transport, at the cost of CPU and of masking genuine reordering that you would rather have monitored. Enable it where the transport can reorder; leave it off on a well-behaved MPLS or single-path IP core and monitor instead.

Troubleshooting in order

1. Is the IP transport healthy? Ping the peer loopback with the right source and check for loss before blaming the pseudowire.
2. Is the session established? show l2tun session all on both ends. A session stuck in an intermediate state means a parameter mismatch — VC ID, encapsulation or authentication.
3. Is the cross-connect attached? show xconnect all must show the segment up on both ends with the same VC ID.
4. Are frames entering the tunnel? Compare interface counters on both attachment circuits; input on one side should map to output on the other.
5. Is the customer protocol the problem? Check spanning tree state on the attachment circuit — a blocked customer VLAN over a working pseudowire looks exactly like a broken pseudowire from a ping test.

ping 10.0.3.201 source Loopback0 repeat 100
show l2tun session all
show xconnect all
show interfaces GigabitEthernet0/0/1.100 counters
show spanning-tree vlan 100 | include "Interface|Role"

FAQ

L2TPv3 or MPLS AToM? If you have MPLS, AToM is the native choice with better tooling and no extra encapsulation. L2TPv3 is the option when the transport is plain IP — a WAN, a partner network, or an overlay where you do not control the middle.

Can I carry multiple customers over one pseudowire? You can, but each customer should get its own attachment circuit and VC ID. Multiplexing customers into one pseudowire removes the isolation the service is supposed to provide.

How do I secure the pseudowire? The tunnel itself is not encrypted. Where the transport is untrusted, run the pseudowire over an IPsec or MACsec-protected path rather than assuming the L2TPv3 session provides confidentiality.

What happens if one end reboots? With signalling, the session renegotiates automatically. In manual mode the session may stay up while traffic is interrupted until the peer's parameters are re-established, another reason to prefer signalling where both ends support it.

Capacity and path planning

The pseudowire inherits the transport's capacity, but with an important nuance: because the tunnel carries Layer 2 frames without the flow control of a routed session, a broadcast storm inside the customer's VLAN is carried end to end. Two design consequences follow. First, cap what the pseudowire can carry by policing the attachment circuit, so that a customer-side loop degrades one service rather than saturating the transport. Second, monitor the pseudowire's utilisation separately from the underlying interface, because on a shared transport the pseudowire's traffic is indistinguishable from any other customer's until you look at the tunnel statistics.

# police the attachment circuit, then watch the counters
policy-map PW-POLICE
 class class-default
  police rate 500000000 conform-action transmit exceed-action drop
!
interface GigabitEthernet0/0/1.100
 service-policy input PW-POLICE
!
show policy-map interface GigabitEthernet0/0/1.100
show interfaces GigabitEthernet0/0/1.100 | include "rate|packets"

Plan the path for stability as well as capacity: a pseudowire that follows an automatically re-routed path will reorder and, worse, occasionally follow a longer one, which shows up as latency spikes for protocols running over the Layer 2 service. Where the transport supports it, pin the tunnel endpoints' traffic to a forwarding path with predictable latency and document that dependency — it is invisible in the pseudowire configuration and therefore easy for the next engineer to break.

Related Reading

Related reading: Cisco GRE Tunnel Configuration: Step-by-Step Example, IPsec VTI vs Policy-Based VPN: Choosing and Configuring, MPLS L3VPN Route Distinguisher and Route Target Design

原文链接：https://www.cisco.com/c/en/us/td/docs/routers/ios/config/17-x/lan-wan/b-lan-wan/m_wan-l2-tun-pro-v3-xe.html