Configuring Hierarchical Vpls
Configuring Hierarchical Vpls
Published: 2014-01-10
Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right to change, modify,
transfer, or otherwise revise this publication without notice.
The information in this document is current as of the date on the title page.
Juniper Networks hardware and software products are Year 2000 compliant. Junos OS has no known time-related limitations through the
year 2038. However, the NTP application is known to have some difficulty in the year 2036.
The Juniper Networks product that is the subject of this technical documentation consists of (or is intended for use with) Juniper Networks
software. Use of such software is subject to the terms and conditions of the End User License Agreement (“EULA”) posted at
http://www.juniper.net/support/eula.html. By downloading, installing or using such software, you agree to the terms and conditions of
that EULA.
VPLS is one of the key MPLS-based services that have developed in the industry. The
purpose of VPLS is to provide a private multipoint LAN-type Ethernet connectivity service.
For those more familiar with technologies like Asynchronous Transfer Mode, VPLS is
similar to a LAN emulation service for MPLS.
VPLS is especially useful in the service provider space as the way to deliver Layer 2
multipoint transparent services over an Ethernet infrastructure using MPLS. The key
differentiating factor of VPLS is MPLS. There are different ways for a service provider to
deliver services over an Ethernet infrastructure, but not all of them fit into the requirements
that a service provider has in terms of scalability, reliability, service flexibility, and
operational complexity. MPLS is the catalyst that can turn an Ethernet infrastructure into
a carrier class network, making it suitable for a service provider. This is as opposed to a
VLAN-based or Q-in-Q operation that does not provide what is required in the carrier
environment.
VPLS, is the main technology in use in the Metro Ethernet space, with two standardized
implementation options:
• RFC4761 – Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling
• RFC4762 – Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP)
Signaling
BGP-based VPLS and LDP-based VPLS are nearly identical in the operation of the
forwarding plane, with the main differences in the control plane, particularly in the
protocols used to signal and establish the pseudowires, BGP or LDP.
LDP-based VPLS requires a full mesh of tunnel LSPs between all the PE routers that
participate in the VPLS service. For each VPLS service, n*(n-1)/2 pseudowires must be
set up between the PE routers. The full mesh requirement creates signaling overhead,
consequently LDP-based VPLS has scaling challenges for large deployments.
• It is labor intensive because you must manually configure targeted LDP sessions.
• The requirement for a full mesh of pseudowires creates significant signaling overhead.
• Multicast, broadcast, and unknown unicast packets must be replicated for each
provisioned pseudowire, which can waste bandwidth in large-scale deployments,
especially for the hub router in a hub-and-spoke topology.
To address the scaling issues of LDP-based VPLS, hierarchical VPLS (H-VPLS) is defined
in RFC 4762.
• The signaling overhead caused by the requirement for a full mesh of pseudowires.
• The possibility of extending the VPLS domain to use simpler, less expensive devices.
Juniper Networks recommends using BGP-based VPLS for better scalability in the control
plane and data plane. However, service providers are often in a situation where they need
Juniper Networks routers to interoperate with other vendors’ routers, which may not
support BGP-based VPLS.
1. Interworking between LDP-based VPLS and BGP-based VPLS on the border routers
using mesh groups.
H-VPLS Implementation
Hierarchical LDP-based VPLS requires a full mesh of tunnel LSPs between all the PE
routers that participate in the VPLS service. For each VPLS service, n*(n-1)/2 pseudowires
must be set up between the PE routers. Although the full mesh requirement creates
signaling overhead, the larger negative impact to large-scale deployment is the packet
replication requirements for each provisioned pseudowire on a PE router. Using hierarchical
connectivity reduces signaling and replication overhead to facilitate large-scale
deployments.
• PE-r (Hub-PE) — A PE router that has routing capabilities but does not have bridging
capabilities. It supports all of the functions of the VPLS architecture. It has VPLS
pseudowires to PE-rs routers and also has pseudowires with other devices called
multi-tenant units (MTUs).
• MTU-s (Spoke-PE) — A switch that has bridging capabilities but does not have routing
capabilities. This represents the access layer of the H-VPLS architecture. The MTU-s
device establishes pseudowires to one or two PE-rs routers through which VPLS traffic
is forwarded.
CPE
MTU-s PE-rs PE-rs MTU-s
MTU-s
g040548
LDP active pseudowire
LDP backup pseudowire
The operation between PE-rs routers uses normal VPLS. Between MTU-s devices and
PE-rs routers, the PE-rs routers treat the pseudowires as access links. Therefore, the split
horizon rule used in normal VPLS is not used.
If traffic is received at a PE-rs router from an MTU-s device, it is forwarded to the other
PE-rs routers and MTU-s devices that are connected to the same PE-rs router. When
traffic is received at a PE-rs router from another PE-rs router, it is forwarded to the MTU-s
devices connected to it through a pseudowire, but not to the other PE-rs routers. In this
case the split horizon rule is used.
The mode of operation used by H-VPLS is intended to make VPLS more scalable.
However, this mode of operation requires PE-rs routers to maintain media access control
(MAC) tables and to perform the VPLS operations of learning and flooding. In normal
VPLS, these routers are performing the role of provider (P) routers and have no VPLS
state. In H-VPLS operation, a PE-rs router performs the VPLS operations of learning and
flooding for all of the MTU-s devices to which it is connected. H-VPLS operation can lead
to data plane scaling problems, especially in terms of the number and size of the MAC
tables.
In summary, H-VPLS creates a control plane hierarchy, in the form of MTU-s devices and
PE-rs routers, at the expense of forcing hierarchy in the data plane as well. Therefore, in
the process of solving one scalability problem, H-VPLS introduces a new data plane
scalability problem, and it does not provide solutions for this new problem.
It is important to note that the ability to extend the VPLS domain to less expensive and
simpler devices by establishing pseudowires into a centralized or semi-centralized PE-rs
Junos OS introduces the concept of a mesh group. A mesh group is used to connect
multiple partial mesh domains into a single mesh group. Using a mesh group augments
the forwarding plane operations to permit forwarding across mesh groups. A pseudowire
mesh group is defined as a group of all pseudowires, that are fully meshed in the data
plane. By default PE routers within the same mesh group do not communicate through
the PE-r router .
The following are the H-VPLS definitions of flooding, learning, and learned unicast MAC
forwarding:
• Learning — Source MAC address learning remains unchanged from normal VPLS.
• Learned unicast MAC forwarding — Any traffic received with a destination unicast MAC
address learned on pseudowireX1 and belonging to mesh group X is forwarded only if
the packet is received over a pseudowire that is not part of mesh group X.
To enable H-VPLS, configure an LDP Layer 2 circuit in a VPLS instance using mesh groups.
The Layer 2 circuit virtual circuit ID must match the VPLS ID on the hub PE router’s VPLS
instance.
1. Configure a mesh group for each Layer 2 circuit pseudowire terminating at a VPLS
routing instance.
• The ethernet-ccc encapsulation is used in one mesh group for each Layer 2 circuit
configuration.
• You can use different Layer 2 circuit and VPLS ID pairs for each spoke PE router
mesh group.
• You can terminate Layer 2 circuits into BGP-based VPLS or LDP-based VPLS on
the hub PE router.
• BGP-based VPLS is used in the configuration that uses one mesh group for each
Layer 2 circuit.
• By default, local switching for mesh groups is not enabled. However, the
local-switching statement is useful if you are:
• Configuring the routers with the same virtual circuit ID and VPLS ID pairs in a mesh
group
• LDP-based VPLS is used in the configuration that terminates all the Layer 2 circuit
pseudowires into a single mesh group.
Related • Example: Configuring BGP-Based H-VPLS Using Different Mesh Groups for Each Spoke
Documentation Router on page 5
Example: Configuring BGP-Based H-VPLS Using Different Mesh Groups for Each Spoke
Router
This example shows how to configure the hierarchical virtual private LAN service (H-VPLS)
using different mesh groups to provide H-VPLS functionality and provides steps for
verifying the configuration. This is one type of H-VPLS configuration possible in the Juniper
Networks implementation. For information about the alternate type of configuration see
“Example: Configuring LDP-Based H-VPLS Using a Single Mesh Group to Terminate the
Layer 2 Circuits” on page 28.
Using mesh groups improves LDP-based VPLS control plane scalability and avoids the
requirement for a full mesh of LDP sessions. This example uses BGP-based VPLS.
• Requirements on page 6
• Overview and Topology on page 6
• Configuration on page 8
Requirements
This example uses the following hardware components:
• Four MX Series 3D Universal Edge Routers for Router PE1, Router PE2, Router PE3, and
Router PE4 runnung Junos OS Release 9.4 or later
• Two EX Series Ethernet Switches for Device CE1 and Device CE2
NOTE: This configuration example has been tested using the software release
listed and is assumed to work on all later releases.
J Series
ge-2/0/9
ge-2/0/5
ge-2/0/8
8
EX Series /0/
-2
ge-2/0/9
ge-2/0/9
-2
/0
ge
/8
ge-2/0/10
ge-2/0/8
8
/0/
ge-2/1/5
ge
-2
-2
CE2 ge
/0
/9
ge-2/0/9
MX Series MX Series PE4
ge-2/0/10
ge-2/0/6
EX Series ge-2/1/7
PE2
ge-2/1/6
g0153183
M Series
CE4
• Router PE3 and Router PE4 are configured as PE-r routers, each using an LDP-based
VPLS routing instance.
• The LDP and OSPF protocols are configured on all of the MTU devices and PE-r routers.
• BGP is configured on the PE-r routers. Optionally, you can configure route reflection.
This is useful for scaling internal BGP (IBGP). The BGP configuration includes the
signaling statement at the [edit protocols bgp group group-name family l2vpn] hierarchy
level to support Layer 2 VPN signaling using BGP.
EX Series
CE2
MX Series MX Series
M Series
EX Series
PE2 PE4
MTU2 Primary-PE-r
2.2.2.2 4.4.4.4
g0153184
Primary LDP Pseudowires from MTU to PE
Backup LDP Pseudowires from MTU to PE
In Figure 3 on page 7:
• The MTU devices (Router PE1 and Router PE2) have Layer 2 circuit connections to the
PE-r routers (Router PE3 and Router PE4). For redundancy, a backup neighbor is
configured for the Layer 2 circuit connections to the PE-r routers.
• The l2circuit statement in the [edit protocols] hierarchy is included on the MTU devices.
• In the VPLS routing instance on the PE-r routers, mesh groups are created to terminate
the Layer 2 circuit pseudowires that originate at the MTU devices.
• Each PE-r router’s mesh groups configuration includes VPLS ID values that match the
virtual circuit IDs used on the MTU devices.
Configuration
To configure H-VPLS with different mesh groups for each spoke PE-r router using
BGP-based VPLS, perform the following tasks:
Step-by-Step 1. On Router PE1, configure the Gigabit Ethernet interface connected to Router CE1.
Procedure Include the encapsulation statement and specify the ethernet-ccc option. Also
configure the logical interface by including the family statement and specifying the
ccc option.
[edit interfaces]
ge-2/0/5 {
encapsulation ethernet-ccc;
unit 0 {
family ccc;
}
}
2. On Router PE1, configure the Layer 2 circuit by including the neighbor statement and
specifying the IP address of Router PE3 as the neighbor. Configure the Gigabit
Ethernet logical interface by including the virtual-circuit-id statement and specifying
100 as the ID. Also configure a backup neighbor for the Layer 2 circuit by including
the backup-neighbor statement, specifying the loopback interface IP address of
Router PE4 as the backup neighbor, and including the standby statement.
[edit protocols]
l2circuit {
neighbor 3.3.3.3 {
interface ge-2/0/5.0 {
virtual-circuit-id 100;
backup-neighbor 4.4.4.4 { # Backup H-VPLS PE router
standby;
}
}
}
3. On Router PE2, configure the Gigabit Ethernet interface connected to Router CE2.
Include the encapsulation statement and specify the ethernet-ccc option. Also
configure the logical interface by including the family statement and specifying the
ccc option.
[edit interfaces]
ge-2/0/6 {
encapsulation ethernet-ccc;
unit 0 {
family ccc;
}
}
[edit protocols]
l2circuit {
neighbor 3.3.3.3 {
interface ge-1/0/2.0 {
virtual-circuit-id 200;
encapsulation-type ethernet;
backup-neighbor 4.4.4.4 {
standby;
}
}
}
}
Step-by-Step 1. On Router PE3 (the primary hub), configure the Gigabit Ethernet interface connected
Procedure to Router CE3. Include the encapsulation statement and specify the ethernet-vpls
option. Also configure the logical interface by including the family vpls statement.
[edit interfaces]
ge-2/0/0 {
encapsulation ethernet-vpls;
unit 0 {
family vpls;
}
}
lo0 {
unit 0 {
family inet {
address 3.3.3.3/32;
}
}
}
2. On Router PE4 (the backup hub), configure the Gigabit Ethernet interface connected
to Router CE4. Include the encapsulation statement and specify the ethernet-vpls
option. Also configure the logical interface by including the family vpls statement.
[edit interfaces]
ge-2/1/7 {
encapsulation ethernet-vpls;
unit 0 {
description to_CE4;
family vpls;
}
}
lo0 {
unit 0 {
family inet {
address 4.4.4.4/32;
}
}
}
3. On PE-r Router PE3, configure the BGP-based VPLS routing instance by including
the instance-type statement at the [edit routing-instances H-VPLS] hierarchy level
and specifying the vpls option. Include the interface statement and specify the
Gigabit Ethernet interface connected to Router CE3. Configure a route distinguisher
to ensure that the route advertisement is unique by including the route-distinguisher
statement and specifying 3.3.3.3:33 as the value. Also configure the VPN routing
and forwarding (VRF) route target to be included in the route advertisements to
the other routers participating in the VPLS. To configure the VRF route target, include
the vrf-target statement and specify target:64510:2 as the value. Optionally, include
the no-tunnel-services statement to enable the use of LSI interfaces, which is useful
if the device does not have tunnel services. The no-tunnel-services statement is
omitted in this example. Optionally, you can include the site-range statement to
specify an upper limit on the maximum site identifier that can be accepted to allow
a pseudowire to be brought up. The site-range statement is omitted in this example.
We recommend using the default of 65,534.
Configure the VPLS protocol and the mesh groups for each MTU PE device.
To configure the VPLS protocol, include the vpls statement at the [edit
routing-instances H-VPLS protocols] hierarchy level. Include the site statement and
specify a name for the site. Include the interface statement and specify the Gigabit
Ethernet interface connected to Device CE3.
Configuring mesh groups under the VPLS instance terminates the Layer 2 circuit
into the VPLS instance. To configure each mesh group, include the mesh-group
statement and specify the mesh group name. In this example, the mesh group name
is the name of the MTU device associated with each mesh group. Include the vpls-id
statement and specify the ID that matches the virtual circuit ID configured in
“Configuring the Spoke MTU PE Routers” on page 8. Also include the neighbor
statement and specify the IP address of the spoke PE router associated with each
mesh group. Optionally, include the local-switching statement if you are not using
a full mesh of VPLS connections. The local-switching statement is useful if you are
configuring a single mesh group and terminating multiple Layer 2 circuit pseudowires
into it. The local-switching statement is omitted in this example.
routing-instances {
H-VPLS {
instance-type vpls;
interface ge-2/1/3.0;
route-distinguisher 3.3.3.3:33;
vrf-target target:64510:2;
protocols {
vpls {
site pe3 {
site-identifier 3;
4. On PE-r Router PE4, configure a routing instance like the one on Router PE3.
routing-instances {
H-VPLS {
instance-type vpls;
interface ge-2/1/7.0;
route-distinguisher 4.4.4.4:44;
vrf-target target:64510:2;
protocols {
vpls {
site pe4 {
site-identifier 4;
interface ge-2/1/7.0;
}
mesh-group pe1 {
vpls-id 100;
neighbor 1.1.1.1;
}
mesh-group pe2 {
vpls-id 200;
neighbor 2.2.2.2;
}
}
}
}
}
Step-by-Step This section describes the operational commands that you can use to validate that the
Procedure H-VPLS is working as expected.
The output also shows the assigned label, virtual circuit ID, and the ETHERNET
encapsulation type.
2. On Router PE1 and Router PE2, use the show ldp neighbor command to verify that
the targeted LDP sessions have been created between the loopback interface to
the primary and backup H-VPLS hub neighbors.
3. On Router PE3 and Router PE4, use the show vpls connections command to verify
that the VPLS connection status is Up for both the LDP-based VPLS and the
BGP-based VPLS Layer 2 circuits that are terminated.
Instance: H-VPLS
BGP-VPLS State
Local site: pe3 (3)
connection-site Type St Time last up # Up trans
Instance: H-VPLS
BGP-VPLS State
Local site: pe4 (4)
connection-site Type St Time last up # Up trans
4. On Router PE3 and Router PE4, use the show vpls flood command to verify that the
H-VPLS PE router created a flood group for each spoke PE site.
5. On Router PE3 and Router PE4, use the show vpls mac-table command to verify
that MAC addresses of the CE devices have been learned.
MAC flags (S -static MAC, D -dynamic MAC, L -locally learned, C -Control MAC
3.3.3.3:NoCtrlWord:5:100:Local/96
*[L2CKT/7] 00:12:16, metric2 1
> to 10.10.1.2 via ge-2/0/10.0
3.3.3.3:NoCtrlWord:5:100:Remote/96
*[LDP/9] 00:12:16
Discard
4.4.4.4:NoCtrlWord:5:100:Local/96
*[L2CKT/7] 00:12:10, metric2 1
> to 10.10.9.2 via ge-2/0/8.0
4.4.4.4:NoCtrlWord:5:100:Remote/96
*[LDP/9] 00:12:15
Discard
3.3.3.3:NoCtrlWord:5:200:Local/96
*[L2CKT/7] 00:13:13, metric2 1
> to 10.10.4.1 via ge-2/0/8.0
3.3.3.3:NoCtrlWord:5:200:Remote/96
*[LDP/9] 00:13:13
Discard
4.4.4.4:NoCtrlWord:5:200:Local/96
*[L2CKT/7] 00:13:13, metric2 1
> to 10.10.5.2 via ge-2/0/9.0
4.4.4.4:NoCtrlWord:5:200:Remote/96
*[LDP/9] 00:13:13
Discard
3.3.3.3:33:3:1/96
*[L2VPN/170/-101] 03:19:26, metric2 1
Indirect
4.4.4.4:44:4:1/96
*[BGP/170] 03:15:45, localpref 100, from 4.4.4.4
AS path: I, validation-state: unverified
> to 10.10.6.2 via ge-2/0/9.0
3.3.3.3:33:3:1/96
*[BGP/170] 03:21:17, localpref 100, from 3.3.3.3
AS path: I, validation-state: unverified
> to 10.10.6.1 via ge-2/0/9.0
4.4.4.4:44:4:1/96
*[L2VPN/170/-101] 03:17:47, metric2 1
Indirect
area 0.0.0.0 {
interface lo0.0 {
passive;
}
interface ge-2/0/8.0;
interface ge-2/0/9.0;
interface ge-2/0/10.0;
}
}
ldp {
interface ge-2/0/8.0;
interface ge-2/0/9.0;
interface ge-2/0/10.0;
interface lo0.0;
}
l2circuit {
neighbor 3.3.3.3 {
interface ge-2/0/5.0 {
virtual-circuit-id 100;
backup-neighbor 4.4.4.4 {
standby;
}
}
}
}
}
description to_PE2;
family inet {
address 10.10.4.1/30;
}
family mpls;
}
}
ge-2/0/9 {
unit 0 {
description to_PE4;
family inet {
address 10.10.6.1/30;
}
family mpls;
}
}
ge-2/0/10 {
unit 0 {
description to_PE1;
family inet {
address 10.10.1.2/30;
}
family mpls;
}
}
ge-2/1/3 {
encapsulation ethernet-vpls;
unit 0 {
description to_CE3;
family vpls;
}
}
lo0 {
unit 0{
family inet {
address 3.3.3.3/32;
}
}
}
}
protocols {
mpls {
interface ge-2/0/8.0;
interface ge-2/0/9.0;
interface ge-2/0/10.0;
}
bgp {
group internal-peers {
type internal;
local-address 3.3.3.3;
family l2vpn {
signaling;
}
neighbor 4.4.4.4;
}
}
}
}
ge-2/0/9 {
unit 0 {
description to_PE1;
family inet {
address 10.10.9.2/30;
}
family mpls;
}
}
ge-2/0/10 {
unit 0 {
description to_PE2;
family inet {
address 10.10.5.2/30;
}
family mpls;
}
}
ge-2/1/7 {
encapsulation ethernet-vpls;
unit 0 {
description to_CE4;
family vpls;
}
}
lo0 {
unit 0 {
family inet {
address 4.4.4.4/32;
}
}
}
}
protocols {
mpls {
interface ge-2/0/8.0;
interface ge-2/0/9.0;
interface ge-2/0/10.0;
}
bgp {
group internal-peers {
type internal;
local-address 4.4.4.4;
family l2vpn {
signaling;
}
neighbor 3.3.3.3;
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface lo0.0 {
passive;
}
}
}
}
protocols {
ospf {
area 0.0.0.0 {
interface lo0.0 {
passive;
}
interface ge-2/0/8.0;
}
}
}
Related • Example: Configuring LDP-Based H-VPLS Using a Single Mesh Group to Terminate the
Documentation Layer 2 Circuits
This example shows how to configure a single mesh group to terminate the Layer 2
circuits into an LDP-based VPLS. This is one type of hierarchical virtual private LAN service
(H-VPLS) configuration possible in the Juniper Networks implementation. For information
about the alternate type of configuration see “Example: Configuring BGP-Based H-VPLS
Using Different Mesh Groups for Each Spoke Router” on page 5.
This example provides step-by-step configuration instructions and also provides steps
for verifying and troubleshooting the configuration.
• Requirements on page 28
• Overview and Topology on page 28
• Configuration on page 29
Requirements
This example uses the following hardware components:
• Four MX Series 3D Universal Edge Routers for Routers PE1, PE2, PE3, and PE4 runnung
Junos OS Release 9.4 or later
• Two M Series Multiservice Edge Routers for Routers CE4 and PE5
• Two T Series Core Routers for Routers P1 and the route reflector
NOTE: This configuration example has been tested using the software release
listed and is assumed to work on all later releases.
ge-3/0/0 T Series
ge-0/2/0
xe-0/0/0
ge-1/0/0
ge-0/1/0
CE1 PE1 ge-1/0/1 ge-0/0/0
xe-0/3/0 PE3
ge-0/1/0
xe-1/3/0
MX Series MX Series T Series ge
ge-1/1/0
-0/
EX Series 1/0
P1 PE4 CE4
xe-0/2/0
xe-0/1/0
xe-0/1/0
ge-1/2/0
MX Series M Series
ge-0/1/2
xe-0/2/0
xe-0/0/0
CE2
xe-0/3/0
MX Series MX Series PE5
ge-1/0/2
EX Series ge-2/0/0
PE2
ge-0/2/0
g040546
M Series
CE5
• Local switching is used to switch traffic between Layer 2 circuit pseudowires from the
different spoke PE routers.
• The spoke PE routers are configured with the same virtual circuit ID and VPLS ID pair
in a mesh group.
Configuration
To configure a single mesh group to terminate the Layer 2 circuits into an LDP-based
VPLS, perform the following tasks:
Step-by-Step Configure a single mesh group to terminate all the Layer 2 circuit pseudowires and enable
Procedure local switching between the pseudowires.
1. On Router PE1, configure the Layer 2 circuit by including the l2circuit statement at
the [edit protocols] hierarchy level. Include the neighbor statement and specify the
IPv4 address of the hub PE router. Also configure the logical interface by including
the interface statement and specify the interface connected to Router CE1.
[edit protocols]
l2circuit {
neighbor 5.5.5.5 {
interface ge-1/0/0.0 {
virtual-circuit-id 100;
backup-neighbor 3.3.3.3 {
standby;
}
}
}
}
2. On Router PE2, configure the Layer 2 circuit by including the l2circuit statement at
the [edit protocols] hierarchy level. Include the neighbor statement and specify the
IPv4 address of the hub PE router. Configure the logical interface by including the
interface statement and specifying the interface connected to Router CE2.
[edit protocols]
l2circuit {
neighbor 5.5.5.5 {
interface ge-1/0/2.0 {
virtual-circuit-id 100;
encapsulation-type ethernet;
backup-neighbor 3.3.3.3 {
standby;
}
}
}
}
3. On Router PE4, configure the Layer 2 circuit by including the l2circuit statement at
the [edit protocols] hierarchy level. Include the neighbor statement and specify the
IPv4 address of the hub PE router. Configure the logical interface by including the
interface statement and specify the interface connected to Router CE4.
[edit protocols]
l2circuit {
neighbor 5.5.5.5 {
interface ge-1/2/0.0 {
virtual-circuit-id 100;
backup-neighbor 3.3.3.3 {
standby;
}
}
}
}
Step-by-Step Configure a single mesh group to terminate all the Layer 2 circuit pseudowires and enable
Procedure local switching between the pseudowires.
1. On Router PE3, configure the Gigabit Ethernet interface connected to Router CE3
by including the encapsulation statement and specifying the ethernet-vpls option.
Also configure the logical interface by including the family statement and specifying
the vpls option.
[edit interfaces]
ge-1/0/1 {
encapsulation ethernet-vpls;
unit 0 {
family vpls;
}
}
2. On Router PE3, configure the logical loopback interface by including the family
statement and specifying the inet option. Include the address statement and specify
the IPv4 address for the interface.
[edit interfaces]
lo0 {
unit 0 {
family inet {
address 3.3.3.3/32;
}
}
}
3. On Router PE3, configure the LDP-based VPLS routing instance by including the
instance-type statement at the [edit routing-instances H-VPLS] hierarchy level and
specifying the vpls option. Include the interface statement and specify the Gigabit
Ethernet interface connected to Router CE3.
Configure the VPLS protocol by including the vpls statement at the [edit
routing-instances H-VPLS protocols] hierarchy level. Include the no-tunnel-services
statement to enable the router to use an LSI interface.
[edit routing-instances]
H-VPLS {
instance-type vpls;
interface ge-1/0/1.0;
protocols {
vpls {
no-tunnel-services;
}
}
}
4. On Router PE3, configure the mesh group by including the mesh-group statement
at the [edit routing-instances H-VPLS protocols vpls] hierarchy level and specifying
L2-Circuits as the name of the group. Include the vpls-id statement and specify 100
as the ID value. Enable local switching by include the local-switching statement to
enable the router to switch traffic between the pseudowires.
For each neighbor in the mesh group, include the neighbor statement and specify
the IPv4 address of the spoke PE router.
Verification
Step-by-Step 1. On Router PE5, use the show ldp neighbor command to verify that LDP sessions
Procedure have been created to each of the spoke PE routers.
2. On Router PE5, use the show vpls connections extensive command to verify that
the mesh group neighbor session is Up, that inbound and outbound labels have
been assigned, that the VPLS ID is correct, and that the virtual tunnel interface is
being used.
Related • Example: Configuring BGP-Based H-VPLS Using Different Mesh Groups for Each Spoke
Documentation Router on page 5