Validating VPLS on the PTX10002-36QDD with Junos Evolved 24.2R2 for Metro Aggregation or Cloud Enterprise use cases.
Introduction
The PTX10002-36QDD is a next-generation cloud-optimized 2U fixed-configuration routing platform powered by Juniper’s Express 5 ASIC. With an industry-leading 28.8 Tbps throughput capacity, it is purpose-built for space- and power-constrained environments, making it ideal for dense, high-performance network deployments.
Despite the growing adoption of EVPN solutions, VPLS remains a widely deployed and trusted technology for delivering services such as enterprise connectivity, mobile backhaul, or wholesale services. VPLS enables multipoint Layer 2 Ethernet connectivity over MPLS networks. The service allows geographically distributed LAN segments to appear as if on the same Ethernet broadcast domain by interconnecting sites with pseudowires. Pseudowires can be signaled using either BGP or LDP, as defined by the IETF standards listed below.
IETF VPLS Standards
- RFC 4761 defines BGP-VPLS, utilizing BGP for both service discovery and the signaling of pseudowires.
- RFC 4762 describes LDP-signaled VPLS, using LDP either FEC128 or FEC129 (Generalized PWid).
- RFC 6074 extends VPLS signaling using FEC129 with BGP-based auto-discovery, enhancing scalability and flexibility.
Historically, the PTX platform has been deployed primarily in core and peering roles. However, with the significant advancements introduced by the latest-generation Express 5 (code name BX) chipset, PTX is increasingly being evaluated for more complex roles across the network. As bandwidth demands grow — especially in Metro Aggregation and Cloud Enterprise environments — the PTX10002-36QDD emerges as a strong candidate for these evolving use cases. For this validation, we selected a representative scale of 4,000 VPLS instances, distributed across three service types: BGP-VPLS, LDP-VPLS, and LDP-VPLS with BGP auto-discovery.
PTX10002-36QDD, running Junos Evolved 24.2R2 as the primary device under test (DUT), serves as the Provider Edge (PE) router. It provides Layer 2 bridged connectivity between Customer Edge (CE) devices across an MPLS core. VPLS PEs may leverage various transport technologies, including MPLS with LDP or RSVP, SR-MPLS, or SRv6. MAC learning in Virtual Private LAN Service (VPLS) occurs in the data plane, like it's done in Ethernet switches.
JUNOS-EVO supports VPLS functionality with the instance type “virtual-switch” on PTX10002-36QDD platform. The logical tunnel interfaces connecting the PE devices are known as “LSI ifl” interfaces. The scope of an LSI IFL is limited to the respective routing instances configured as a virtual switch.
VPLS Packet Walkthrough
Here’s a summary of how a customer Ethernet packet is processed through the VPLS domain.
Ingress PE:
An Ethernet frame arriving at the PE router is associated with a virtual-switch routing instance (VSI) based on a physical/logical port and VLAN ID (IEEE 802.1Q) and undergoes the following MAC operations.
- The source MAC address is learned and creates an entry in the Ethernet switching table, which is associated with the incoming interface.
- The destination MAC address is looked up in the VSI Ethernet switching table, and the following decisions are made:
- For a known MAC address, learned from other associated CE interfaces on the PE device, the packet is forwarded.
- For a known MAC address, learned over the LSI IFL, the Ethernet switching table identifies an associated LSI IFL, which gives a composite NH that will provide a service label & transport label required to forward the packet.
- If the destination MAC address is unknown, the packet is flooded to all destinations over associated LSI IFLs using the service and corresponding transport labels. If local switching is enabled, this packet will be sent to the other associated CE IFLs as well.
Transit LSRs:
Transit (P) routers are Label Switch Routers (LSRs) that switch the packet based on the transport (outer) label of the packet until the packet arrives at the far-end PE Router. LSR P-routers are service agnostic and unaware of the VPLS overlay.
Penultimate Hop Popping (PHP) removes the transport label one hop before the egress PE, and the packet is forwarded to the PE node with only the service label.
Egress PE:
The remaining service label is mapped to the associated VPLS domain LSI IFL. Earlier source lookup populates the local LSI IFL information with the service label, which is mapped to the VSI. A layer 2 lookup is performed, and the packet is forwarded toward the destination CE interface.
Validated KPIs
In this article, we will validate the following goals and Key Performance Indicators (KPIs) to create a reasonable solution scale.
- Successful provisioning and operation of 4,000 VPLS instances.
- MAC scalability validated for 600K learned MAC addresses.
- End-to-end packet forwarding and MAC learning between PE routers.
- Interoperability of PTX10002-36QDD and MX10004 devices acting as PE DUTs with PTX10001-36MR as P-routers.
- Packet forwarding behavior for known and unknown MACs.
- Validation of service label and transport label resolution via LSI IFLs.
| KPIs |
Scale |
| Total VPLS instances |
4,000 |
| BGP-Based VPLS instances |
1,333 |
| LDP-VPLS instances |
1,333 |
| LDP-VPLS instances with BGP-AD |
1,334 |
| Total MACs |
600,000 |
| Number of interfaces |
4,000 |
| Number of VLANS |
4,000 |
Scale KPIs
VPLS Topology
Topology consists of multiple devices in various roles such as Provider Edge routers, Provider routers, and Customer Edge devices.
- PTX10002-36QDD as PE1
- MX10004 as PE2 & PE3
- PTX10001-36MR as P1 & P2
- CEs are emulated using a traffic generator
All the core connections are 100GE links. PE1 & PE2 are connected to CEs using 100GE links whereas PE2 is connected to CE using 10GE link.
Figure 1 - Testbed Topology
PTX10002-36QDD is the Device under test. ISIS Segment Routing is used as the underlay transport. The VPLS services are configured on CE-bound interfaces of PEs. The devices shown as CEn represent the additional CEs emulated by the validation (up to 4,000 in total).
VPLS Configuration
This section outlines the configuration steps required to provision VPLS over an MPLS network. Network reachability can be established with OSPF or IS-IS Interior Gateway Protocols (IGP). For the MPLS transport layer, RSVP-TE, LDP, or SR may be used. In this setup, IS-IS with Segment Routing (ISIS-SR) is configured for MPLS transport.
For signaling VPLS services, Label Distribution Protocol (LDP) is enabled over the loopback (lo0) interfaces to facilitate remote targeted LDP (tLDP). This is essential for LDP-signaled VPLS, where pseudowire signaling occurs between non-directly connected PE routers. The tLDP sessions are established using the Extended Discovery mechanism, as defined by RFC5036, which allows session formation between non-directly connected neighbors.
For BGP-signaled VPLS, the l2vpn-signaling address family is enabled under BGP configuration. This permits the use of BGP-based service signaling and auto-discovery as defined by RFC 4761 and RFC 6074. BGP auto-discovery simplifies the provisioning process by allowing PEs to dynamically learn about remote VPLS instances.
Loopback interfaces are used as logical endpoints for both BGP and LDP signaling and thus for establishing VPLS pseudowire connections. The loopback IPs configured for each PE router include.
- PE1: 10.0.0.1
- PE2: 10.0.0.4
- PE3: 10.0.0.5
These loopbacks are advertised by the ISIS SR to ensure reachability across the MPLS domain.
VPLS provides Ethernet-based multipoint-to-multipoint Layer 2 connectivity over MPLS. In this setup, the three PEs (PE1, PE2, and PE3) are configured with VPLS instances to emulate a LAN-like broadcast domain for customer sites. This enables the seamless extension of Layer 2 services across geographically dispersed locations using MPLS transport.
Protocol Configuration on PTX10002-36QDD
root@PE1> show configuration protocols | display inheritance no-comments
bgp {
group GR-IBGP {
type internal;
local-address 10.0.0.1;
family l2vpn {
auto-discovery-only;
signaling;
}
export PS-BGP-EXPORT;
bfd-liveness-detection {
minimum-interval 100;
multiplier 3;
}
neighbor 10.0.0.4 {
description PE2;
}
neighbor 10.0.0.5 {
description PE3;
}
}
log-updown;
}
isis {
interface et-0/0/4.0 {
level 2 {
post-convergence-lfa {
node-protection cost 16777214;
}
}
point-to-point;
}
interface et-0/0/3.0 {
level 2 {
post-convergence-lfa {
node-protection cost 16777214;
}
}
point-to-point;
}
interface lo0.0 {
passive;
}
source-packet-routing {
node-segment {
ipv4-index 0;
ipv6-index 100;
}
flex-algorithm [ 128 129 ];
strict-asla-based-flex-algorithm;
explicit-null;
traffic-statistics {
statistics-granularity per-interface;
}
}
level 1 disable;
level 2 wide-metrics-only;
spf-options {
microloop-avoidance {
post-convergence-path {
delay 5000;
}
}
}
backup-spf-options {
use-post-convergence-lfa maximum-labels 3;
use-source-packet-routing;
}
traffic-engineering {
advertisement {
application-specific {
all-applications;
}
}
}
export PS-ISIS-EXPORT;
overload timeout 300;
}
ldp {
interface lo0.0;
}
mpls {
label-range {
srgb-label-range 16000 24000;
}
interface et-0/0/3.0;
interface et-0/0/4.0;
}
BGP-VPLS
Configuration required to provision BGP signaled VPLS. The label-block-size is 8 by default, but can be reduced for more efficient resource utilization based on the number of configured sites in the VPLS domain. In this example, since we have three VPLS sites, we can reduce the block allocation to 4.
interfaces {
et-0/0/0 {
flexible-vlan-tagging;
encapsulation flexible-ethernet-services;
unit 1 {
encapsulation vlan-bridge;
vlan-id 1;
}
}
}
routing-instances {
bgp_vpls_1 {
instance-type virtual-switch;
protocols {
vpls {
site PE1 {
site-identifier 1; # must be unique per site
}
service-type single;
site-range 3; # since we have only 3 sites here
label-block-size 4; # 4 is sufficient for 3 VPLS sites
}
}
interface et-0/0/0.1;
route-distinguisher 10.0.0.1:1;
vrf-target target:63535:1;
vlans {
vlan_1 {
interface et-0/0/0.1;
}
}
}
}
LDP-VPLS
Configuration required to provision LDP signaling-based VPLS.
routing-instances {
fec128_vpls_1400 {
instance-type virtual-switch;
protocols {
vpls {
neighbor 10.0.0.4; #PE2 needs to be configured
neighbor 10.0.0.5; #PE3 needs to be configured
service-type single;
encapsulation-type ethernet-vlan;
no-control-word;
vpls-id 1; # vpls-id must be the same for an instance
}
}
description "FEC 128 VPLS LDP";
interface et-0/0/0.1400;
vlans {
vlan1400 {
vlan-id 1400;
interface et-0/0/0.1400;
}
}
}
}
interfaces {
et-0/0/0 {
flexible-vlan-tagging;
encapsulation flexible-ethernet-services;
unit 1400 {
encapsulation vlan-bridge;
vlan-id 1400;
}
}
}
LDP-VPLS With BGP-AD
Configuration required to bring up LDP-based VPLS with BGP auto-discovery. The l2vpn-id configuration construct is used per-VPLS domain for FEC129 LDP-VPLS using BGP auto-discovery.
routing-instances {
fec129_vpls_2740 {
instance-type virtual-switch;
l2vpn-id l2vpn-id:1:100; # BGP auto discovery establishing LDP PW mesh
protocols {
vpls {
service-type single;
no-control-word;
}
}
route-distinguisher 10.0.0.1:10000;
vrf-target target:63555:2740;
vlans {
bd2740 {
vlan-id 2740;
interface et-0/0/0.2740;
}
}
}
}
interfaces {
et-0/0/0 {
flexible-vlan-tagging;
encapsulation flexible-ethernet-services;
unit 2740 {
encapsulation vlan-bridge;
vlan-id 2740;
}
}
}
Traffic Generator Configuration
CE devices emulated behind every PE can be observed here.
Figure 2 - CE devices emulated behind every PE
CE-Bound Interface Schema on each PE
PE devices are connected to the traffic generator using the links below. Each interface is logically split into sub-interfaces using VLANs, and each logical interface is assigned to a VPLS instance.
| PE1 |
PE2 |
PE3 |
Service Type |
VRF |
VLAN Association |
Number of MAC |
Traffic Load |
| et-0/0/0 |
et-1/1/0 |
xe-0/1/2 |
virtual-switch |
1-1333 |
1-1333 |
200004 |
99.90% |
| et-0/0/0 |
et-1/1/0 |
xe-0/1/2 |
virtual-switch |
1400-2732 |
1400-2732 |
199998 |
99.90% |
| et-0/0/0 |
et-1/1/0 |
xe-0/1/2 |
virtual-switch |
2740-4073 |
2740-4073 |
199998 |
99.90% |
VPLS Verifications
This section shows the provisioning steps and operations of VPLS via control plane CLIs, along with traffic forwarding snapshots.
BGP and LDP signalling should be verified as the first step to ensure expected behaviour between PEs. As shown below, PE1 (10.0.0.1) established BGP & LDP sessions with PE2 (10.0.0.4) & PE3 (10.0.0.5) .
Signaling Verification
root@PE1> show bgp summary
Threading mode: BGP I/O
Default eBGP mode: advertise - accept, receive - accept
Groups: 1 Peers: 2 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
bgp.l2vpn.0
5334 5334 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
10.0.0.4 63535 3163 3162 0 541 3:42:41 Establ
bgp.l2vpn.0: 2667/2667/2667/0
bgp_vpls_1.l2vpn.0: 1/1/1/0
bgp_vpls_2.l2vpn.0: 1/1/1/0
bgp_vpls_3.l2vpn.0: 1/1/1/0
.
.
.
bgp_vpls_1331.l2vpn.0: 1/1/1/0
bgp_vpls_1332.l2vpn.0: 1/1/1/0
bgp_vpls_1333.l2vpn.0: 1/1/1/0
.
.
fec129_vpls_2740.l2vpn.0: 1/1/1/0
fec129_vpls_2741.l2vpn.0: 1/1/1/0
fec129_vpls_2742.l2vpn.0: 1/1/1/0
.
.
fec129_vpls_4071.l2vpn.0: 1/1/1/0
fec129_vpls_4072.l2vpn.0: 1/1/1/0
fec129_vpls_4073.l2vpn.0: 1/1/1/0
10.0.0.5 63535 3319 3316 0 2 4:52:38 Establ
bgp.l2vpn.0: 2667/2667/2667/0
bgp_vpls_1.l2vpn.0: 1/1/1/0
bgp_vpls_2.l2vpn.0: 1/1/1/0
bgp_vpls_3.l2vpn.0: 1/1/1/0
.
.
bgp_vpls_1331.l2vpn.0: 1/1/1/0
bgp_vpls_1332.l2vpn.0: 1/1/1/0
bgp_vpls_1333.l2vpn.0: 1/1/1/0
fec129_vpls_2740.l2vpn.0: 1/1/1/0
fec129_vpls_2741.l2vpn.0: 1/1/1/0
fec129_vpls_2742.l2vpn.0: 1/1/1/0
.
.
fec129_vpls_4071.l2vpn.0: 1/1/1/0
fec129_vpls_4072.l2vpn.0: 1/1/1/0
fec129_vpls_4073.l2vpn.0: 1/1/1/0
LDP sessions
root@PE1> show ldp session
Address State Connection Hold time Adv. Mode
10.0.0.4 Operational Open 20 DU
10.0.0.5 Operational Open 27 DU
VPLS Control Plane Verifications
This section displays the successful provisioning of all 3 variants of VPLS via control plane verifications.
BGP-VPLS:
BGP-VPLS connections between the two other sites (PE2 and PE3) are shown as UP for the VPLS instance with LSI service label resolution.
root@PE1> show vpls connections instance bgp_vpls_1
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 HS -- Hot-standby Connection
Legend for interface status
Up -- operational
Dn -- down
Instance: bgp_vpls_1
Edge protection: Not-Primary
Local site: PE1 (1)
connection-site Type St Time last up # Up trans
2 rmt Up Apr 7 10:30:06 2025 1
Remote PE: 10.0.0.4, Negotiated control-word: No
Incoming label: 47670, Outgoing label: 2682
Local interface: lsi.1271307, Status: Up, Encapsulation: VPLS
Description: Intf - vpls bgp_vpls_1 local site 1 remote site 2
Flow Label Transmit: No, Flow Label Receive: No
3 rmt Up Apr 7 09:20:06 2025 1
Remote PE: 10.0.0.5, Negotiated control-word: No
Incoming label: 47671, Outgoing label: 2682
Local interface: lsi.1264640, Status: Up, Encapsulation: VPLS
Description: Intf - vpls bgp_vpls_1 local site 1 remote site 3
Flow Label Transmit: No, Flow Label Receive: No
root@PE1> show route label 47670
mpls.0: 16015 destinations, 16015 routes (16015 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
47670 *[VPLS/7] 1d 01:16:14
> via lsi.1271307 (master), Pop
VPLS routing-instance routing table shows the NLRI of all VPLS sites.
root@PE1> show route table bgp_vpls_1.l2vpn.0
bgp_vpls_1.l2vpn.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.1:1:1:1/96
*[L2VPN/170/-101] 4d 06:48:47, metric2 1
Indirect
10.0.0.4:1:2:1/96
*[BGP/170] 04:21:01, localpref 100, from 10.0.0.4
AS path: I, validation-state: unverified
> to 10.10.0.2 via et-0/0/3.0, Push 16904
to 10.10.0.6 via et-0/0/4.0, Push 16904
10.0.0.5:1:3:1/96
*[BGP/170] 05:30:58, localpref 100, from 10.0.0.5
AS path: I, validation-state: unverified
> to 10.10.0.2 via et-0/0/3.0, Push 16905
to 10.10.0.6 via et-0/0/4.0, Push 16905
LDP-VPLS:
LDP-VPLS connection status shows UP for the configured neighbors, i.e., PE2 and PE3.
root@PE1> show vpls connections instance fec128_vpls_1400
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 HS -- Hot-standby Connection
Legend for interface status
Up -- operational
Dn -- down
Instance: fec128_vpls_1400
VPLS-id: 1
Neighbor Type St Time last up # Up trans
10.0.0.4(vpls-id 1) rmt Up Apr 7 10:30:39 2025 1
Remote PE: 10.0.0.4, Negotiated control-word: No
Incoming label: 2682, Outgoing label: 16
Negotiated PW status TLV: No
Local interface: lsi.1275797, Status: Up, Encapsulation: VLAN
Description: Intf - vpls fec128_vpls_1400 neighbor 10.0.0.4 vpls-id 1
Flow Label Transmit: No, Flow Label Receive: No
10.0.0.5(vpls-id 1) rmt Up Apr 7 09:20:13 2025 1
Remote PE: 10.0.0.5, Negotiated control-word: No
Incoming label: 55876, Outgoing label: 16
Negotiated PW status TLV: No
Local interface: lsi.1267307, Status: Up, Encapsulation: VLAN
Description: Intf - vpls fec128_vpls_1400 neighbor 10.0.0.5 vpls-id 1
Flow Label Transmit: No, Flow Label Receive: No
LDP-VPLS with BGP Auto-Discovery:
In this example, the sites/neighbors are not defined and instead are auto-discovered via BGP discovery mechanisms.
root@PE1> show vpls connections instance fec129_vpls_2740
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 HS -- Hot-standby Connection
Legend for interface status
Up -- operational
Dn -- down
Instance: fec129_vpls_2740
L2vpn-id: 1:100
Local-id: 10.0.0.1
Remote-id Type St Time last up # Up trans
10.0.0.4 rmt Up Apr 7 10:30:36 2025 1
Remote PE: 10.0.0.4, Negotiated control-word: No
Incoming label: 461377, Outgoing label: 509741
Negotiated PW status TLV: No
Local interface: lsi.1273974, Status: Up, Encapsulation: ETHERNET
Description: Intf - vpls fec129_vpls_2740 local-id 10.0.0.1 remote-id 10.0.0.4 neighbor 10.0.0.4
Flow Label Transmit: No, Flow Label Receive: No
10.0.0.5 rmt Up Apr 7 09:20:10 2025 1
Remote PE: 10.0.0.5, Negotiated control-word: No
Incoming label: 458709, Outgoing label: 2831
Negotiated PW status TLV: No
Local interface: lsi.1265973, Status: Up, Encapsulation: ETHERNET
Description: Intf - vpls fec129_vpls_2740 local-id 10.0.0.1 remote-id 10.0.0.5 neighbor 10.0.0.5
Flow Label Transmit: No, Flow Label Receive: No
The route table of LDP-VPLS with BGP-AD routing instance is shown below; here, the AD routes of all VPLS sites can be observed.
root@PE1> show route table fec129_vpls_2740.l2vpn.0
fec129_vpls_2740.l2vpn.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.1:10000:10.0.0.1/96 AD
*[VPLS/170] 1w3d 04:32:09, metric2 1
Indirect
10.0.0.4:10000:10.0.0.4/96 AD
*[BGP/170] 04:46:21, localpref 100, from 10.0.0.4
AS path: I, validation-state: unverified
to 10.10.0.2 via et-0/0/3.0, Push 16904
> to 10.10.0.6 via et-0/0/4.0, Push 16904
10.0.0.5:10000:10.0.0.5/96 AD
*[BGP/170] 05:56:25, localpref 100, from 10.0.0.5
AS path: I, validation-state: unverified
to 10.10.0.2 via et-0/0/3.0, Push 16905
> to 10.10.0.6 via et-0/0/4.0, Push 16905
10.0.0.4:NoCtrlWord:5:1:100:10.0.0.1:10.0.0.4/176
*[VPLS/7] 04:46:21, metric2 20
> to 10.10.0.2 via et-0/0/3.0, Push 16904
to 10.10.0.6 via et-0/0/4.0, Push 16904
10.0.0.4:NoCtrlWord:5:1:100:10.0.0.4:10.0.0.1/176
*[LDP/9] 04:45:57
Discard
10.0.0.5:NoCtrlWord:5:1:100:10.0.0.1:10.0.0.5/176
*[VPLS/7] 05:56:25, metric2 30
> to 10.10.0.2 via et-0/0/3.0, Push 16905
to 10.10.0.6 via et-0/0/4.0, Push 16905
10.0.0.5:NoCtrlWord:5:1:100:10.0.0.5:10.0.0.1/176
*[LDP/9] 05:56:22
Discard
VLANs of VPLS instances:
VLANs are created in Junos EVO by respective VPLS virtual-switch instance configurations. The interesting part is where the respective LSI interface of each site is included in the L2 domain. Refer to the VPLS verification section to match and verify respective LSI interfaces.
root@PE1> show vlans instance bgp_vpls_1
Routing instance VLAN name Tag Interfaces
bgp_vpls_1 vlan_1 NA
et-0/0/0.1*
lsi.1264640*
lsi.1271307*
root@PE1> show vlans instance fec128_vpls_1400
Routing instance VLAN name Tag Interfaces
fec128_vpls_1400 vlan1400 1400
et-0/0/0.1400*
lsi.1267307*
lsi.1275797*
root@PE1> show vlans instance fec129_vpls_2740
Routing instance VLAN name Tag Interfaces
fec129_vpls_2740 bd2740 2740
et-0/0/0.2740*
lsi.1265973*
lsi.1273974*
Data Plane Verification
Traffic is transmitted over a 100GE interface at 99.9%-line rate, accounting for the encapsulation overhead, and is distributed across 4,000 VPLS instances with 600K emulated MAC addresses, which is split across two PFEs. We can observe that the traffic traversing the core interfaces (et-0/0/3 & et-0/0/4) is load-balanced in the output below.
PE1 Seconds: 30 Time: 15:34:43
Interface Link Input packets (pps) Output packets (pps)
dsc Up 0 (0) 0 (0)
esi Up 0 (0) 0 (0)
et-0/0/0 Up 1916180163257 (23488049) 1939574211442 (23488051)
et-0/0/1 Down 0 (0) 0 (0)
et-0/0/2 Down 0 (0) 0 (0)
et-0/0/3 Up 954313491338 (11557058) 960861508232 (11739806)
et-0/0/4 Up 991811908913 (12029189) 961103366194 (11747578)
et-0/0/5 Down 0 (0) 0 (0)
et-0/0/6 Down 0 (0) 0 (0)
et-0/0/7 Down 0 (0) 0 (0)
et-0/0/8 Down 0 (0) 0 (0)
Also, traffic flow details from the traffic generator are shown below. These traffic streams were transmitted at a 99.9% line rate of the 100GE interface from each PE without any traffic loss.
The below traffic generator snapshots show traffic rate, throughput, and loss over VPLS.
Figure 3 - Traffic generator snapshots showing traffic rate, throughput, and loss (Delta) over VPLS.
Validations
System scale over PTX10002-36QDD
This section shows PTX10002-36QDD system scale data of the provisioned VPLS instances, the associated system-level routes, and global MAC scale.
VPLS instance scale:
Since each instance has two sites and the output below is matched for its state, there is an accumulated 8,000 connections for the 4,000 VPLS instances.
root@PE1> show vpls connections | match "rmt Up" | count
Count: 8000 lines
System-level routes:
root@PE1> show route summary
Autonomous system number: 63535
Router ID: 10.0.0.1
Highwater Mark (All time / Time averaged watermark)
RIB unique destination routes: 42733 at 2025-04-03 09:48:29 / 32488
RIB routes : 44106 at 2025-04-06 05:33:29 / 32488
FIB routes : 16031 at 2025-04-03 09:48:31 / 11303
VRF type routing instances : 0 at 2025-03-28 10:44:16
inet.0: 17 destinations, 17 routes (16 active, 0 holddown, 1 hidden)
Direct: 4 routes, 3 active
Local: 2 routes, 2 active
Static: 1 routes, 1 active
IS-IS: 9 routes, 9 active
LDP: 1 routes, 1 active
inet.2: 6 destinations, 6 routes (5 active, 0 holddown, 1 hidden)
Direct: 4 routes, 3 active
Local: 2 routes, 2 active
inet.3: 10 destinations, 10 routes (9 active, 0 holddown, 1 hidden)
Direct: 4 routes, 3 active
Local: 2 routes, 2 active
L-ISIS: 4 routes, 4 active
mgmt_junos.inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
Direct: 1 routes, 1 active
Local: 1 routes, 1 active
Static: 1 routes, 1 active
iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
Direct: 1 routes, 1 active
mpls.0: 16015 destinations, 16015 routes (16015 active, 0 holddown, 0 hidden)
MPLS: 6 routes, 6 active
VPLS: 16000 routes, 16000 active
L-ISIS: 9 routes, 9 active
inet6.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
Direct: 2 routes, 2 active
Static: 1 routes, 1 active
INET6: 1 routes, 1 active
inet6.2: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
Direct: 2 routes, 2 active
inet6.3: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
Direct: 2 routes, 2 active
mgmt_junos.inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
Static: 1 routes, 1 active
bgp.l2vpn.0: 5334 destinations, 5334 routes (5334 active, 0 holddown, 0 hidden)
BGP: 5334 routes, 5334 active
MAC scale Validation:
This validation is done with 600K MACs distributed equally across 4,000 VPLS instances.
root@PE1> show ethernet-switching table summary
Total dynamic and static MAC addresses learned globally : 600000
Configured static MAC addresses learned globally : 0
root@PE1> show ethernet-switching table | grep et-0/0/13 | count
Count: 300000 lines
root@PE1> show ethernet-switching table | grep lsi| count
Count: 300000 lines
Monitor interface traffic:
PE1 Seconds: 12499 Time: 16:56:42
Interface Link Input packets (pps) Output packets (pps)
dsc Up 0 (0) 0 (0)
esi Up 0 (0) 0 (0)
et-0/0/0 Down 0 (0) 0 (0)
et-0/0/1 Down 0 (0) 0 (0)
et-0/0/2 Down 0 (0) 0 (0)
et-0/0/3 Up 325358297942 (10804732) 342039523451 (11162237)
et-0/0/4 Up 341527145454 (11513156) 341462328952 (11155575)
et-0/0/5 Down 0 (0) 0 (0)
et-0/0/6 Down 0 (0) 0 (0)
et-0/0/7 Down 0 (0) 0 (0)
et-0/0/8 Down 0 (0) 0 (0)
et-0/0/9 Down 0 (0) 0 (0)
et-0/0/10 Down 0 (0) 0 (0)
et-0/0/11 Down 0 (0) 0 (0)
et-0/0/12 Down 0 (0) 0 (0)
et-0/0/13 Up 561246293674 (22317537) 553433268329 (22317527)
Figure 4
In the below output, 300K MAC addresses are learned on the service interfaces, and another 300K are learned on the LSI interfaces. Traffic forwarding without flooding is evident from the monitor interface traffic output above and the traffic snapshots.
VPLS Instance-level MACs are shown below based on the type of service.
BGP-VPLS:
root@PE1> show ethernet-switching table
MAC flags (S - static MAC, D - dynamic MAC, L - locally learned, P - Persistent static, C - Control MAC
SE - statistics enabled, NM - non configured MAC, R - remote PE MAC, O - ovsdb MAC
GBP - group based policy, B - Blocked MAC)
Ethernet switching table : 152 entries, 152 learned
Routing instance : bgp_vpls_1
Vlan MAC MAC Age GBP Logical NH MAC RTR
name address flags Tag interface Index property ID
vlan_1 00:00:12:00:00:01 D - lsi.1152968 0 0
.
.
.
vlan_1 00:00:12:01:81:53 D - lsi.1152968 0 0
vlan_1 00:00:12:01:86:88 D - lsi.1152968 0 0
vlan_1 00:11:01:00:00:01 D - et-0/0/13.1 0 0
vlan_1 00:11:01:00:05:36 D - et-0/0/13.1 0 0
.
.
.
vlan_1 00:11:01:01:81:53 D - et-0/0/13.1 0 0
vlan_1 00:11:01:01:86:88 D - et-0/0/13.1 0 0
LDP-VPLS:
root@PE1> show ethernet-switching table instance fec128_vpls_1400
MAC flags (S - static MAC, D - dynamic MAC, L - locally learned, P - Persistent static, C - Control MAC
SE - statistics enabled, NM - non configured MAC, R - remote PE MAC, O - ovsdb MAC
GBP - group based policy, B - Blocked MAC)
Ethernet switching table : 152 entries, 152 learned
Routing instance : fec128_vpls_1400
Vlan MAC MAC Age GBP Logical NH MAC RTR
name address flags Tag interface Index property ID
vlan1400 00:00:14:00:00:01 D - lsi.1275797 0 0
vlan1400 00:00:14:00:05:36 D - lsi.1275797 0 0
vlan1400 00:00:14:00:0a:6b D - lsi.1275797 0 0
.
.
.
vlan1400 00:00:18:00:82:2e D - lsi.1267307 0 0
vlan1400 00:00:18:00:87:63 D - lsi.1267307 0 0
vlan1400 00:00:18:00:8c:98 D - lsi.1267307 0 0
vlan1400 00:13:01:00:00:01 D - et-0/0/0.1400 0 0
vlan1400 00:13:01:00:05:36 D - et-0/0/0.1400 0 0
vlan1400 00:13:01:00:0a:6b D - et-0/0/0.1400 0 0
.
.
.
vlan1400 00:13:01:00:82:2e D - et-0/0/0.1400 0 0
vlan1400 00:13:01:00:87:63 D - et-0/0/0.1400 0 0
vlan1400 00:13:01:00:8c:98 D - et-0/0/0.1400 0 0
LDP-VPLS with BGP-AD:
root@PE1> show ethernet-switching table instance fec129_vpls_2740
MAC flags (S - static MAC, D - dynamic MAC, L - locally learned, P - Persistent static, C - Control MAC
SE - statistics enabled, NM - non configured MAC, R - remote PE MAC, O - ovsdb MAC
GBP - group based policy, B - Blocked MAC)
Ethernet switching table : 152 entries, 152 learned
Routing instance : fec129_vpls_2740
Vlan MAC MAC Age GBP Logical NH MAC RTR
name address flags Tag interface Index property ID
bd2740 00:00:15:00:00:01 D - lsi.1280640 0 0
bd2740 00:00:15:00:05:37 D - lsi.1280640 0 0
bd2740 00:00:15:00:0a:6d D - lsi.1280640 0 0
.
.
.
bd2740 00:00:19:00:82:47 D - lsi.1265973 0 0
bd2740 00:00:19:00:87:7d D - lsi.1265973 0 0
bd2740 00:00:19:00:8c:b3 D - lsi.1265973 0 0
bd2740 00:16:01:00:00:01 D - et-0/0/0.2740 0 0
bd2740 00:16:01:00:05:37 D - et-0/0/0.2740 0 0
bd2740 00:16:01:00:0a:6d D - et-0/0/0.2740 0 0
.
.
.
bd2740 00:16:01:00:82:47 D - et-0/0/0.2740 0 0
bd2740 00:16:01:00:87:7d D - et-0/0/0.2740 0 0
bd2740 00:16:01:00:8c:b3 D - et-0/0/0.2740 0 0
Junos Telemetry Streaming Data
System CPU, process memory, and core utilization were monitored using Juniper Streaming Telemetry, collecting data over a 6-hour period, with 4,000 VPLS instances running at 99.9% line-rate on 100GE links and 600K MAC addresses on the PTX10002-36QDD.
Figure 5 - Core utilization
Figure 6 - Junos Process memory
Figure 7 - System CPU
Figure 8 - Routing-engine CPU & memory
The Juniper Streaming Telemetry data of various router resources demonstrates the stability of the PTX10002-36QDD with heavy scaling with respect to VPLS.
VPLS BUM Traffic Flooding and Handling
This section validates the flooding behavior to all VPLS sites when handling BUM (Broadcast, Unknown Unicast, and Multicast) traffic.
Unknown unicast traffic is sent over VPLS instances to observe how the traffic is replicated across all sites. The traffic is flooded because the destination MAC addresses are not yet present in the forwarding table.
The following CLI outputs demonstrate that all MAC addresses are learned on the CE interface, not on the LSI, indicating the traffic is unknown unicast. Additionally, the core interfaces show a traffic rate double that of the ingress rate, reflecting the flooding of traffic to the other two sites.
root@PE1> show ethernet-switching table summary
Total dynamic and static MAC addresses learned globally : 0
Configured static MAC addresses learned globally : 0
PE1 Seconds: 36 Time: 09:33:54
Interface Link Input packets (pps) Output packets (pps)
dsc Up 0 (0) 0 (0)
esi Up 0 (0) 0 (0)
et-0/0/0 Up 588301612 (23492747) 0 (0) => CE intf
et-0/0/1 Down 0 (0) 0 (0)
et-0/0/2 Down 0 (0) 0 (0)
et-0/0/3 Up 485 (10) 565086123 (22564916) =>core intf
et-0/0/4 Up 483 (10) 565091426 (22564811) =>core intf
et-0/0/5 Down 0 (0) 0 (0)
et-0/0/6 Down 0 (0) 0 (0)
et-0/0/7 Down 0 (0) 0 (0)
et-0/0/8 Down 0 (0) 0 (0)
et-0/0/9 Down 0 (0) 0 (0)
et-0/0/10 Down 0 (0) 0 (0)
et-0/0/11 Down 0 (0) 0 (0)
et-0/0/12 Down 0 (0) 0 (0)
et-0/0/13 Down 0 (0) 0 (0)
et-0/0/14 Down 0 (0) 0 (0)
et-0/0/15 Down 0 (0) 0 (0)
et-0/0/16 Down 0 (0) 0 (0)
et-0/0/17 Down 0 (0) 0 (0)
et-0/0/18 Down 0 (0) 0 (0)
et-0/0/19 Down 0 (0) 0 (0)
et-0/0/20 Down 0 (0) 0 (0)
et-0/0/21 Down 0 (0) 0 (0)
et-0/0/22 Down 0 (0) 0 (0)
et-0/0/23 Down 0 (0) 0 (0)
et-0/0/24 Down 0 (0) 0 (0)
et-0/0/25 Down 0 (0) 0 (0)
et-0/0/26 Down 0 (0) 0 (0)
et-0/0/27 Down 0 (0) 0 (0)
et-0/0/28 Down 0 (0) 0 (0)
et-0/0/29 Down 0 (0) 0 (0)
et-0/0/30 Down 0 (0) 0 (0)
et-0/0/31 Down 0 (0) 0 (0)
et-0/0/32 Down 0 (0) 0 (0)
et-0/0/33 Down 0 (0) 0 (0)
et-0/0/34 Down 0 (0) 0 (0)
et-0/0/35 Down 0 (0) 0 (0)
root@PE1> show ethernet-switching table summary
Total dynamic and static MAC addresses learned globally : 231667
Configured static MAC addresses learned globally : 0
root@PE1> show ethernet-switching table | match lsi | count
Count: 0 lines
VPLS Split Horizon
By default, Juniper devices configured as PE routers enforce split-horizon operations, which helps prevent Layer 2 loops within the VPLS domain.
In this example, PE1 receives a broadcast from a split-horizon neighbor, PE2, on core interfaces. However, PE1 does not replicate this broadcast to other split-horizon neighbors, such as PE3. Instead, the traffic is only flooded to the service interface.
A notable observation here is the traffic classification into the Expedited Forwarding (EF) forwarding class and Queue 1, as it pertains to BUM traffic. Otherwise, the traffic would have been classified as Best Effort (BE) to be associated with Queue 0. In Juniper Express 5 architecture, BUM traffic is by default classified into Queue 1 for expedited handling, but this is configurable.
PE1 Seconds: 2 Time: 09:55:31
Interface Link Input packets (pps) Output packets (pps)
dsc Up 0 (0) 0 (0)
esi Up 0 (0) 0 (0)
et-0/0/0 Up 0 (0) 2752370611 (7431896) =>CE
et-0/0/1 Down 0 (0) 0 (0)
et-0/0/2 Down 0 (0) 0 (0)
et-0/0/3 Up 1292947569 (3494759) 4340 (13) =>core
et-0/0/4 Up 1459430778 (3940982) 4549 (14) =>core
root@PE1> show interfaces queue et-0/0/0
Physical interface: et-0/0/0, up, Physical link is Up
Interface index: 1251, SNMP ifIndex: 517
Forwarding classes: 16 supported, 4 in use
Egress queues: 8 supported, 4 in use
Queue: 0, Forwarding classes: best-effort
Queued:
Packets : 0 0 pps
Bytes : 0 0 bps
Transmitted:
Packets : 0 0 pps
Bytes : 0 0 bps
Tail-dropped packets : 0 0 pps
Tail-dropped bytes : 0 0 bps
RED-dropped packets : 0 0 pps
RED-dropped bytes : 0 0 bps
Queue: 1, Forwarding classes: expedited-forwarding
Queued:
Packets : 2871399225 7438573 pps
Bytes : 1527584387700 31658565632 bps
Transmitted:
Packets : 2871399225 7438573 pps
Bytes : 1527584387700 31658565632 bps
Tail-dropped packets : 0 0 pps
Tail-dropped bytes : 0 0 bps
RED-dropped packets : 0 0 pps
RED-dropped bytes : 0 0 bps
Queue: 2, Forwarding classes: assured-forwarding
Queued:
Packets : 0 0 pps
Bytes : 0 0 bps
Transmitted:
Packets : 0 0 pps
Bytes : 0 0 bps
Tail-dropped packets : 0 0 pps
Tail-dropped bytes : 0 0 bps
RED-dropped packets : 0 0 pps
RED-dropped bytes : 0 0 bps
Queue: 3, Forwarding classes: network-control
Queued:
Packets : 0 0 pps
Bytes : 0 0 bps
Transmitted:
Packets : 0 0 pps
Bytes : 0 0 bps
Tail-dropped packets : 0 0 pps
Tail-dropped bytes : 0 0 bps
RED-dropped packets : 0 0 pps
RED-dropped bytes : 0 0 bps
root@PE1> show ethernet-switching table summary
Total dynamic and static MAC addresses learned globally : 77223
Configured static MAC addresses learned globally : 0
root@PE1> show ethernet-switching table | match et- | count
Count: 0 lines
Default CoS Behavior on VPLS Traffic
By default, classifiers and rewrite rules are applied to both VPLS service interfaces and core interfaces.
In this section, we will observe the preservation of Class of Service (CoS) bits in the end-to-end VPLS traffic flow and examine the default CoS components applied to the PTX10002-36QDD interfaces.
root@PE1> show class-of-service interface et-0/0/0.1 =>Service intf
Logical interface: et-0/0/0.1, Index: 9238
Object Name Type Index
Classifier ieee8021p-default ieee-802.1 0
root@PE1> show class-of-service interface et-0/0/0.1400 =>Service intf
Logical interface: et-0/0/0.1400, Index: 6536
Object Name Type Index
Classifier ieee8021p-default ieee-802.1 0
root@PE1> show class-of-service interface et-0/0/0.2740 =>Service intf
Logical interface: et-0/0/0.2740, Index: 7869
Object Name Type Index
Classifier ieee8021p-default ieee-802.1 0
root@PE1> show class-of-service classifier name ieee8021p-default
Classifier: ieee8021p-default, Code point type: ieee-802.1, Index: 4
Code point Forwarding class Loss priority
000 best-effort low
001 best-effort high
010 expedited-forwarding low
011 expedited-forwarding high
100 assured-forwarding low
101 assured-forwarding high
110 network-control low
111 network-control high
root@PE1> show class-of-service interface et-0/0/3 => Core intf
Physical interface: et-0/0/3, Index: 1252
Maximum usable queues: 8, Queues in use: 4
Exclude aggregate overhead bytes: disabled
Logical interface aggregate statistics: disabled
Scheduler map: <default>
Congestion-notification: Disabled
Logical interface: et-0/0/3.0, Index: 9203
Object Name Type Index
Classifier ipprec-compatibility ip 0
Classifier exp-default exp 0
Rewrite exp-default exp (mpls-any) 0
root@PE1> show class-of-service interface et-0/0/4 => Core intf
Physical interface: et-0/0/4, Index: 1253
Maximum usable queues: 8, Queues in use: 4
Exclude aggregate overhead bytes: disabled
Logical interface aggregate statistics: disabled
Scheduler map: <default>
Congestion-notification: Disabled
Logical interface: et-0/0/4.0, Index: 9204
Object Name Type Index
Classifier ipprec-compatibility ip 0
Classifier exp-default exp 0
Rewrite exp-default exp (mpls-any) 0
root@PE1> show class-of-service classifier name exp-default
Classifier: exp-default, Code point type: exp, Index: 3
Code point Forwarding class Loss priority
000 best-effort low
001 best-effort high
010 best-effort medium-low
011 best-effort medium-high
100 network-control medium-low
101 network-control medium-high
110 network-control low
111 network-control high
root@PE1> show class-of-service rewrite-rule name exp-default
Rewrite rule: exp-default, Code point type: exp, Index: 1
Forwarding class Loss priority Code point
best-effort low 000
best-effort medium-low 010
best-effort medium-high 011
best-effort high 001
network-control low 110
network-control medium-low 100
network-control medium-high 101
network-control high 111
The default behavior on PTX10002-36QDD is designed to preserve CoS bits specified in the transmitted VPLS traffic. This is evident from the packet captures below, which show consistent CoS marking across the VPLS pseudowires.
Traffic flowing from the CE interface to the core interface carries an IEEE 802.1p VLAN priority value of 5, while traffic in the reverse direction—from core to CE—is marked with a VLAN priority of 7.
Figure 9 - Packet capture snapshot for traffic from CE to Core interface
Figure 10 - Core interface to CE interface traffic packet capture snapshot
VPLS MAC Learning Performance
This section highlights the MAC learning rate of the PTX10002-36QDD while operating at the full VPLS scale represented in this validation and examines the corresponding impact on system resources during this process.
A total of 600,000 MAC addresses are learned across 4,000 VPLS instances. The learning rates are shown in the table below, while system resource utilization is represented by the collected streaming telemetry data in the graphs.
| MACs |
50K |
100K |
200K |
333K |
400K |
500K |
600K |
Mac learning-rate |
| Duration |
9s |
19s |
40s |
66s |
80s |
100s |
123s |
4878 MACs/sec |
Learning rate (in seconds)
root@PE1> show ethernet-switching table summary
Total dynamic and static MAC addresses learned globally : 600000
Configured static MAC addresses learned globally : 0
The above streaming data illustrates the extent to which system resources are affected during the MAC learning process. From the telemetry data above, ~20% RE CPU utilization, ~50% peak core utilization, and processes utilization peaks are observed only during MAC learning and reverted back to normal values after the brief event period.
Also steep raise in memory according to MACs learnt during the learning phase and constant afterwards can be observed
MAC Flushing Rate
The default aging time of 300 seconds is applied, after which MAC addresses begin to gradually flush out of the router. The measured flushing rates are shown in the table below, and the corresponding impact on system resources is represented by the collected streaming telemetry data.
| MACs |
600K |
500K |
400K |
333K |
200K |
50K |
0 |
Mac learning-rate |
| Duration |
0 |
18s |
38s |
51s |
79s |
111s |
130s |
4615 MACs/sec |
MAC flushing rate (in seconds)
Following streaming data from Junos telemetry shows the effects of MAC flushing on PTX10002-36QDD.
Figure 14 - RE CPU spike and memory release can be observed here.
Figure 15 - Core utilization and process memory
Conclusion
PTX10002-36QDD supports the validated VPLS scale up to 4,000 instances, utilizing different implementations, such as BGP-VPLS, LDP-VPLS, and LDP-VPLS with BGP auto-discovery. The validation highlights the PTX10002-36QDD’s flexibility to support diverse network roles, including metro aggregation.
Useful links
Glossary
- BGP – Border Gateway Protocol
- BGP-AD – BGP with auto-discovery
- BX - Code name of Express 5 chipset
- CE – Customer Edge Node
- CoS – Class of Service
- DUT – Device Under Test
- ISIS - Intermediate System to Intermediate System
- KPI – Key Performance Indicators
- LAN – Local Area Network
- LDP – Label Distribution Protocol.
- LSP - Label Switch Routers
- MAC – Media Access Control
- MPLS – Multi Protocol Label Switching
- OSPF – Open Shortest Path First
- P/PE – Provider/Provider Edge Node
- PHP – Penultimate Hop Popping
- SR – Segment routing
- tLDP – Targeted LDP
- VPLS – Virtual Private LAN Service
- VLAN – Virtual LAN
Acknowledgements
Special thanks to Kevin Brown for his guidance and contributions throughout the development of this article. I'm also grateful to Dmitry Bugrimenko for his technical expertise on the inner workings of Express 5 and to Vasily Mukhin, Nicolas Fevrier, Peter Naveen and Rajneesh Kumar Srivastava for their valuable review and feedback.