Description

When the VPLS local site-range is less than the remote site-identifier, the VPLS connection will be signaled as 'down' due to 'remote site out of range'. However, VPLS connection from the remote site still appears 'Up'. This article explains the cause and why this behavior is expected.

Symptoms

Topology:

CE1 --- <xe-2/0/1> PE1 --- P1 --- P2 --- PE2 <xe-2/0/2> --- CE2

When PE1's site-range configuration changes from 3 to 2, it causes PE1's VC to go down due to 'remote site out of range'. However, it is not signaled to PE2, which makes the VC in PE2 to stay in 'Up' status.

Normal behavior:

In the following example, PE1's site-range is 2, which is less than PE2's site-identifier.  This causes the VPLS connection to go down due to OR (out of range). 

root@mx480xxx# show routing-instances 
TEST1 {
    instance-type vpls;
    interface xe-2/0/1.0;
    route-distinguisher 1.1.1.1:1;
    vrf-target target:10:60;
    protocols {
        vpls {
            traceoptions {
                file pe1-vpls-trace;
                flag all;
            }
            site-range 2;
            interface xe-2/0/1.0 {
                encapsulation-type ethernet;
            }
            no-tunnel-services;
            site xxx {
                site-identifier 1;
            }
        }
    }
}


root@mx480xxx# show routing-instances 
TEST2 {
    instance-type vpls;
    interface xe-2/0/2.0;
    route-distinguisher 6.6.6.6:1;
    vrf-target target:10:60;
    protocols {
        vpls {
            traceoptions {
                file pe2-vpls-trace;
                flag all;
            }
            site-range 10;
            interface xe-2/0/2.0 {
                encapsulation-type ethernet;
            }
            no-tunnel-services;
            site xxx {
                site-identifier 3;
            }
        }
    }
}

From PE1:

root@mx480xxx# 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
LB -- Local site not best-site   RB -- Remote site not best-site
VM -- VLAN ID mismatch

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

Instance: TEST1
Edge protection: Not-Primary
  Local site: xxx (1)
    connection-site           Type  St     Time last up          # Up trans
    3                         rmt   OR
Up behavior: The following output shows that VPLS connection is Up from PE2, even if the Virtual Circuit is singled to down.

From PE2: 
root@mx480xxx# 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
LB -- Local site not best-site   RB -- Remote site not best-site
VM -- VLAN ID mismatch

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

Instance: TEST2
Edge protection: Not-Primary
  Local site: xxx (3)
    connection-site           Type  St     Time last up          # Up trans
    1                         rmt   Up     Mar 25 19:28:38 2016           1
      Remote PE: 2.2.2.2, Negotiated control-word: No
      Incoming label: 262145, Outgoing label: 262147
      Local interface: lsi.17826048, Status: Up, Encapsulation: VPLS
        Description: Intf - vpls TEST2 local site 3 remote site 1

Solution

As per the VPLS design, it is possible to have one end pseudowire in OR state and the other end in Up state, when the remote site ID do not fall in the locally configured site-range. This functionality is useful in hub-and-spoke VPLS with multihoming.

This behavior is intended according to VPLS design. In a hub-and-spoke VPLS with multihomed sites network, it needs to allow pseudowires to be established between the spoke routers and the hub router. However, it also needs to prevent pseudowires from being established between spoke routers directly. Refer to the VPLS Configuration Guide for more information.

Also, see KB30802 - [MX/PTX/TX] System does not warn of out-of-range situation after commit [juniper.net] .

Related Information