Service Provider Services: DIA, L2VPN, VPLS, and EVPN
A service provider’s MPLS backbone supports multiple service types simultaneously, each defined by the OSI layer it operates at, the topology it presents to customers, and the BGP address family that controls it [1, 13]. This chapter covers the five primary SP service models — L3VPN, DIA, L2VPN (VPWS), VPLS, and EVPN — progressing from the simplest dedicated internet pipe through to EVPN, the modern unified control plane that is steadily replacing legacy Layer 2 services [7, 13, 14].
Content
Service Model Taxonomy
Every SP service can be classified along three axes: the layer at which the customer hands off traffic, the logical topology the service presents, and what the customer perceives on their side of the demarcation [1, 13].
| Service | Layer | Topology | Customer Perspective |
|---|---|---|---|
| L3VPN | Layer 3 | Any-to-any | Private IP routing |
| DIA | Layer 3 | One-to-internet | Full BGP table/default |
| L2VPN/VPWS | Layer 2 | Point-to-point | Virtual wire |
| VPLS | Layer 2 | Any-to-any | Virtual switch |
| EVPN | L2 + L3 | Flexible | Modern unified fabric |
graph LR subgraph "Layer 3 Services" L3VPN["L3VPN<br/>Any-to-any IP"] DIA["DIA<br/>Internet access"] end subgraph "Layer 2 Services" VPWS["L2VPN / VPWS<br/>Point-to-point wire"] VPLS["VPLS<br/>Any-to-any switch"] end subgraph "Unified" EVPN["EVPN<br/>L2 + L3 fabric"] end VPLS -.->|"replaced by"| EVPN L3VPN -.->|"Type 5 routes"| EVPN style EVPN fill:#dfd,stroke:#333
L3VPN is covered in its own chapter. The sections below focus on DIA, L2VPN, VPLS, and EVPN.
Dedicated Internet Access (DIA)
DIA provides a committed-bandwidth, SLA-backed pipe from a customer site to the public internet. Unlike L3VPN, DIA traffic rides in the PE’s global routing table rather than a VRF. The customer receives a static public IP block and optionally peers with BGP using their own ASN.
Address Roles on the PE-CE Link
Two address blocks serve distinct purposes on every DIA handoff:
- Link prefix (e.g., 203.0.113.0/29) — allocated to the point-to-point connection between PE and CE. This prefix is never advertised beyond the link itself; it exists solely to establish Layer 3 reachability between the two routers.
- Customer public block (e.g., 198.51.100.0/24) — the routable prefix assigned to the customer’s servers, NAT pool, or public-facing infrastructure. The SP announces this block to the global internet on the customer’s behalf.
BGP Route Exchange
- CE to PE: The customer advertises its public block (198.51.100.0/24).
- PE to CE: The SP sends a default route (0.0.0.0/0), a partial table, or the full internet table depending on the service tier.
- PE to backbone: The PE redistributes the customer prefix into iBGP. Border PEs then announce it to upstream transit providers via eBGP.
PE Configuration Example
interface GigabitEthernet0/2
description to-CustB-DIA
ip address 203.0.113.1 255.255.255.248
bandwidth 1000000
!
router bgp 65000
address-family ipv4 unicast
neighbor 203.0.113.2 remote-as 65200
neighbor 203.0.113.2 prefix-list CUST-B-IN in
neighbor 203.0.113.2 prefix-list CUST-B-OUT out
neighbor 203.0.113.2 maximum-prefix 10
neighbor 10.0.0.100 next-hop-self
exit-address-family
!
ip prefix-list CUST-B-IN permit 198.51.100.0/24
ip prefix-list CUST-B-OUT permit 0.0.0.0/0
Two elements in this configuration deserve special attention:
Inbound prefix-list (CUST-B-IN): This is a security control. Without it, a misconfigured or malicious customer could announce arbitrary prefixes — effectively hijacking someone else’s address space (a real-world attack vector responsible for major outages). The prefix-list constrains the customer to only their authorized block.
next-hop-self: When the PE learns the customer prefix via eBGP, the BGP next-hop is the CE’s link address (203.0.113.2). iBGP preserves the next-hop by default, but the /29 link prefix is not redistributed into the IGP. Other PEs would have no route to resolve it. next-hop-self rewrites the next-hop to the PE’s loopback (10.0.0.12), which IS-IS already advertises.
Traffic Flow
Outbound (customer to internet): The customer’s server sends traffic to its default gateway (the CE). The CE matches the destination against the default route received from the SP and forwards to the PE. The PE polices ingress against the contracted bandwidth, performs a global-table lookup, and forwards toward the border PE via an MPLS LDP label path. Because DIA uses the global table (not a VRF), only a single transport label is needed — there is no VPN label. The border PE pops the label, performs an IP lookup, and forwards to the upstream transit provider.
Inbound (internet to customer): An internet router forwards traffic toward AS 65000. A border PE receives it, looks up the destination in iBGP, and finds the customer prefix with a next-hop of the serving PE. An LDP label path carries the packet across the core to the PE, which delivers it to the CE.
BGP Table Options for Customers
- Default route only — simplest option, suitable for single-homed customers who need only a way out.
- Partial table — the SP sends its own customer routes plus a default. Useful for multi-homed customers who want to make path-selection decisions for nearby destinations.
- Full internet table — approximately 1 million IPv4 prefixes (May 2026 figure; see https://bgp.potaroo.net). Required for customers implementing granular traffic engineering. Demands significant router memory on the CE side.
L2VPN with VPWS: The Virtual Wire
Virtual Private Wire Service (VPWS) provides a point-to-point Layer 2 circuit across the MPLS backbone [2]. The SP transports entire Ethernet frames transparently — the customer can run any protocol (IP, non-IP, or their own routing) over the link [2, 3]. VPWS is the right choice when the customer needs a Layer 2 handoff between exactly two sites [1, 13].
Configuration
Both PE endpoints reference each other’s loopback and share a common Virtual Circuit ID (VC ID):
PE1:
interface GigabitEthernet0/3
no ip address
xconnect 10.0.0.14 500 encapsulation mpls
PE4:
interface GigabitEthernet0/3
no ip address
xconnect 10.0.0.11 500 encapsulation mpls
Targeted LDP signals the pseudowire between the two PEs and exchanges VPN labels [4]. The forwarding path uses a two-label MPLS stack: the outer label is the LDP transport label (swapped hop-by-hop across the core), and the inner label identifies the specific pseudowire at the egress PE [2, 3]. A four-octet PWE3 control word may be inserted between the inner label and the customer payload to carry sequencing and flags [3].
VPWS performs no MAC learning. With only two endpoints, every frame entering one side exits the other — there is no forwarding decision to make [2].
VPLS: The Virtual Switch
Virtual Private LAN Service (VPLS) extends the virtual-wire concept to three or more sites, making the SP backbone behave like a single Ethernet switch [5, 6]. All participating sites share one broadcast domain [5, 6].
Configuration
Each PE in the VPLS instance maintains a Virtual Forwarding Instance (VFI) naming every other participating PE:
l2 vfi CUST-D-VPLS manual
vpn id 600
neighbor 10.0.0.12 encapsulation mpls
neighbor 10.0.0.13 encapsulation mpls
neighbor 10.0.0.14 encapsulation mpls
!
interface Vlan100
no ip address
xconnect vfi CUST-D-VPLS
Each PE maintains a per-instance MAC address table populated through data-plane learning [6]. A split-horizon rule prevents loops: frames received on one pseudowire are never forwarded to another pseudowire — only to local attachment circuits [5, 6]. This rule demands a full mesh of pseudowires between all PEs in the instance, scaling at O(n-squared) [6, 14].
VPLS Limitations
Five fundamental problems drove the industry toward EVPN [7, 13, 14]:
- O(n-squared) pseudowire mesh — signaling and state overhead grows quadratically with the number of PEs.
- No native multi-homing — connecting a CE to two PEs for redundancy requires awkward workarounds (e.g., STP across the backbone).
- Flooding inefficiency — every broadcast, unknown-unicast, and multicast frame is replicated to every PE in the instance.
- Data-plane MAC learning — convergence after a topology change is slow because MAC tables must be relearned from traffic, with no control-plane visibility into the process.
- No active-active forwarding — only one PE can forward at a time for a given CE, wasting the backup link’s capacity.
EVPN: The Modern Replacement
Ethernet VPN (EVPN) solves every VPLS limitation by moving MAC (and optionally IP) learning into the BGP control plane [7]. It uses MP-BGP with a dedicated address family (AFI 25, SAFI 70), treating MAC addresses the same way BGP treats IP prefixes — advertising them, withdrawing them, and applying route-target import/export filtering [7].
Configuration
EVPN reuses the same RD/RT model as L3VPN [7]:
l2vpn evpn instance 700 vlan-based
rd 65000:700
route-target import 65000:700
route-target export 65000:700
!
router bgp 65000
address-family l2vpn evpn
neighbor 10.0.0.100 activate
neighbor 10.0.0.100 send-community extended
exit-address-family
The route reflector infrastructure already deployed for L3VPN VPNv4 sessions serves EVPN as well — no new overlay topology is needed.
EVPN Route Types
RFC 7432 defines four EVPN route types (1: Ethernet A-D, 2: MAC/IP, 3: Inclusive Multicast Ethernet Tag, 4: Ethernet Segment) [7]; RFC 9136 adds Type 5 (IP Prefix) for L2/L3 unification [8]. Each route type carries a distinct class of reachability information:
| Type | Name | Defined in | Purpose |
|---|---|---|---|
| 1 | Ethernet Auto-Discovery | RFC 7432 | Multi-homing metadata: enables fast failover and aliased load balancing |
| 2 | MAC/IP Advertisement | RFC 7432 | Core route: advertises a MAC address, optionally with its host IP |
| 3 | Inclusive Multicast Ethernet Tag | RFC 7432 | Builds the BUM (broadcast/unknown-unicast/multicast) flooding tree |
| 4 | Ethernet Segment | RFC 7432 | Discovers co-attached PEs on the same CE; elects a Designated Forwarder |
| 5 | IP Prefix | RFC 9136 | Carries Layer 3 prefixes, enabling integrated L2+L3 VPN in one fabric |
Control-Plane MAC Learning
sequenceDiagram participant CE as CE (Host) participant PE1 participant RR as Route Reflector participant PE2 participant PE3 CE->>PE1: Frame arrives<br/>(src MAC: aa:bb:cc) Note over PE1: Learns MAC locally<br/>on attachment circuit PE1->>RR: BGP Type 2 Route<br/>MAC: aa:bb:cc<br/>EVI: 700, NH: PE1, Label: X RR->>PE2: Reflect Type 2 Route RR->>PE3: Reflect Type 2 Route Note over PE2,PE3: Install MAC route<br/>Future unicast → PE1 directly PE2->>PE1: Direct unicast to aa:bb:cc<br/>(no flooding!)
Advantages Over VPLS
| Capability | VPLS | EVPN |
|---|---|---|
| PE signaling | Full mesh of pseudowires — O(n²) | iBGP route reflector — O(n) |
| Multi-homing | Active-standby only (STP workaround) | Active-active with Designated Forwarder [12] |
| MAC learning | Data plane (flood-and-learn) | Control plane (BGP Type 2 routes) |
| Convergence on failure | Slow — MAC tables must age out | Sub-second — single BGP mass withdrawal |
| ARP handling | Flood to every PE | Local proxy-ARP from EVPN table |
| L2 + L3 integration | Separate control planes | Unified MP-BGP (Type 5 routes for IP) |
Industry Direction
Service Composition on a Single Backbone
A production PE typically runs multiple service types simultaneously for different customers, each isolated by its own BGP address family and forwarding construct:
| Service | BGP Address Family | Key Construct |
|---|---|---|
| L3VPN | vpnv4 unicast | VRF with RD/RT |
| DIA | ipv4 unicast | Global table + BGP peer |
| VPWS | l2vpn (LDP-signaled) | xconnect / pseudowire |
| VPLS | l2vpn (LDP or BGP) | L2 VFI |
| EVPN | l2vpn evpn | EVI with RD/RT |
The industry trajectory is clear: modern Tier-1 service providers are converging on EVPN as a unified control plane [13, 14]. EVPN fully replaces VPLS and, through Type 5 IP prefix routes, is capable of supplanting traditional L3VPN as well [7, 8]. EVPN also subsumes point-to-point VPWS via EVPN-VPWS [10] and large-scale carrier Ethernet via PBB-EVPN [11]. New SP deployments increasingly build on EVPN-VXLAN [9] or EVPN-MPLS [7] from the start, avoiding the legacy complexity of maintaining separate signaling protocols for each service type.
References
- RFC 4664 — Framework for Layer 2 Virtual Private Networks (L2VPNs). L. Andersson, E. Rosen (Eds.), IETF, September 2006. https://www.rfc-editor.org/rfc/rfc4664
- RFC 3985 — Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture. S. Bryant, P. Pate (Eds.), IETF, March 2005. https://www.rfc-editor.org/rfc/rfc3985
- RFC 4385 — Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN. S. Bryant et al., IETF, February 2006. https://www.rfc-editor.org/rfc/rfc4385
- RFC 8077 — Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP). L. Martini, G. Heron (Eds.), IETF (STD 84), February 2017 (obsoletes RFC 4447). https://www.rfc-editor.org/rfc/rfc8077
- RFC 4761 — Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling. K. Kompella, Y. Rekhter (Eds.), IETF, January 2007. https://www.rfc-editor.org/rfc/rfc4761
- RFC 4762 — Virtual Private LAN Service (VPLS) Using LDP Signaling. M. Lasserre, V. Kompella (Eds.), IETF, January 2007. https://www.rfc-editor.org/rfc/rfc4762
- RFC 7432 — BGP MPLS-Based Ethernet VPN. A. Sajassi (Ed.) et al., IETF, February 2015. https://www.rfc-editor.org/rfc/rfc7432
- RFC 9136 — IP Prefix Advertisement in Ethernet VPN (EVPN). J. Rabadan (Ed.) et al., IETF, October 2021. https://www.rfc-editor.org/rfc/rfc9136
- RFC 8365 — A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN). A. Sajassi (Ed.) et al., IETF, March 2018. https://www.rfc-editor.org/rfc/rfc8365
- RFC 8214 — Virtual Private Wire Service Support in Ethernet VPN. S. Boutros et al., IETF, August 2017. https://www.rfc-editor.org/rfc/rfc8214
- RFC 7623 — Provider Backbone Bridging Combined with Ethernet VPN (PBB-EVPN). A. Sajassi (Ed.) et al., IETF, September 2015. https://www.rfc-editor.org/rfc/rfc7623
- RFC 8584 — Framework for Ethernet VPN Designated Forwarder Election Extensibility. J. Rabadan (Ed.) et al., IETF, April 2019. https://www.rfc-editor.org/rfc/rfc8584
- A. Sánchez-Monge, K. G. Szarkowicz, MPLS in the SDN Era, O’Reilly, 2015.
- I. Minei, J. Lucek, MPLS-Enabled Applications, 3rd ed., Wiley, 2011.