I85PREP
⌘ K
Nokia VPLS study materials
Nokia VPLS study resources

Nokia VPLS: VPLS operations, verification and troubleshooting

Nokia VPLS · Work through your exam, one topic at a time.

All guide sections

VPLS operations, verification and troubleshooting

Domain 6 tests VPLS operations, verification, and troubleshooting: the order to check service, SAP, pseudowire, and transport state, and how to isolate common faults.

Verification sequence

  1. Check the service: show service id <id> base.
  2. Check SAPs: show service id <id> sap; confirm admin/oper state and encapsulation.
  3. Check SDP bindings: show service id <id> sdp; confirm the pseudowire is up.
  4. Check transport: show service sdp <sdp-id> and show router ldp session; confirm far-end reachability and labels.
  5. Check learning: show service id <id> fdb; confirm expected MACs are learned on the correct SAP or SDP binding.
  6. Check BGP-AD if used: VPLS ID, RD, route target, and peering state.

Fault isolation

  • SAP down: wrong port, encapsulation, VLAN, admin state, or filter.
  • Pseudowire down: SDP far-end unreachable, LDP session down, VC ID mismatch, MTU, or signaling failure.
  • Pseudowire up but no traffic: SAP encapsulation mismatch, filters, split horizon, missing MAC learning, or BGP-AD route-target mismatch.
  • Intermittent loss: check counters, MTU, transport errors, and redundancy state.

Worked example

Users report no connectivity between CE-A and CE-B. show service id 100 sap shows both SAPs up. show service id 100 sdp shows spoke-sdp 2:100 down. show service sdp 2 shows the far-end unreachable, and show router ldp session shows no session to PE2. The fault is in the underlay, not the VPLS SAP. After restoring IGP/LDP reachability, the SDP and pseudowire come up; show service id 100 fdb then shows CE MACs learned over the pseudowire.

Traps

Checking only the service admin state; ignoring the underlay; assuming an up SAP means the PW is up; and not checking FDB entries to confirm the data plane.