Nokia VPLS: VPLS service configuration and provisioning

Domain 2 tests VPLS service configuration and provisioning: the order of operations, required Nokia SR OS objects, and parameter consistency between PEs.

Provisioning sequence

1. Build the underlay: ports, network interfaces, IGP, and LDP or RSVP transport.
2. Create the SDP with a far-end address and transport type.
3. Create configure service vpls <service-id> customer <customer-id> create.
4. Add local SAPs, for example sap 1/1/1:100 create.
5. Add remote bindings, for example spoke-sdp 2:100 create or mesh-sdp 2:100 create.
6. Enable and verify signaling and auto-discovery.

Core rules

• The customer ID scopes the service; the service ID must be unique on the PE.
• A SAP's port and encapsulation must be valid and unique on that port. The VLAN tag must match the CE.
• An SDP binding must reference an existing SDP and a VC ID. The far-end must be reachable before the pseudowire can come up.
• Use mesh SDPs for a full any-to-any VPLS core; use spoke SDPs where a hub/spoke or simple two-PE design is intended. Split horizon still applies to mesh.
• With BGP-AD, VPLS ID, RD, and route target values must be consistent across participating PEs.

Worked example

On PE1, configure VPLS 100 under customer 1, SAP 1/1/1:100, and spoke-sdp 2:100. On PE2, configure VPLS 100, SAP 1/1/1:100, and spoke-sdp 1:100. SDP 2 on PE1 must have far-end PE2's loopback and a working LDP session. The VC ID 100 must be coordinated. If the SDP does not exist, the binding cannot be created; if LDP is down, the SAP can be up while the pseudowire remains down.

Traps

Provisioning the SAP before the port encapsulation is correct; mismatching VC IDs; forgetting the customer; using a mesh SDP where a spoke is intended; and assuming a service is working because the SAP is up while the SDP binding is down.