In this article, we validate the VPLS feature scale support on the ACX7100-32C platform with 22.2R1 Junos-EVO build.
VPLS is a BGP or LDP MPLS Enabled Solution to connect Customer Edge Devices (CEs) across a Provider Edge Network. RFC4761 describes VPLS using BGP for Auto-Discovery and Signalling and RFC4762 presents VPLS using LDP Signalling. The PEs provide Layer 2 bridged connectivity between CEs. The PEs of the network are connected via MPLS technology with the help of LDP, RSVP, SR-MPLS, etc. In VPLS, the MAC address associated with the hosts is learned via the data plane.
JUNOS-EVO supports VPLS functionality with the instance type "virtual-switch" on ACX7000 platforms. In this article, we define the support and scale of the VPLS on the ACX7100-32C platform with LDP Signalling.
ACX7100-32C with 22.2R1 Junos Version supports 8,000 VPLS instances. The Key Performance Indicator (KPI) tested are captured in the below table. The same scale is tested on ACX7100-48L as well as on ACX7509 Scale is not covered in this article and supports a different scale.
Please note that despite sharing the same ACX moniker, the ACX7000 products are different products than ACX500/710/1000/1100/2100/2200/4000/5000/5400/6000. They are powered by different Packet Forwarding Engines (PFE), and support different feature sets and scales.
PEs are connected to CEs using 4x 100GE links. CEs are simulated using a traffic generator. PEs are connected to the core using 8x 100GE links, which are bundled in 2x LAGs each having four links.
The ACX7100-32C is the Device Under Test (DUT). The underlay transport used for testing is LDP with both OSPF and ISIS protocols individually. The CE-bound interface configurations are of SP-Style (see glossary).
Test configures 8,000 virtual-switch instances, 80 MACs are learned per instance, 40 from local and 40 from remote peers. Bidirectional traffic in iMIX mode at 99.9% offer-load flows for all the VPLS services. A total of ~800Gbps traffic transits through the DUT.
This section covers the configurations required to bring up VPLS using LDP signalling. In the PE Network, we can have OSPF or ISIS as the IGP protocol for the node connectivity and LDP or RSVP helps to bring up the transport protocol. BGP Auto-Discovery and ldp-signalling is enabled across the PE devices to enable VPLS services.
The PE devices are connected to the traffic generator using 4x 100GE interfaces, each interface is logically split into sub-interfaces using VLANs, one interface bound to one VPLS instance.
The first step to verify the VPLS service is to make sure that PE devices are having BGP established with l2vpn-signalling. As shown below from PE1, BGP is in established state for the Peer PE2 (12.1.1.3):
regress@PE1> show ethernet-switching table summary
Total dynamic and static MAC addresses learned globally : 640000
Configured static MAC addresses learned globally : 0
The VPLS connections is UP towards the 12.1.1.3 Peer for the routing-instance METRO_VPLS_VRF_1
regress@PE1> show vpls connections instance METRO_VPLS_VRF_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: METRO_VPLS_VRF_1
Edge protection: Not-Primary
LDP-VPLS State
VPLS-id: 1
Mesh-group connections: __ves__
Neighbor Type St Time last up # Up trans
12.1.1.3(vpls-id 1) rmt Up Oct 27 09:49:15 2022 1
Remote PE: 12.1.1.3, Negotiated control-word: No
Incoming label: 16, Outgoing label: 16
Negotiated PW status TLV: No
Local interface: lsi.1048576, Status: Up, Encapsulation: ETHERNET
Description: Intf - vpls METRO_VPLS_VRF_1 neighbor 12.1.1.3 vpls-id 1
Flow Label Transmit: No, Flow Label Receive: No
regress@PE1>
The VLAN Association of the METRO_MAC_VRF_1 instance is shown below.
regress@PE1> show ethernet-switching table instance METRO_VPLS_VRF_1
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)
Ethernet switching table : 80 entries, 80 learned
Routing instance : METRO_VPLS_VRF_1
Vlan MAC MAC Age Logical NH RTR
name address flags interface Index ID
VLAN_1 00:11:01:00:00:01 D - et-0/0/0.1 0 0
VLAN_1 00:11:01:00:00:02 D - et-0/0/0.1 0 0
...
VLAN_1 00:11:01:00:00:27 D - et-0/0/0.1 0 0
VLAN_1 00:11:01:00:00:28 D - et-0/0/0.1 0 0
VLAN_1 00:15:01:00:00:01 D - lsi.1048576 0 0
VLAN_1 00:15:01:00:00:02 D - lsi.1048576 0 0
....
VLAN_1 00:15:01:00:00:27 D - lsi.1048576 0 0
VLAN_1 00:15:01:00:00:28 D - lsi.1048576 0 0
regress@PE1>
The following output captures the total number of instances and total MAC learned in the DUT.
The Python Script is having three components, a Jinja File capturing the various configuration templates, a Params File capturing the various user variables and the script uses both these input files and generates the required configurations and commit that in the router.
Note: The configs are generated as per the CE-bound interface schema.
ACX7000 (ACX7100-32C, ACX7100-48L, ACX7509) can scale to 8,000 VPLS instances and 640,000 MAC addresses, it caters for Metro aggregation requirements. Next and finale article of the series will be dedicated to L2 MAC scale and learning rate validation, stay tuned :)