New BGP-AD VPLS site does not discover existing peers
VPLS 300 uses BGP-AD across five PEs. The existing four PEs were built with vpls-id 65000:300, RD 65000:300, and route-target import/export 65000:1300. A new PE5 is added for a new site. Its VPLS 300 is configured with vpls-id 65000:300, RD 65000:300, and route-target import/export 65000:300. The BGP session between PE5 and the route reflectors is Established, and PE5 has a valid SDP to each existing PE. However, show service id 300 bgp-ad on PE5 shows no remote VPLS peers, and no MAC addresses from the other sites appear. The existing PEs also do not list PE5. The engineer who built PE5 says the VPLS ID matches, so discovery should work. The new site is due to go live in two hours. The service must not be renumbered, because existing customer SLAs reference VPLS 300.
1. Diagnose why BGP-AD discovery is failing even though the VPLS-ID matches.
Read the worked answer
The VPLS-ID matching is necessary but not sufficient. BGP-AD uses route targets for import and export. PE5 exports RT 65000:300 and imports 65000:300, while the existing PEs use 65000:1300. PE5’s VPLS routes are therefore not imported by the existing PEs, and their routes are not imported by PE5, so no pseudowires are discovered. The BGP session being up only proves IP reachability. Check show service id 300 bgp-ad, show router bgp routes vpls, and the route-target configuration on both PE5 and an existing PE. Also confirm the RD and VPLS-ID on both sides.
2. What is the safest fix under the two-hour deadline, and what must be verified after the change?
Read the worked answer
Fix PE5 to match the existing route-target policy: import and export 65000:1300. Changing all PEs is ruled out by the SLA constraint and would put other sites at risk. Keep the RD and VPLS-ID unchanged; the RD is local but must be unique per PE, while the VPLS-ID identifies the VPLS instance. After the change, confirm bidirectional discovery with show service id 300 bgp-ad, check that remote peers appear, and verify MAC learning with show service id 300 fdb. Test with a small ping and a large frame, and confirm the pseudowire state with show service id 300 sdp.
3. What post-change checks would you perform to prove the new site is fully integrated?
Read the worked answer
Check that PE5 and at least one existing PE list each other as BGP-AD peers, that the VPLS FDB contains local and remote MACs, and that traffic flows in both directions. Verify the SDP operational state and VC labels, and confirm no MTU mismatch between the new site and existing sites. Use show service id 300 base, show service id 300 fdb, and show service id 300 sdp. If MAC learning is incomplete, clear the FDB and retest. Document the RT value; the next site must use the same policy.