Hubbry Logo
Virtual Private LAN ServiceVirtual Private LAN ServiceMain
Open search
Virtual Private LAN Service
Community hub
Virtual Private LAN Service
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Virtual Private LAN Service
Virtual Private LAN Service
Virtual Private LAN Service
View on Wikipedia
from Wikipedia

Virtual Private LAN Service (VPLS) is a virtual private network (VPN) technology that provides Ethernet-based multipoint-to-multipoint communication over IP or MPLS networks. It allows geographically dispersed sites to share an Ethernet broadcast domain by connecting sites (including both servers and clients) through pseudowires.[1] The technologies that can be used as pseudo-wire can be Ethernet over MPLS, L2TPv3 or even GRE. There are two IETF standards-track RFCs (RFC 4761[2] and RFC 4762)[3] describing VPLS establishment. In contrast to L2TPv3, which allows only point-to-point OSI layer 2 tunnels, VPLS allows any-to-any (multipoint) connectivity.

Since VPLS emulates a LAN, full mesh connectivity is required. In a VPLS, the local area network (LAN) at each site is extended to the edge of the provider network. The provider network then emulates a switch or bridge to connect all of the customer LANs to create a single bridged LAN. There are two methods for full mesh establishment for VPLS: using Border Gateway Protocol (BGP) and using Label Distribution Protocol (LDP). BGP mechanisms used are very similar to those used in establishing OSI layer 3 MPLS VPNs and provide both auto-discovery and signalling; each provider edge (PE) router configured to participate in a given VPLS, through the use of BGP, simultaneously discovers all other PEs in the same VPLS, establishing a full mesh of pseudowires. With LDP, each PE router must be given the addresses of other PEs participating in the same VPLS. A full mesh of LDP sessions is then established, before LDP is used to create an equivalent mesh of pseudowires.

Benefits of VPLS include flexible bandwidth, sophisticated service level agreements, simplicity, and cost-effectiveness. VPLS users can also connect all of their sites to an Ethernet VPN that provides a secure, high speed and homogenous network.

Terminology and overview

[edit]
  • The "control plane" is the means by which provider edge (PE) routers communicate for auto-discovery and signalling.
  • Auto-discovery refers to the process of finding other PE routers participating in the same VPN or VPLS.
  • Signalling is the process of establishing pseudowires (PW).
  • The PWs constitute the "data plane", whereby PEs send customer VPN/VPLS traffic to other PEs.

An advantage to using PWs as the underlying technology for the data plane is that in the event of failure, traffic will automatically be routed along available backup paths in the service provider's network. Failover will be much faster than could be achieved with e.g. Spanning Tree Protocol (STP). VPLS is thus a more reliable solution for linking together Ethernet networks in different locations than simply connecting a WAN link to Ethernet switches in both locations.

VPLS MPLS packets have a two-label stack. The outer label is used for normal MPLS forwarding in the service provider's network. If BGP is used to establish the VPLS, the inner label is allocated by a PE as part of a label block. If LDP is used, the inner label is a virtual circuit ID assigned by LDP when it first established a mesh between the participating PEs. Every PE keeps track of assigned inner label, and associates these with the VPLS instance.

Ethernet emulation

[edit]

PEs participating in a VPLS-based VPN must appear as an Ethernet bridge to connected customer edge (CE) devices. Received Ethernet frames must be treated in such a way as to ensure CEs can be simple Ethernet devices.

When a PE receives a frame from a CE, it inspects the frame and learns the CE's MAC address, storing it locally along with LSP routing information. It then checks the frame's destination MAC address. If it is a broadcast frame, or the MAC address is not known to the PE, it floods the frame to all PEs in the mesh.

Ethernet does not have a time to live (TTL) field in its frame header, so loop avoidance must be arranged by other means. In regular Ethernet deployments, Spanning Tree Protocol is used for this. In VPLS, loop avoidance is arranged by the following rule: A PE never forwards a frame received from a PE to another PE. The use of a full mesh combined with split horizon forwarding guarantees a loop-free broadcast domain.

Scalability

[edit]

Hierarchical VPLS

[edit]

VPLS requires a full mesh in both the control and data planes; this can be difficult to scale. For BGP, the control plane scaling issue has long been addressed, through the use of route reflectors (RRs). RRs are extensively used in the context of Internet routing, as well as for several types of VPNs. To scale the data plane for multicast and broadcast traffic, there is work in progress to use point-to-multipoint LSPs as the underlying transport.

For LDP, a method of subdividing a VPLS VPN into two or three tiered hierarchical networks was developed. Called hierarchical VPLS (HVPLS), it introduces a new type of MPLS device: the multi-tenant unit (MTU) switch. This switch aggregates multiple customers into a single PE, which in turn needs only one control and data plane connection into the mesh. This can significantly reduce the number of LDP sessions and LSPs, and thus unburden the core network, by concentrating customers in edge devices.

HVPLS (LDP) may also be used to join two VPLS mesh structures together. Without using HVPLS, every node in each VPLS mesh must become meshed with all nodes in the other VPLS mesh. However, with HVPLS, the two meshes can essentially be joined together at certain locations. Techniques such as redundant pseudowires can provide resiliency in case of failures at the interconnection points.

MAC addresses

[edit]

Since VPLS links multiple Ethernet broadcast domains together, it effectively creates a much larger broadcast domain. Since every PE must keep track of all MAC addresses and associated LSP routing information, this can potentially result in a large amount of memory being needed in every PE in the mesh.

To counter this problem, sites may use a router as the CE device. This hides all MAC addresses on that site behind the CE's MAC address.

PE devices may also be equipped with content-addressable memory (CAM), similar to high-end Ethernet switches.

An alternative mechanism is using MAT (MAC Address Translation).[4] However, at the time of writing this, there are no vendors providing MAT functionality.

PE auto-discovery

[edit]

In a VPLS-based VPN with a large number of sites, manually configuring every participating PE does not scale well. If a new PE is taken into service, every existing PE needs to have its configuration adjusted to establish an LDP session with the new PE. Standardisation work is in progress to enable auto-discovery of participating PEs. Three implementations are being worked on:

LDP

[edit]

The LDP method of PE auto-discovery is based on that used by the Label Distribution Protocol to distribute labels across P and PE routers within a single autonomous system.

BGP

[edit]

The BGP method of PE auto-discovery is based on that used by Layer-3 MPLS VPNs to distribute VPN routes among PEs participating in a VPN. The BGP4 Multi-Protocol (BGP-MP) extensions are used to distribute VPN IDs and VPN-specific reachability information. Since IBGP requires either a full mesh of BGP sessions or the use of a route reflector, enabling the VPN ID in a participating PEs existing BGP configuration provides it with a list of all PEs in that VPN. Note that this method is for auto-discovery alone; LDP is still used for signaling. The method of establishing VPLS with BGP described above accomplishes both auto-discovery and signalling.

RADIUS

[edit]

This method requires all PEs to be configured with one or more RADIUS servers to use. When the first CE router in a particular VPLS VPN connects to the PE, it uses the CE's identification to request authentication from the RADIUS server. This identification may be provided by the CE or may be configured into the PE for that particular CE. In addition to a username and password, the identification string also contains a VPN name and an optional provider name.

The RADIUS server keeps track of all PEs that requested authentication for a particular VPN and returns a list of them to the PE requesting authentication. The PE then establishes LDP sessions to every PE in the list.

See also

[edit]
[edit]

References

[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Virtual Private LAN Service

View on Grokipedia
from Grokipedia
Virtual Private LAN Service (VPLS) is a Layer 2 (VPN) technology that emulates an Ethernet-based multipoint (LAN) over a provider's MPLS-based packet-switched network, allowing customer edge (CE) devices at dispersed sites to communicate as if connected via a single . Introduced in the mid-2000s through (IETF) standards, VPLS enables service providers to deliver transparent LAN services to enterprises, supporting applications like , bridging, and traffic replication across metropolitan or wide area networks. It operates by establishing pseudowires—virtual point-to-point links—between provider edge (PE) routers, which perform learning, forwarding, and flooding for broadcast, , and unknown unicast frames, mimicking traditional Ethernet switch behavior. There are two primary signaling mechanisms for VPLS: one using Border Gateway Protocol (BGP) for auto-discovery and distribution of reachability information via route targets and label blocks, as defined in RFC 4761, and another employing Label Distribution Protocol (LDP) to establish a full-mesh topology of pseudowires, per RFC 4762. In both approaches, PE routers maintain virtual switching instances (VSIs) for each VPLS service, handling attachment circuits to CE devices and ensuring service isolation through unique identifiers. This multipoint connectivity distinguishes VPLS from point-to-point services like Virtual Private Wire Service (VPWS), providing scalability for larger networks while supporting features such as hierarchical aggregation via user-facing PE (u-PE) devices.

Fundamentals

Definition and Purpose

Virtual Private LAN Service (VPLS) is a Layer 2 (VPN) technology that emulates an Ethernet (LAN) across a provider's (MPLS) or IP-based , enabling multiple customer sites to function as a single . As defined in RFC 4761 and RFC 4762, VPLS delivers multipoint-to-multipoint Ethernet connectivity through pseudowires, where provider edge (PE) routers perform learning, forwarding, and flooding of frames, including broadcast, , and unknown traffic, to replicate the behavior of a traditional Ethernet switch. This service integrates with MPLS for efficient tunneling and label-based forwarding, allowing seamless extension of customer LANs without modifications to customer edge (CE) devices. The primary purpose of VPLS is to provide transparent, geographically dispersed Ethernet connectivity that supports latency-sensitive and protocol-dependent applications, such as (VoIP), video conferencing, and interconnects (DCI), while insulating customers from the complexities of the underlying provider network. By maintaining full transparency for customer Layer 2 protocols like (ARP) and (STP), VPLS ensures that end-user applications operate as if all sites are on the same physical LAN, facilitating resource sharing and workload migration across locations. Unlike point-to-point services, VPLS's multipoint architecture supports efficient collaboration among multiple sites, reducing the need for customer-managed overlays and lowering operational costs for enterprises. VPLS was developed by the (IETF) in the early 2000s as an evolution of point-to-point Layer 2 VPNs like Virtual Private Wire Service (VPWS), with initial draft specifications emerging in 2003 to address the demand for scalable multipoint Ethernet services. occurred through RFC 4761 (using BGP for auto-discovery and signaling) and RFC 4762 (using for signaling) in 2007, building on earlier MPLS frameworks to enable service providers to offer LAN-like extensions over packet-switched networks. This progression from VPWS's limited point-to-point model to VPLS's emulation marked a key advancement in Layer 2 VPN technologies, prioritizing scalability and protocol transparency for modern enterprise needs.

Architectural Components

The architecture of Virtual Private LAN Service (VPLS) comprises several key components that enable the emulation of a multipoint Ethernet LAN across a provider's packet-switched network, ensuring transparent Layer 2 connectivity for customer sites. These elements include customer-facing devices, provider edge functions, core transit capabilities, virtual interconnections, and logical switching instances, all operating to bridge customer traffic without altering its Ethernet framing. Customer Edge (CE) devices serve as the demarcation point between the customer's and the service provider's domain. These are typically customer-owned routers or switches that interface directly with Provider Edge (PE) devices via attachment circuits (ACs), such as Ethernet links, and remain unaware of the underlying VPLS mechanisms. From the customer's perspective, the CE connects to a single virtual LAN, with no need for special configuration related to the provider's tunneling or bridging processes. Provider Edge (PE) routers form the core of the VPLS implementation, acting as the intelligent boundary devices that connect multiple CE devices and manage the service's forwarding logic. Each PE encapsulates and decapsulates customer Ethernet frames into pseudowires for transit across the provider network, while also performing MAC address learning and maintaining per-VPLS forwarding tables to enable efficient bridging. PEs are typically edge routers equipped with MPLS capabilities, ensuring that customer traffic is transparently forwarded based on Layer 2 headers without the CE devices requiring awareness of the provider's infrastructure. Provider (P) routers reside in the core of the service provider's network and handle the transit of encapsulated VPLS traffic between PEs, without any specific knowledge of the VPLS service itself. These routers forward packets using standard MPLS label switching or over transport tunnels, relying on the outer labels provided by PEs to route frames efficiently through the backbone. By design, P routers operate transparently to the VPLS emulation, focusing solely on high-speed packet transport. Pseudowires (PWs) represent the virtual point-to-point connections that link PEs, emulating dedicated Ethernet links to carry customer across the provider's network. In VPLS, PWs utilize MPLS labels (or alternative tunneling mechanisms like IP) for demultiplexing and transport, with each PW terminating on a PE to preserve the original Ethernet payload. This encapsulation allows for the seamless extension of the customer's LAN, as frames are bridged across PWs without modification to their Layer 2 content. The Forwarding Instance, often termed the Virtual Switching Instance (VSI), operates on each PE as a logical entity dedicated to a specific VPLS service, functioning like a distributed segment of an Ethernet switch. Each VSI maintains a separate (FIB) populated through MAC learning from incoming ACs and PWs, enabling forwarding, flooding of unknown frames, and broadcast/ distribution within the emulated LAN. VSIs ensure isolation between different VPLS services on the same PE, with capabilities for dynamic or static FIB management to support scalable Layer 2 bridging. At the network level, VPLS employs a full-mesh of pseudowires interconnecting all participating PEs, creating a loop-free multipoint domain that transparently bridges customer traffic as if all CEs were attached to a single Ethernet . This requires each PE to establish a PW to every other PE in the service, with techniques like split-horizon forwarding preventing loops while maintaining the illusion of a flat LAN. Customer Ethernet frames are thus forwarded across the PWs by the VSIs, emulating native LAN behavior over the provider's routed backbone.

Operational Mechanisms

Mesh and Pseudowire Establishment

In Virtual Private LAN Service (VPLS), the mesh topology is established by creating a full-mesh of point-to-point between all Provider Edge (PE) routers participating in a given service instance. This logical full-mesh ensures that customer Ethernet frames can be flooded for , , and unknown traffic across the emulated LAN, mimicking the behavior of a single without requiring physical connectivity between customer sites. Each PE maintains pseudowires to every other PE in the instance, enabling direct frame forwarding and avoiding intermediate hops within the provider network. Pseudowires in VPLS can be implemented using MPLS-based encapsulation, which is preferred for its label-switching efficiency and scalability in large networks, or IP-based encapsulation such as version 3 (L2TPv3) or Generic Routing Encapsulation (GRE). For MPLS-based pseudowires, signaling occurs via (LDP) in a full-mesh of targeted LDP sessions or (BGP) for auto-discovery and label exchange, with LDP operating in downstream unsolicited label allocation mode to assign unique labels per . IP-based options like L2TPv3 use session identifiers for demultiplexing, but they are less common due to higher overhead compared to MPLS. The establishment process begins with signaling protocols initiating pseudowire setup between PEs, where each PE allocates and exchanges labels or session identifiers to form the full mesh. Upon receiving an unknown unicast, broadcast, or multicast frame from a customer attachment circuit (AC), the ingress PE floods it across all pseudowires in the mesh, learning MAC addresses along the way to enable subsequent unicast forwarding. This dynamic learning and flooding mechanism, combined with label or identifier state exchange during signaling, ensures connectivity without prior knowledge of all destinations. To prevent bridging loops in the emulated LAN, VPLS integrates with customer (STP) by transparently tunneling STP Bridge Protocol Data Units (BPDUs) across pseudowires, allowing the customer's STP to handle loop resolution at . Provider-side mechanisms, such as the split-horizon rule, further enforce loop-free forwarding by prohibiting frames received on one pseudowire from being sent out another pseudowire within the same Virtual Switching Instance (VSI), ensuring the full-mesh topology remains stable. Configuration basics for mesh and pseudowire establishment involve creating a VPLS service instance, or VSI, on each participating PE router, where customer ACs—typically Ethernet ports or VLANs—are associated with the VSI to delineate the service boundary. PEs are manually provisioned with peer addresses and service identifiers (e.g., VPLS-ID encoded as an Attachment Group Identifier), after which signaling protocols automate creation; for example, LDP requires configuring targeted sessions, while BGP uses route targets for peer discovery. This setup ensures all pseudowires align with matching (MTU) values to avoid fragmentation.

Label Stack and Forwarding

In Virtual Private LAN Service (VPLS), the MPLS label stack encapsulates Ethernet frames for transport across the provider's core network, consisting of an outer transport label and an inner virtual circuit (VC) label. The outer transport label directs the packet along a label-switched path (LSP) to the remote provider edge (PE) router, while the inner VC label uniquely identifies the specific VPLS service instance or pseudowire (PW) to which the frame belongs. The forwarding process begins at the ingress PE router, where an incoming from a customer edge (CE) device is classified into a VPLS service instance (VSI) based on the access interface. The ingress PE performs a MAC address lookup in its forwarding database (FDB); if the destination MAC is known and associated with a remote PE, it imposes the corresponding VC label to demultiplex the frame to the appropriate PW, followed by the outer transport label for tunnel encapsulation. If the destination MAC is unknown, the frame is flooded by imposing VC labels for all remote PEs in the service, each paired with a transport label. In the core network, provider (P) routers forward the packet by swapping the outer transport label based on their MPLS forwarding tables, remaining unaware of the inner VC label or VPLS-specific details. Upon reaching the egress PE, the outer transport label is popped, exposing the VC label, which identifies the target VSI; the egress PE then strips the VC label, performs another FDB lookup, and delivers the frame to the appropriate local CE interface or floods it locally if necessary. Label imposition follows rules outlined in RFC 4761 for BGP-based VPLS and RFC 4762 for LDP-based VPLS, where the VC label is assigned per PW during signaling to ensure service isolation. An optional control word may be inserted immediately after the VC label and before the Ethernet payload; this 32-bit field provides sequence numbering to maintain packet order, and when used, the VC label's S-bit is set to 0, as specified in encapsulation standards. The control word is signaled via the C-bit in LDP or BGP extended communities and is typically disabled for Ethernet PWs unless required for fragmentation or reassembly. For tunnel selection, VPLS relies on MPLS LSPs established via protocols like LDP or RSVP-TE to carry the labeled packets, with the outer label binding to these tunnels for efficient core forwarding. Alternative transports, such as IP/MPLS or GRE tunnels, may be used in certain implementations for flexibility, particularly in non-MPLS cores. To enhance resilience, fast reroute (FRR) mechanisms can be applied to the transport LSPs, enabling sub-50ms protection against link or node failures by detouring traffic via backup paths. A representative example of the VPLS label stack for an is as follows:

Ethernet Header + Payload | [Optional Control Word] | VC Label (S=1, [BoS](/page/Bos)=1) | Transport Label (S=0, [BoS](/page/Bos)=0)

Ethernet Header + Payload | [Optional Control Word] | VC Label (S=1, [BoS](/page/Bos)=1) | Transport Label (S=0, [BoS](/page/Bos)=0)

Here, the VC label's BoS bit is set to 1 if no control word is used, while the transport label's BoS bit is set to 0 to indicate additional labels may follow in stacked scenarios.

Ethernet Emulation Model

The Virtual Private LAN Service (VPLS) provides transparent emulation of an Ethernet Layer 2 network by bridging customer Ethernet frames across a provider's MPLS core without modifying the frames' MAC addresses, tags, or higher-layer protocols such as ARP or (STP). This emulation ensures that customer sites perceive a single , as if connected via a common Ethernet switch, while the provider edge (PE) devices handle the transport over pseudowires (PWs). MAC address learning in VPLS occurs in a distributed manner across all participating PE devices, where each PE maintains its own forwarding database (FDB), also known as a MAC table, that associates customer MAC addresses with either local attachment circuits (ACs) or remote PWs. Upon receiving an Ethernet frame from a customer AC, the ingress PE examines the source MAC address and updates its FDB to map it to the corresponding AC or PW, enabling subsequent frames destined to that MAC to be forwarded efficiently. This learning process mirrors traditional Ethernet bridging but is replicated across the full mesh of PEs to maintain reachability information network-wide. Forwarding decisions in the VPLS emulation model follow standard Ethernet bridge behavior: known unicast frames are directed solely to the PW or AC associated with the destination MAC in the local FDB, while unknown unicast, broadcast, and multicast frames are flooded to all other PEs in the service instance via their respective PWs. This flooding mechanism ensures delivery to all potential recipients in the emulated LAN, replicating the broadcast domain semantics of a physical Ethernet segment. VPLS supports both port-based and VLAN-based service instances to delineate customer traffic, preserving VLAN tags within customer frames during transport over PWs. In a port-based instance, all traffic on an AC is treated as belonging to the VPLS domain without regard to VLAN tags, whereas VLAN-based instances allow selective inclusion based on specific 802.1Q tags, enabling multiple VPLS services per physical port. The PE devices do not alter or interpret these customer VLAN tags, ensuring end-to-end transparency for VLAN-aware customer equipment. A key limitation of the basic VPLS Ethernet emulation is the lack of native support for provider-side VLAN stacking, such as (QinQ), which is required for service multiplexing within the provider network; extensions or additional encapsulation are necessary to incorporate provider VLANs without impacting customer frames.

Scalability Solutions

Hierarchical VPLS Design

Hierarchical Virtual Private LAN Service (H-VPLS) extends the basic VPLS architecture to address scalability limitations of the full-mesh pseudowire topology, which requires O(n²) connections among provider edge (PE) devices for n sites, leading to excessive signaling and replication overhead. Introduced in RFC 4762, H-VPLS employs a two-tier hub-and-spoke model where access PEs, termed spoke PEs or multi-tenant units (MTU-s), connect via pseudowires to a smaller set of hub PEs (PE-rs), while the hub PEs maintain a full-mesh interconnection among themselves. This design segments the network into access and core layers, with spoke PEs establishing a single pseudowire per VPLS instance to one or more hub PEs, thereby reducing the total pseudowire count to O(n) and enabling deployment across thousands of sites. In the H-VPLS topology, spoke PEs handle local Ethernet frame switching for attached customer sites and forward inter-site traffic over spoke pseudowires to hub PEs, which perform bridging across these pseudowires and their access circuits (ACs) to emulate the LAN service. Hub PEs use Label Distribution Protocol (LDP) signaling per RFC 4447 for both spoke and hub pseudowires, ensuring consistent label stacking and forwarding. To accommodate double encapsulation—involving Ethernet headers, MPLS labels, and potential inner labels—implementations require maximum transmission unit (MTU) adjustments across the pseudowire paths, typically setting the service MTU to account for the additional overhead while maintaining end-to-end consistency. This hierarchical structure offloads core network traffic replication to the hubs, minimizing bandwidth usage in the provider core and supporting multi-tier extensions for further scalability. H-VPLS benefits large-scale deployments by limiting the full-mesh complexity to a manageable number of hub PEs, often in the range of tens, while spokes can number in the thousands per hub. For instance, in Ethernet access networks, H-VPLS supports up to 4,096 VPLS instances per access island using provider VLANs (P-VLANs), with multiple islands interconnected via hub PEs for metro-to-regional extensions in enterprise or environments. Dual-homing of spoke PEs to redundant hubs, combined with (STP) for loop prevention, enhances reliability without compromising the topology's efficiency. Overall, this approach facilitates transparent LAN emulation over wide-area MPLS networks while adhering to the Ethernet emulation model of basic VPLS.

MAC Address Management

In Virtual Private LAN Service (VPLS), Provider Edge (PE) devices perform MAC address learning by examining the source in incoming Ethernet frames received over attachment circuits (ACs) or pseudowires (PWs), associating each learned MAC with the corresponding ingress interface or PW to populate the forwarding database (FDB) for efficient unicast forwarding. This process emulates traditional Ethernet switch behavior, where known destination MACs are forwarded directly while unknown ones trigger flooding across the VPLS domain. To manage dynamic network changes, learned MAC entries include aging timers, with a typical aging time of 300 seconds in many implementations (vendor-specific), after which inactive entries are removed to free resources and prevent retention of stale mappings. Scalability challenges arise in full-mesh VPLS topologies, where unknown , broadcast, and traffic floods across all PWs, amplifying bandwidth consumption and potentially overwhelming PE resources as the number of sites grows. MAC table size limitations per Virtual Switching Instance (VSI), which vary by hardware and implementation, often with defaults in the hundreds and maximums up to 65,000 or more on high-end devices, can lead to exhaustion; once full, new MACs cannot be learned, resulting in continued flooding of unknown traffic or blackholing if discard-unknown policies are enforced, which drops such packets instead of replicating them. To address these issues, VPLS implementations support MAC withdrawal messages as defined in RFC 4762, allowing PEs to notify peers of invalid or aged-out MACs via LDP, reducing unnecessary flooding without full table resets. Additional mitigations include configuring static MAC entries for known stable addresses, which bypass dynamic learning and reserve FDB space, and applying to flooded traffic using ingress QoS policies on service access points (SAPs) to cap broadcast and unknown replication. For multicast optimization, integration with enables PEs to track group memberships and forward streams only to interested receivers, minimizing domain-wide flooding. In hierarchical VPLS (H-VPLS), MAC learning occurs locally at spoke PEs for attached sites, with unknown frames flooded over spoke pseudowires to hub PEs, which perform bridging and forward back to other spokes, confining much of the learning and replication to the access layer and reducing core overhead. Monitoring and maintenance tools in VPLS include MAC flush mechanisms triggered by topology changes, such as link failures or STP events, where PEs issue withdrawal messages with empty MAC lists to clear remote FDB entries and prevent persistent loops from outdated paths. These flushes, often configurable per VSI, facilitate rapid convergence by invalidating potentially looping routes while preserving local learning.

Provider Edge Auto-Discovery

Provider Edge (PE) auto-discovery in Virtual Private LAN Service (VPLS) enables the automatic detection of participating PEs and the establishment of pseudowires (PWs) without requiring manual configuration of a full-mesh among all PEs in a VPLS instance. This mechanism advertises VPLS instance details, such as service identifiers and information, allowing PEs to dynamically learn peers and set up connectivity, which enhances scalability in large deployments by reducing operational overhead. The Label Distribution Protocol (LDP)-based approach, defined in RFC 4762, extends LDP signaling for VPLS PW setup using targeted LDP sessions between PEs. PEs advertise the VPLS service ID, known as the Attachment Group Identifier (AGI), via the Generalized PWid Forwarding Equivalence Class (FEC) element (type 129), which includes the AGI as the unique VPLS identifier and null Attachment Individual Identifiers (AIIs) for the source and target. This allows PEs to discover peers and distribute VC labels over the full mesh of targeted LDP sessions, automating PW instantiation while relying on manual or external means for initial PE reachability. In contrast, the (BGP)-based method, outlined in RFC 4761 and refined in RFC 6074, uses BGP for both auto-discovery and signaling to support larger-scale VPLS deployments. PEs advertise VPLS membership through BGP Network Layer Reachability Information (NLRI) using the L2VPN Address Family Identifier (AFI 25) and VPLS Subsequent Address Family Identifier (SAFI 65), incorporating Route Targets (RTs) as extended communities to identify the VPLS instance and a (RD) combined with the PE address as the endpoint identifier. This enables PEs to import routes from matching RTs, learn remote PE addresses, and exchange VC labels or label blocks (via a label base and block size) for PW demultiplexing, with support for multi-homing through additional RT constraints. BGP's policy-based control and route reflection further optimize discovery in multi-AS environments. RADIUS integration complements BGP and LDP auto-discovery in scenarios by providing , , and (AAA) for dynamic VPLS service activation, particularly for subscriber-based deployments. RADIUS servers can trigger VPLS instance provisioning on PEs via attributes in authentication responses, enabling on-demand SDP bindings and PW setup without core PE rediscovery, often in combination with BGP for inter-PE signaling. For example, implementations use RADIUS to dynamically instantiate VPLS services from subscriber sessions, enhancing flexibility in broadband environments. LDP-based auto-discovery suits smaller deployments due to its and reliance on existing MPLS , but it requires a full of targeted sessions, limiting . BGP-based methods are preferred for large-scale networks offering better control, multi-homing, and reduced signaling overhead through route reflectors, while RADIUS adds value for dynamic, subscriber-driven activation in edge scenarios without native signaling for core discovery.

Advanced Topics

Management and OAM Features

Management of Virtual Private LAN Service (VPLS) relies on standardized protocols for configuration and oversight. The (SNMP) utilizes (MIB) modules to monitor and manage VPLS instances, including objects for pseudowire status, service parameters, and forwarding entries using dedicated MIB modules such as VPLS-BGP-MIB for BGP-signaled VPLS. Configuration is facilitated through command-line interfaces (CLI) on provider edge routers and emerging data models that abstract Layer 2 VPN services, enabling programmatic setup of virtual switching instances (VSIs) and pseudowire associations per RFC 8466. Service activation testing (SAT) employs Virtual Circuit Connectivity Verification (VCCV) mechanisms to validate pseudowire integrity before production use, as outlined in RFC 5085. Operations, Administration, and Maintenance (OAM) features in VPLS ensure ongoing reliability through fault detection and diagnostics. VCCV provides a control channel for verification, supporting ICMP-based ping or Label Switched Path (LSP) ping to confirm end-to-end connectivity without disrupting data traffic. (BFD) enhances liveliness monitoring by enabling sub-second failure detection on the data plane, integrated with VCCV for Layer 2 VPNs including VPLS. Monitoring capabilities focus on and alerting within VPLS domains. Providers collect traffic statistics per VSI, tracking ingress/egress packet counts, byte volumes, and error rates to assess utilization and anomalies. Alarm reporting notifies operators of events such as down states or MAC withdrawal failures, often via SNMP traps or integration. metrics like latency and are measured using extended OAM probes, providing insights into across the emulated LAN. In hierarchical VPLS (H-VPLS), OAM extends VCCV across multi-tier , allowing segmented fault isolation between access and core layers. Recent advancements integrate VPLS provisioning with (SDN) controllers for automation. Nokia's Network Services Platform (NSP), as of 2025 implementations on the 7750 Service Router, enables intent-based orchestration of VPLS services, automating setup, scaling, and fault remediation through model-driven APIs.

Security and Operational Challenges

Virtual Private LAN Service (VPLS) deployments are susceptible to several security risks stemming from its reliance on MPLS and Ethernet emulation. expose customer traffic to MPLS core attacks, such as label spoofing, where unauthorized labels are injected to hijack or redirect traffic, potentially enabling VPN hopping or unauthorized access across domains. Additionally, denial-of-service (DoS) attacks can overwhelm provider edge (PE) devices by exhausting tables, increasing CPU utilization and memory consumption, as demonstrated in tests on routers where flooding raised CPU from 2% to 25%. VPLS lacks native , leaving Ethernet frames vulnerable to sniffing, interception, and replay attacks during transit over provider networks. To mitigate these threats, operators implement access control lists (ACLs) on PE routers to validate incoming labels and filter unauthorized pseudowires, preventing spoofing and injection attacks. For BGP-signaled VPLS, authentication secures control plane exchanges, while tunnels can encapsulate pseudowires in IP-based deployments to provide encryption and integrity protection. Isolation is achieved through (VRF)-like segmentation per VPLS instance, using separate Layer 2 forwarding information bases (FIBs) to prevent cross-domain leakage, and limiting MAC addresses learned per site to curb DoS from excessive learning. LDP authentication per RFC 5036 further protects signaling in LDP-based VPLS. Operational challenges in VPLS arise primarily from configuration complexity in large-scale meshes, where full-mesh requirements—scaling as n*(n-1)/2 for n PEs—lead to high signaling overhead and resource strain. Troubleshooting distributed states across PEs is difficult due to the lack of centralized visibility, complicating fault isolation in multipoint topologies. MTU mismatches between customer edge devices and pseudowires often cause packet fragmentation or drops, as Ethernet frames exceeding the pseudowire MTU (typically bytes plus MPLS labels) require careful alignment to avoid performance degradation. A 2021 survey highlights additional complexity factors, including tunnel management overhead from manual provisioning of and compatibility issues with legacy Ethernet protocols, such as (STP) loops or broadcast storms when integrating older devices that expect native Layer 2 behavior. Multi-vendor interoperability challenges persist despite adherence to MEF standards for E-LAN services, which VPLS implements, due to vendor-specific extensions in pseudowire signaling and MAC handling. Best practices for addressing these issues include conducting regular security audits of PE configurations and pseudowire validations to detect anomalies, implementing phased rollouts for hierarchical VPLS (H-VPLS) to limit mesh scale during deployment, and deploying continuous monitoring for traffic patterns and MAC table sizes to preempt DoS risks.

Comparisons with EVPN

Ethernet VPN (EVPN), defined in RFC 7432, is a BGP-based control plane protocol that enables Layer 2 and Layer 3 VPN services by advertising MAC and IP routes through BGP, allowing for targeted traffic forwarding without relying on broadcast, unknown unicast, or multicast (BUM) flooding for MAC learning. In contrast, Virtual Private LAN Service (VPLS) primarily depends on data-plane learning and flooding mechanisms, which propagate unknown frames across the network, leading to higher bandwidth consumption and scalability challenges in large deployments. EVPN's control-plane approach distributes MAC addresses precisely via BGP routes, minimizing unnecessary traffic and enabling policy-based learning, which addresses key limitations in VPLS such as inefficient unknown unicast handling. A primary difference lies in multihoming support: EVPN offers both single-active (one active link, others standby) and all-active modes, facilitating per-flow load balancing and faster convergence upon failures, whereas VPLS is limited to active-backup redundancy without inherent load sharing. EVPN also integrates Layer 3 capabilities natively through IP prefix advertisements, allowing seamless L2/L3 VPN convergence, while VPLS focuses solely on Layer 2 emulation and requires separate mechanisms for IP services. These enhancements make EVPN more suitable for modern, large-scale environments like data centers and transport networks, where rapid convergence and efficiency are critical. Migration from VPLS to EVPN often involves hybrid setups where EVPN operates as an overlay on the existing MPLS underlay, enabling staged upgrades of provider edge (PE) devices without service disruption—EVPN handles forwarding among upgraded PEs, while VPLS manages legacy ones via pseudowires. Industry trends as of 2025 indicate a shift toward EVPN for and interconnects due to its superior scalability and resiliency, with seamless integration standards like RFC 8560 supporting in mixed environments. VPLS remains viable for legacy systems or small-scale multipoint Layer 2 needs where the added complexity of BGP signaling in EVPN provides no benefit.

References

  1. https://www.rfc-editor.org/rfc/rfc4761.html
  2. https://www.rfc-editor.org/rfc/rfc4762.html
  3. https://datatracker.ietf.org/doc/html/rfc4761
  4. https://datatracker.ietf.org/doc/html/rfc4762
  5. https://www.sciencedirect.com/science/article/pii/S1389128621002814
  6. https://datatracker.ietf.org/doc/html/draft-ietf-l2vpn-vpls-ldp-00
  7. https://datatracker.ietf.org/doc/html/rfc4664
  8. https://datatracker.ietf.org/doc/html/rfc4665
  9. https://www.rfc-editor.org/rfc/rfc6074.html
  10. https://documentation.nokia.com/sar-gen-2/25-3/7705-sar/books/layer-2-services-evpn/virtual-private-lan-service.html
  11. https://datatracker.ietf.org/doc/html/rfc4761#section-4.2
  12. https://datatracker.ietf.org/doc/html/rfc4761#section-3.2.4
  13. https://datatracker.ietf.org/doc/html/rfc4447#section-6.4
  14. https://datatracker.ietf.org/doc/html/rfc4447#section-3
  15. https://datatracker.ietf.org/doc/html/rfc4762#section-4
  16. https://datatracker.ietf.org/doc/html/rfc4762#section-4.1
  17. https://datatracker.ietf.org/doc/html/rfc4762#section-4.2
  18. https://datatracker.ietf.org/doc/html/rfc4762#section-7.2
  19. https://standards.ieee.org/ieee/802.1Q/6844/
  20. https://datatracker.ietf.org/doc/html/rfc4762#section-7.1
  21. https://datatracker.ietf.org/doc/html/rfc4762#section-8.1
  22. https://datatracker.ietf.org/doc/html/rfc4762#section-11
  23. https://www.rfc-editor.org/rfc/rfc4762.html#section-10
  24. https://www.rfc-editor.org/rfc/rfc4762.html#section-10.1
  25. https://www.rfc-editor.org/rfc/rfc4762.html#section-10.1.1
  26. https://www.rfc-editor.org/rfc/rfc4762.html#section-6.1.1
  27. https://www.rfc-editor.org/rfc/rfc4762.html#section-11.1
  28. https://www.rfc-editor.org/rfc/rfc4762.html#section-11.2
  29. https://infocenter.nokia.com/public/7750SR227R1A/topic/com.nokia.L2_Services_and_EVPN_Guide/vpls_mac_learni-ai9enrmqth.html
  30. https://www.cisco.com/c/en/us/td/docs/routers/xr12000/software/xr12k_r4-1/lxvpn/command/reference/vpn_cr41xr12k_chapter2.html
  31. https://www.cisco.com/c/en/us/td/docs/iosxr/ncs5xx/l2vpn/25xx/b-l2vpn-cg-25xx-ncs540/config-multipoint-layer2-services.html
  32. https://www.juniper.net/documentation/us/en/software/junos/vpn-l2/topics/concept/vpns-configuring-vpls-routing-instances.html
  33. https://documentation.nokia.com/html/0_add-h-f/93-0076-10-01/7750_SR_OS_Services_Guide/Service-VPLS-CLI.html
  34. https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/mp_l2_vpns/configuration/xe-16/mp-l2-vpns-xe-16-book/vpls-mac-address-withdrawal.html
  35. https://infocenter.nokia.com/public/7750SR217R1A/topic/com.nokia.L2_Services_and_EVPN_Guide_21.7.R1/vpls_and_rate_l-d620e1770.html
  36. https://www.juniper.net/documentation/us/en/software/junos/multicast/topics/topic-map/pim-snooping-vpls.html
  37. https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/vpls-flush-on-topology-change-edit-protocols-xstp.html
  38. https://datatracker.ietf.org/doc/html/rfc6074
  39. https://datatracker.ietf.org/doc/html/rfc4447
  40. https://datatracker.ietf.org/doc/html/rfc4360
  41. https://documentation.nokia.com/html/0_add-h-f/93-0076-10-01/7750_SR_OS_Services_Guide/services_con_vpls.html
  42. https://mibs.observium.org/mib/VPLS-BGP-MIB/
  43. https://datatracker.ietf.org/doc/html/rfc5085
  44. https://www.juniper.net/documentation/us/en/software/junos/vpn-l2/topics/task/vpn-bfd-configuring.html
  45. https://support.huawei.com/enterprise/en/doc/EDOC1100301726/209bc1be/verifying-traffic-statistics-on-a-vpls
  46. https://www.juniper.net/documentation/us/en/software/junos/vpn-l2/vpn-l2.pdf
  47. https://www.nokia.com/asset/i/164728/
  48. https://www.blackhat.com/presentations/bh-europe-06/bh-eu-06-Rey-up.pdf
  49. https://datatracker.ietf.org/doc/html/rfc5036
  50. https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/710x/l2vpn/configuration/guide/b-l2vpn-cg-asr9000-710x/implementing-multipoint-layer-2-services.html
  51. https://www.rfc-editor.org/rfc/rfc7387.html
  52. https://datatracker.ietf.org/doc/html/rfc7432
  53. https://datatracker.ietf.org/doc/html/rfc7432#section-1
  54. https://datatracker.ietf.org/doc/html/rfc7432#section-4
  55. https://datatracker.ietf.org/doc/html/rfc7432#section-14.1
  56. https://www.cisco.com/c/en/us/td/docs/iosxr/cisco8000/evpn/711x/configuration/guide/b-evpn-cg-cisco8000-711x/m-getting-started-with-evpn.html
  57. https://www.juniper.net/assets/us/en/local/pdf/books/day-one-poster-vpns.pdf
  58. https://www.cisco.com/c/en/us/td/docs/iosxr/cisco8000/evpn/711x/configuration/guide/b-evpn-cg-cisco8000-711x/migrate-vpls-network-to-evpn-network-through-seamless-integration.html
  59. https://www.juniper.net/documentation/us/en/software/junos/evpn/topics/concept/bgp-vpls-to-evpn-migration.html
  60. https://datatracker.ietf.org/doc/html/rfc8560
  61. https://blogs.juniper.net/en-us/industry-solutions-and-trends/the-2024-results-are-in-5g-transport-networks-the-focus-of-the-eantc-2024-multi-vendor-mpls-sdn-interoperability-test
Add your contribution
Related Hubs
User Avatar
No comments yet.