This article details a step-by-step procedure to troubleshoot generic Virtual Private LAN Service (VPLS) Control Plane issues.
Note: The scope of this article is limited to BGP signaled VPLS setup as described in RFC4761. If your scenario is not addressed here, also refer to KB25099 - VPLS Resources for Junos devices [juniper.net] .
Goal
To troubleshoot issues related to VPLS connection setup
Symptoms
VPLS connection is not listed.
VPLS connection is not UP.
If the VPLS connection is UP, and you are having trouble with traffic passing, refer to KB24986 - Resolution Guide - MX - VPLS Troubleshooting (Forwarding Plane) - VPLS connection is up but not passing data [juniper.net] .
Topology used for this guide
Perform the following steps:
Note : Although these troubleshooting steps can be applied for all code versions and for all platforms, this troubleshooting guide is written primarily keeping the MX platform in mind.
For the flowchart version of these steps, click the flowchart icon:
Run the command show vpls connections , and observe the list of connections.
show vpls connections
user@PE2# run show vpls connections Layer-2 VPN connections: Legend for connection status (St) EI -- encapsulation invalid NC -- interface encapsulation not CCC/TCC/VPLS EM -- encapsulation mismatch WE -- interface and instance encaps not same VC-Dn -- Virtual circuit down NP -- interface hardware not present CM -- control-word mismatch -> -- only outbound connection is up CN -- circuit not provisioned <- -- only inbound connection is up OR -- out of range Up -- operational OL -- no outgoing label Dn -- down LD -- local site signaled down CF -- call admission control failure RD -- remote site signaled down SC -- local and remote site ID collision LN -- local site not designated LM -- local site ID not minimum designated RN -- remote site not designated RM -- remote site ID not minimum designated XX -- unknown connection status IL -- no incoming label MM -- MTU mismatch MI -- Mesh-Group ID not available BK -- Backup connection ST -- Standby connection PF -- Profile parse failure PB -- Profile busy RS -- remote site standby SN -- Static Neighbor VM -- VLAN ID mismatch Legend for interface status Up -- operational Dn -- down Instance: vpls Local site: CE2 (20) connection-site Type St Time last up # Up trans 10 rmt Up Apr 10 14:05:52 2012 1 <------- Remote PE: 1.1.1.1, Negotiated control-word: No Incoming label: 800025, Outgoing label: 800035 Local interface: vt-1/2/10.1051905, Status: Up, Encapsulation: VPLS Description: Intf - vpls vpls local site 20 remote site 10
The above example command output was taken on router PE2. The connection to site 10 is listed, but the connection to site 30 is NOT listed. For more information about the command show vpls connections , refer to show vpls connections .
Is the VPLS connection listed for the remote site in question? No - Continue to Step 2. Yes - Connection is listed. If the connection status ( St ) is Up , and there is an issue with passing traffic, then continue to KB24986 - Resolution Guide - MX - VPLS Troubleshooting (Forwarding Plane) - VPLS connection is up but not passing data [juniper.net] . If the connection status ( St ) is not Up , then continue to KB25097 - Troubleshoot VPLS connection status flags when VPLS connection is down [juniper.net] .
Is the VPLS connection listed for the remote site in question?
No - Continue to Step 2.
Yes - Connection is listed.
If the connection status ( St ) is Up , and there is an issue with passing traffic, then continue to KB24986 - Resolution Guide - MX - VPLS Troubleshooting (Forwarding Plane) - VPLS connection is up but not passing data [juniper.net] .
St
If the connection status ( St ) is not Up , then continue to KB25097 - Troubleshoot VPLS connection status flags when VPLS connection is down [juniper.net] .
The first logical point of troubleshooting is to check if there are issues in the core with IGP and iBGP.
Use the following commands to verify IGP and iBGP:
IGP: Use show route <egress_PE_prefix> extensive , specifying the loopback IP address of egress PE router at the other end from which you are not seeing the VPLS connection listed in Step 1.
show route <egress_PE_prefix> extensive
For example, if PE2 cannot reach PE3, run the following command:
PE2> show route 3.3.3.3 extensive
If the route is not in the local PE routing table, and is the primary route, ping the route to verify connectivity. If not pingable, troubleshoot IGP.
IBGP: Use show bgp neighbor <PE_neighbor_address> , specifying the PE router at the other end. Make sure that the status of the BGP neighbor relationship is ESTABLISHED; if not, troubleshoot issues with iBGP. For more information about the command output, refer to show bgp neighbor .
show bgp neighbor <PE_neighbor_address>
Note: If there are any issues with the LSPs in the core, the connection will be listed in the output shown in Step 1 but it will not be in the Up state; in this case, refer to KB25097 - Troubleshoot VPLS connection status flags when VPLS connection is down [juniper.net] .
Up
Is the VPLS connection listed after verifying IGP and iBGP? No - It is still not listed - Continue to Step 3 . Yes - Connection is listed. If the connection status ( St ) is Up and there is an issue with passing traffic, then continue to KB24986 - Resolution Guide - MX - VPLS Troubleshooting (Forwarding Plane) - VPLS connection is up but not passing data [juniper.net] . If the connection status ( St ) is not Up, then continue to KB25097 - Troubleshoot VPLS connection status flags when VPLS connection is down [juniper.net] .
Is the VPLS connection listed after verifying IGP and iBGP?
No - It is still not listed - Continue to Step 3 .
If the connection status ( St ) is Up and there is an issue with passing traffic, then continue to KB24986 - Resolution Guide - MX - VPLS Troubleshooting (Forwarding Plane) - VPLS connection is up but not passing data [juniper.net] .
If the connection status ( St ) is not Up, then continue to KB25097 - Troubleshoot VPLS connection status flags when VPLS connection is down [juniper.net] .
Verify that all the PE routers belonging to the VPLS instance are advertising the correct BGP NLRI updates (VPLS signaling routes).
Run the command show route advertising-protocol bgp <PE_neighbor> table R_I.l2vpn.0 extensive on all the affected PE routers of the VPLS network. Working Example: In the command output taken on PE3, you see that PE3 is correctly announcing VPLS signaling information to the PE2 peer (2.2.2.2). PE3# run show route advertising-protocol bgp 2.2.2.2 table vpls.l2vpn.0 extensive vpls.l2vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden) * 3.3.3.3:6:20:9/96 (1 entry, 1 announced) BGP group ibgp type Internal Route Distinguisher: 3.3.3.3:6 Label-base: 800016, range: 8 Nexthop: Self Flags: Nexthop Change Localpref: 100 AS path: [100] I Communities: target:100:1 Layer2-info: encaps:VPLS, control flags:, mtu: 0, site preference: 100 * 3.3.3.3:6:20:17/96 (1 entry, 1 announced) BGP group ibgp type Internal Route Distinguisher: 3.3.3.3:6 Label-base: 800000, range: 8 Nexthop: Self Flags: Nexthop Change Localpref: 100 AS path: [100] I Communities: target:100:1 Layer2-info: encaps:VPLS, control flags:, mtu: 0, site preference: 100
Run the command show route advertising-protocol bgp <PE_neighbor> table R_I.l2vpn.0 extensive on all the affected PE routers of the VPLS network.
show route advertising-protocol bgp <PE_neighbor> table R_I.l2vpn.0 extensive
Working Example: In the command output taken on PE3, you see that PE3 is correctly announcing VPLS signaling information to the PE2 peer (2.2.2.2).
PE3# run show route advertising-protocol bgp 2.2.2.2 table vpls.l2vpn.0 extensive vpls.l2vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden) * 3.3.3.3:6:20:9/96 (1 entry, 1 announced) BGP group ibgp type Internal Route Distinguisher: 3.3.3.3:6 Label-base: 800016, range: 8 Nexthop: Self Flags: Nexthop Change Localpref: 100 AS path: [100] I Communities: target:100:1 Layer2-info: encaps:VPLS, control flags:, mtu: 0, site preference: 100 * 3.3.3.3:6:20:17/96 (1 entry, 1 announced) BGP group ibgp type Internal Route Distinguisher: 3.3.3.3:6 Label-base: 800000, range: 8 Nexthop: Self Flags: Nexthop Change Localpref: 100 AS path: [100] I Communities: target:100:1 Layer2-info: encaps:VPLS, control flags:, mtu: 0, site preference: 100
t:100:1 Layer2-info: encaps:VPLS, control flags:, mtu: 0, site preference: 100
After analyzing the above command output on the affected routers, are the PE routers advertising the correct BGP NLRIs (VPLS signaling routes)? Yes - Continue to Step 4 . No - Check the following: Verify configuration on the interested routers. Check if the correct vrf target is set; the vrf target should be the same on all the PE routers involved in VPLS signaling for any particular instance. Check if the correct signaling is configured for the VPLS under protocol bgp , and is under the intended bgp neighbor/group. Check the configuration to see if the same AS site ID is configured at both ends. If so, this is incorrect; they must be different. After performing the above checks, if the interested PE routers are sending the VPLS route information to every other PE router and still the VPLS connection is not listed, then continue to Step 4 .
After analyzing the above command output on the affected routers, are the PE routers advertising the correct BGP NLRIs (VPLS signaling routes)?
Yes - Continue to Step 4 .
No - Check the following:
Verify configuration on the interested routers. Check if the correct vrf target is set; the vrf target should be the same on all the PE routers involved in VPLS signaling for any particular instance.
Check if the correct signaling is configured for the VPLS under protocol bgp , and is under the intended bgp neighbor/group.
protocol bgp
Check the configuration to see if the same AS site ID is configured at both ends. If so, this is incorrect; they must be different.
After performing the above checks, if the interested PE routers are sending the VPLS route information to every other PE router and still the VPLS connection is not listed, then continue to Step 4 .
Verify that all the PE routers belonging to the VPLS instance are receiving the correct BGP NLRI updates (VPLS signaling routes).
Run the command show route receive-protocol bgp <PE_neighbor> table R_I.l2vpn.0 extensive on all the affected PE routers to verify if it is receiving signaling routes from all the PEs. You can also verify if all the intended VPLS routes are in the local PE routing table by looking in to show bgp summary . Working example output: In the command output taken on PE2, you can see that PE2 is receiving the correct VPLS signaling information from PE3 (3.3.3.3). PE2# run show route receive-protocol bgp 3.3.3.3 table vpls.l2vpn.0 extensive vpls.l2vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden) * 3.3.3.3:6:20:9/96 (1 entry, 1 announced) Import Accepted Route Distinguisher: 3.3.3.3:6 Label-base: 800008, range: 8 Nexthop: 3.3.3.3 Localpref: 100 AS path: I Communities: target:100:1 Layer2-info: encaps:VPLS, control flags:, mtu: 0, site preference: 25600 * 3.3.3.3:6:20:17/96 (1 entry, 1 announced) Import Accepted Route Distinguisher: 3.3.3.3:6 Label-base: 800000, range: 8 Nexthop: 3.3.3.3 Localpref: 100 AS path: I Communities: target:100:1 Layer2-info: encaps:VPLS, control flags:, mtu: 0, site preference: 25600
Run the command show route receive-protocol bgp <PE_neighbor> table R_I.l2vpn.0 extensive on all the affected PE routers to verify if it is receiving signaling routes from all the PEs. You can also verify if all the intended VPLS routes are in the local PE routing table by looking in to show bgp summary .
show route receive-protocol bgp <PE_neighbor> table R_I.l2vpn.0 extensive
show bgp summary
PE2# run show route receive-protocol bgp 3.3.3.3 table vpls.l2vpn.0 extensive vpls.l2vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden) * 3.3.3.3:6:20:9/96 (1 entry, 1 announced) Import Accepted Route Distinguisher: 3.3.3.3:6 Label-base: 800008, range: 8 Nexthop: 3.3.3.3 Localpref: 100 AS path: I Communities: target:100:1 Layer2-info: encaps:VPLS, control flags:, mtu: 0, site preference: 25600 * 3.3.3.3:6:20:17/96 (1 entry, 1 announced) Import Accepted Route Distinguisher: 3.3.3.3:6 Label-base: 800000, range: 8 Nexthop: 3.3.3.3 Localpref: 100 AS path: I Communities: target:100:1 Layer2-info: encaps:VPLS, control flags:, mtu: 0, site preference: 25600
:100:1 Layer2-info: encaps:VPLS, control flags:, mtu: 0, site preference: 25600
If the PE routers are not receiving VPLS signaling routes, verify if any of the routes are hidden on the receiving PE. There are various reasons for routes to be hidden, the common being: The received routes have a protocol next-hop value, which is not reachable. There is an import policy on the local PE rejecting the received routes. Verify these by using show route table R_I.l2vpn.0 hidden extensive . In the example output below that is taken on PE3, there was an import policy, which did not pass this route, and hence the route was hidden. PE3# run show route table vpls.l2vpn.0 hidden extensive vpls.l2vpn.0: 4 destinations, 4 routes (2 active, 0 holddown, 2 hidden) 2.2.2.2:5:10:9/96 (1 entry, 0 announced) BGP /-101 Route Distinguisher: 2.2.2.2:5 Next hop type: Indirect Address: 0x2a248f8 Next-hop reference count: 4 Source: 2.2.2.2 Protocol next hop: 2.2.2.2 Indirect next hop: 2 no-forward State: <Secondary Hidden Int Ext> Local AS: 100 Peer AS: 100 Age: 10 Metric2: 1 Task: BGP_100.2.2.2.2+179 AS path: I Communities: target:100:1 Layer2-info: encaps:VPLS, control flags:, mtu: 0, site preference: 25600 Import <<<<<< import policy didn't pass on this route and hence hidden Label-base: 800000, range: 8 Localpref: 100 Router ID: 2.2.2.2 Primary Routing Table bgp.l2vpn.0 Indirect next hops: 1 Protocol next hop: 2.2.2.2 Metric: 1 Indirect next hop: 2 no-forward Indirect path forwarding next hops: 1 Next hop type: Router Next hop: 20.20.20.1 via ge-1/0/1.0 weight 0x1 2.2.2.2/32 Originating RIB: inet.3 Metric: 1 Node path count: 1 Forwarding nexthops: 1 Nexthop: 20.20.20.1 via ge-1/0/1.0
If the PE routers are not receiving VPLS signaling routes, verify if any of the routes are hidden on the receiving PE. There are various reasons for routes to be hidden, the common being:
The received routes have a protocol next-hop value, which is not reachable.
There is an import policy on the local PE rejecting the received routes.
Verify these by using show route table R_I.l2vpn.0 hidden extensive .
show route table R_I.l2vpn.0 hidden extensive
In the example output below that is taken on PE3, there was an import policy, which did not pass this route, and hence the route was hidden.
PE3# run show route table vpls.l2vpn.0 hidden extensive vpls.l2vpn.0: 4 destinations, 4 routes (2 active, 0 holddown, 2 hidden) 2.2.2.2:5:10:9/96 (1 entry, 0 announced) BGP /-101 Route Distinguisher: 2.2.2.2:5 Next hop type: Indirect Address: 0x2a248f8 Next-hop reference count: 4 Source: 2.2.2.2 Protocol next hop: 2.2.2.2 Indirect next hop: 2 no-forward State: <Secondary Hidden Int Ext> Local AS: 100 Peer AS: 100 Age: 10 Metric2: 1 Task: BGP_100.2.2.2.2+179 AS path: I Communities: target:100:1 Layer2-info: encaps:VPLS, control flags:, mtu: 0, site preference: 25600 Import <<<<<< import policy didn't pass on this route and hence hidden Label-base: 800000, range: 8 Localpref: 100 Router ID: 2.2.2.2 Primary Routing Table bgp.l2vpn.0 Indirect next hops: 1 Protocol next hop: 2.2.2.2 Metric: 1 Indirect next hop: 2 no-forward Indirect path forwarding next hops: 1 Next hop type: Router Next hop: 20.20.20.1 via ge-1/0/1.0 weight 0x1 2.2.2.2/32 Originating RIB: inet.3 Metric: 1 Node path count: 1 Forwarding nexthops: 1 Nexthop: 20.20.20.1 via ge-1/0/1.0
Is the VPLS connection listed after verifying that the interested PE routers are receiving VPLS route information from every other PE router? Yes - The connection is listed now . If the connection status ( St ) is Up , and there is an issue with passing traffic, then continue to KB24986 - Resolution Guide - MX - VPLS Troubleshooting (Forwarding Plane) - VPLS connection is up but not passing data [juniper.net] If the connection status ( St ) is not Up, then continue to KB25097 - Troubleshoot VPLS connection status flags when VPLS connection is down [juniper.net] No - Collect the logs/information detailed in KB22637 - [M, MX, T Routers] Data Collection Checklist [juniper.net] under the "VPLS" section, and open a case with your technical support representative .
Is the VPLS connection listed after verifying that the interested PE routers are receiving VPLS route information from every other PE router?
Yes - The connection is listed now .
If the connection status ( St ) is Up , and there is an issue with passing traffic, then continue to KB24986 - Resolution Guide - MX - VPLS Troubleshooting (Forwarding Plane) - VPLS connection is up but not passing data [juniper.net]
If the connection status ( St ) is not Up, then continue to KB25097 - Troubleshoot VPLS connection status flags when VPLS connection is down [juniper.net]
No - Collect the logs/information detailed in KB22637 - [M, MX, T Routers] Data Collection Checklist [juniper.net] under the "VPLS" section, and open a case with your technical support representative .
2022-03-14: Links updated and article checked for accuracy