Support Support Downloads Knowledge Base Case Manager My Juniper Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

[M/MX] VPLS connection is 'Up' when remote site ID is greater than the local site-range

0

0

Article ID: KB30828 KB Last Updated: 06 May 2016Version: 1.0
Summary:

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

Cause:

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.

Solution:

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.

Related Links

Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search