Description

Troubleshooting tips on VPLS connection status flags, when the VPLS connection does not report Status Up (i.e. it's down).

This article is called from KB25025 - Resolution Guide - MX - VPLS Troubleshooting (Control Plane) - Connection not listed or down [juniper.net] .

Symptoms

When checking the status of a remote VPLS connection with the command ' show vpls connection extensive ', the status is not Up.  What do the various flags mean? How do you troubleshoot it?

lab@siteAA-re0> 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 availble
BK -- Backup connection          ST -- Standby connection
PF -- Profile parse failure      PB -- Profile busy
RS -- remote site standby        SN -- Static Neighbor

Legend for interface status 
Up -- operational           
Dn -- down

Instance: vlan-11

rmt   LN   
  BGP-VPLS State
  Local site: vpls-11 
    connection-site           Type  St     Time last up          # Up trans
    1                         rmt   LD   
    2                         rmt   LD   
    3                         rmt   LD  <--- Status is not 'Up'
 

If the VPLS connection is not listed, then refer to KB25025 - Resolution Guide - MX - VPLS Troubleshooting (Control Plane) - Connection not listed or down [juniper.net] .

Solution

Click on one of the Status (St) values below to jump to the troubleshooting information for that status.

For other status values, refer to: http://www.juniper.net/techpubs/en_US/junos/topics/reference/command-summary/show-vpls-connections.html .

 

NP   (NP -- interface hardware not present) 

This is one of the most common states; it indicates that interface hardware is not present for the proper functioning of the VPLS service. The common reason for this state is an issue with the tunnel interface on the core facing side.
 
The type of tunnel interface (either vt or lsi ) used depends on whether the no-tunnel-services knob is configured.  For information on tunnel-services and no-tunnel-services, refer to the following:         
tunnel-services:
Tunnel interface is necessary in VPLS to bind and de-encapsulate traffic from remote sites on the core facing side of the local PE router. By default, the Junos OS automatically selects one of the virtual tunnel (VT) interfaces available to the router. The Junos OS cycles through the currently available VT interfaces, regularly updating the list of available VT interfaces as new remote sites are discovered and new connections are brought up. For that to happen on MX router at least one fpc should have tunnel-services enabled by using tunnel-services statement under the [edit chassis fpc slot-number pic number] hierarchy.

For more information go to http://www.juniper.net/techpubs/en_US/junos12.1/topics/reference/configuration-statement/tunnel-services-edit-chassis.html .
 
CAUTION: VT interfaces created using MS-DPC are not capable to provide VPLS tunnel (vt) functionality. So only use VT interfaces created on the DPC/MPC to tunnel VPLS .
no-tunnel-services:
Alternatively if you do not want to use up one interface on you MX fpc card only for tunnel services, you can make use of lsi interface (which can perform the same functionality as vt) which is enabled by using no-tunnel-services under the [edit routing-instances routing-instance-name protocols vpls] hierarchy. 

To correct the NP status:

  • Verify if tunnel service interface (either vt or lsi ) on the core facing side is present and is up .  Run the command ‘ show interfaces terse | match vpls | match vt ’ or ‘ show interfaces terse | match vpls | match lsi ’
   Working Examples:       
           Example output when tunnel Services is used:
           lab# run show interfaces terse | match vpls 
           lc-0/0/0.32769             up    up   vpls    
            vt-0/0/10.1051136          up    up   vpls <<<<<< VT Interface for Core facing interface
           ge-1/2/5.0                 up    up   vpls      
          
           Example output when no-tunnel-services knob is used:   
           lab# run show interfaces terse | match vpls 
           lc-0/0/0.32769          up    up   vpls    
           ge-1/2/5.0              up    up   vpls      
            lsi.1048576             up    up   vpls <<<<< lsi interface for Core facing interface
  • Correct tunnel service interface that are not up.  

 

OR  (OR -- out of range)             

This flag indicates that the label associated with the Virtual Circuit (pseudowire) is out of range.
 
If any one side of this pseudowire has a site ID which falls out of range of the site config, the status will be OR. 
 
For example, the following configuration shows that site-range is configured as 10, but one of the configured site-id’s for CE3 is 20, which is numerically more than the site-range (10) and falls out of range; hence the flag is OR. Also refer the below link which explains the same: http://www.juniper.net/techpubs/en_US/junos12.1/topics/usage-guidelines/vpns-configuring-vpls-routing-instances.html .
instance-type vpls;
vlan-id none;
interface ge-5/0/7.13;
route-distinguisher 10.1.1.1:1000;
vrf-target target:100:1000;
protocols {
    vpls {
        site-range 10;   <<<<<<<<<
        no-tunnel-services;
        site CE2{
            site-identifier 2;            
            multi-homing;            
            site-preference backup;            
            mesh-group ldp-2;
        }
        site CE3{
            site-identifier 20;   <<<<<<<<<<
             interface ge-5/0/7.13;
        }

To correct the OR status:

 

OL  (OL -- no outgoing label)

This flag indicates that no advertisement has been received for this Virtual Circuit from the neighbor. There is no outgoing label available for use by this Virtual Circuit.
 
If there any issues with label-switched-paths going out from this router to the egress PE then this flag is reported.

To correct the OL status:

  • Make sure your LSPs are up and running, and confirm that outgoing labels are available for the egress PE from this PE.
  • Make sure that core interface are up and have family mpls configure.
  • Check mpls.0 route table and RSVP/LDP session.
  • Check advertised label blocks using ' show vpls connections ' and ' show route advertising-protocol bgp <PE_neighbor> table <routing_instance> extensive '. In rare cases, if the allocated labels are exhausted then the connection may end up in the OL state.
  • Check if the next-hop is valid in the BGP route received using  'show route receive-protocol bgp <PE_neighbor> table <routing_instance> extensive'. If the next-hop is not valid, (e.g. RR modifying the next-hop via NHS policy), it can result in the VPLS connections to be down down due to OL status. 

 

LD   (LD -- local site signaled down )  

This flag indicates that all of the CE facing interfaces to the local site are down. Therefore, the connection to the local site is signaled as down to the other PE routers. No pseudowires can be established.  

On the CE facing side, when the physical and logical interface is configured with the correct encapsulation type for VPLS, if the interface is operationally up, then the local PE router can properly signal the remote PE routers that local site is UP. For more on configuring the CE facing side for VPLS, refer to  http://www.juniper.net/techpubs/en_US/junos12.1/topics/usage-guidelines/vpns-configuring-interfaces-for-vpls-routing.html .
 

If you have LDP VPLS connections, they should be brought down if all CE interfaces go down on the local PE. Along with this there are some other conditions that need to be considered. Basically if any one of the following conditions hold true, the pseudowire is brought UP; otherwise, it is brought down on the local PE.

  • IRB interface is configured and conn type is IRB
  • At least one of the CE facing interfaces is UP
  • At least one of the user defined mesh groups is UP

To correct the LD status, determine why the local CE facing interface is down:

 

LM -- local site ID not minimum designated ;  RM -- remote site ID not minimum designated

The LM or RM state is typically found in multi-homing scenarios:

RM — The remote site identifier is not the minimum designated, i.e. it is not the lowest. There is another remote site connected to the same PE router which has a lower site identifier. The PE router cannot establish a pseduowire to this remote site and the associated remote site identifier cannot be used to distribute VPLS label blocks. However, this is not an error state. Traffic can continue to be forwarded to the PE router interface connected to this remote site when the remote site is in this state.

To correct this issue:

  • Confirm that only one site is configured for a routing instance.  If multiple sites are added to the routing-instance, enable the multi-homing knob.

 

RD  (RD -- remote site signaled down)

This flag is set on the local PE router if all the interfaces to the remote neighbor are down. Therefore, the remote site has been signaled as down to the other PE routers. No pseudowires can be established.

This is similar to LD. On the local PE, the LDP VPLS connection should be brought down if all CE interfaces go down on the remote PE.

If any one of the following conditions are true on the remote PE router's CE facing link, the psuedowire is brought UP; otherwise it is brought down as RD on the local PE.

  • IRB interface is configured and conn type is IRB
  • At least one of the remote CE facing interface is UP
  • At least one of the user defined mesh groups is UP

Modification History

2020-06-12: Article reviewed for accuracy; no changes required
2020-08-21: Added 2nd bullet item under OL regarding core interface and family mpls

Related Information