Nokia VPLS: VPLS pseudowires

Domain 3 tests VPLS pseudowires: how Ethernet frames are carried between PEs, how pseudowires are signaled and identified, and how mesh and spoke bindings differ.

Pseudowire anatomy

• A pseudowire is an emulated Ethernet circuit between two SDP bindings. The SDP provides the transport tunnel; the VC ID identifies the pseudowire within that tunnel.
• Nokia SR OS uses spoke-sdp <sdp-id>:<vc-id> and mesh-sdp <sdp-id>:<vc-id> bindings under the VPLS.
• LDP signaling exchanges pseudowire labels and status. BGP-AD can automate discovery of VPLS members; the VPLS ID, RD, and route target identify the service.
• The data plane carries Ethernet frames with a pseudowire label over the transport label. MTU must accommodate the customer frame plus encapsulation.

Mesh and spoke rules

• A mesh SDP is intended for full-mesh VPLS connectivity. Split horizon blocks forwarding from one mesh SDP to another to prevent loops.
• A spoke SDP is a single attachment to a remote PE and does not have the same mesh-to-mesh restriction. It is useful for hub-and-spoke or two-PE designs.
• The VC ID must be coordinated with the far end. A mismatch or unreachable SDP far-end leaves the pseudowire down.
• Pseudowire status is separate from SAP status: the local SAP can be up while the PW is down.

Worked example

PE1 and PE2 each have VPLS 100. PE1 configures mesh-sdp 2:100; PE2 configures mesh-sdp 1:100. LDP is up and each PE advertises a label for VC ID 100. A frame from CE-A enters PE1's SAP, is flooded over the mesh PW, and PE2 learns CE-A's MAC on its mesh binding. If PE1 adds PE3 with another mesh binding, frames received from PE2 are not sent to PE3 by PE1; the full mesh must provide that path.

Traps

Treating the SDP as the pseudowire; using the same VC ID for different services on one SDP without checking; expecting spoke SDPs to be looped by split horizon; and forgetting that MTU or label/status failures keep the PW down even when the SAP is up.