Skip to content

L3VPN Overview

Jump to bottom
Thomas Mangin edited this page Mar 6, 2026 · 1 revision

L3VPN (Layer 3 VPN) Overview

L3VPN (Layer 3 Virtual Private Network) is a BGP/MPLS-based technology that enables service providers and enterprises to deliver scalable, secure IP VPN services. Defined in RFC 4364, L3VPN uses MP-BGP to distribute customer IPv4 and IPv6 routes with VPN context (VRF - Virtual Routing and Forwarding), allowing multiple isolated routing tables to coexist over a shared MPLS infrastructure.

ExaBGP provides full L3VPN support for both VPNv4 and VPNv6 address families, enabling applications to programmatically inject and receive L3VPN routes for network automation, service provisioning, and VPN testing.

Table of Contents

What is L3VPN?

L3VPN (Layer 3 Virtual Private Network) is a service that allows multiple customers to share a common IP/MPLS infrastructure while maintaining complete routing isolation. Each customer gets a dedicated virtual routing instance (VRF), and BGP distributes customer routes with VPN labels.

How L3VPN Works

[L3VPN Architecture]

Customer A Site 1                    Customer A Site 2
   10.1.0.0/16                          10.2.0.0/16
       │                                      │
       │                                      │
    ┌──▼───┐      MPLS Core Network      ┌───▼──┐
    │  PE1 │◄──────────────────────────►│  PE2  │
    │ VRF-A│         BGP VPNv4           │ VRF-A │
    └──┬───┘     (Route Distribution)   └───┬───┘
       │                                      │
Customer B Site 1                    Customer B Site 2
   10.1.0.0/16                          10.2.0.0/16
  (Same IPs, isolated)              (Same IPs, isolated)

Process:

  1. VRF Creation: PE routers create isolated routing tables per customer (VRF)
  2. Route Learning: PE learns customer routes via CE (Customer Edge) connection (static, OSPF, BGP)
  3. BGP VPN Route Advertisement: PE advertises routes with RD (uniqueness) and RT (import/export control) via MP-BGP
  4. Label Distribution: MPLS VPN labels indicate which VRF to use at remote PE
  5. Route Import: Remote PE imports routes into matching VRF based on RT
  6. Forwarding: Traffic forwarded with two-label stack (VPN label + transport label)

Key Components:

  • PE (Provider Edge): Router connected to customer, maintains VRFs
  • CE (Customer Edge): Customer router, unaware of MPLS/VPN
  • P (Provider): Core MPLS router, no customer routes
  • VRF: Isolated routing instance per customer/service
  • MP-BGP: Distributes VPN routes between PEs
  • MPLS: Provides label-switched forwarding

Why Use L3VPN?

Advantages Over Traditional VPNs

Feature L3VPN (MPLS VPN) Traditional VPN (IPsec, GRE)
Scalability Thousands of VPNs Limited (mesh complexity)
Performance Line-rate forwarding Encryption overhead
Topology Any-to-any (hub-and-spoke, full mesh) Manual configuration
Address Overlap Supported (10.0.0.0/8 in multiple VPNs) Not supported
QoS Native MPLS QoS Tunnel limitations
Provider Control Service provider managed Customer managed

Common Use Cases

  1. Service Provider VPN: ISPs offering enterprise VPN services
  2. Enterprise WAN: Large enterprise connecting branch offices
  3. Multi-Tenant Data Centers: Cloud providers isolating customer networks
  4. Internet Access Services: Shared internet VRF + private VRFs
  5. Carrier's Carrier: Service provider as customer of another SP

ExaBGP L3VPN Capabilities

ExaBGP provides full RFC 4364 L3VPN implementation:

Supported Features

✅ Address Families:

  • VPNv4 (IPv4 VPN): IPv4 routes with MPLS VPN labels
  • VPNv6 (IPv6 VPN): IPv6 routes with MPLS VPN labels

✅ Route Distinguisher (RD) Types:

  • Type 0: AS:nn (2-byte AS : 4-byte number)
  • Type 1: IP:nn (4-byte IP : 2-byte number)
  • Type 2: AS:nn (4-byte AS : 2-byte number)

✅ Route Target Extended Communities:

  • Import RT: Controls route import into VRF
  • Export RT: Attached to routes exported from VRF
  • 2-byte AS, 4-byte AS, and IPv6 RT formats

✅ MPLS Labels:

  • Single label or label stack
  • Supports label values 0-1048575

✅ Standard BGP Attributes:

  • AS-PATH, MED, LOCAL_PREF, COMMUNITIES, etc.
  • All standard attributes apply to VPN routes

Implementation:

  • src/exabgp/bgp/message/update/nlri/ipvpn.py (VPN NLRI encoding/decoding)
  • src/exabgp/protocol/family.py (MPLS_VPN SAFI)

RFC Support

  • RFC 4364: BGP/MPLS IP Virtual Private Networks (VPNs) - Fully Implemented
  • RFC 4659: BGP/MPLS IPv6 VPN Extension - Fully Implemented
  • RFC 4360: BGP Extended Communities Attribute - Fully Implemented
  • RFC 5668: 4-Octet AS Specific BGP Extended Community - Fully Implemented

Key Concepts

Route Distinguisher (RD)

The Route Distinguisher makes each customer route globally unique in the BGP table, even if customers use overlapping address space.

Format: ASN:Value or IP:Value

Types:

  • Type 0: 65000:100 (2-byte AS : 4-byte value)
  • Type 1: 192.0.2.1:100 (IPv4 address : 2-byte value)
  • Type 2: 4200000000:100 (4-byte AS : 2-byte value)

Purpose: Allows multiple customers to use 10.0.0.0/8 without conflict.

Example:

Customer A: RD 65001:100 prefix 10.1.0.0/24
Customer B: RD 65002:100 prefix 10.1.0.0/24

BGP Table:
  65001:100:10.1.0.0/24 → Customer A
  65002:100:10.1.0.0/24 → Customer B (different route despite same prefix)

Note: RD is for uniqueness only; it does NOT control import/export (that's RT's job).

Route Target (RT)

The Route Target extended community controls which VRFs import which routes.

Format: target:ASN:Value

Export RT: Attached to routes when exported from a VRF. Import RT: Configured on VRF; imports routes with matching RT.

Example:

PE1 VRF-A:
  Route Distinguisher: 65001:100
  Export RT: target:65001:100
  Import RT: target:65001:100

PE2 VRF-A:
  Route Distinguisher: 65002:100
  Export RT: target:65001:100  ← Exports with same RT
  Import RT: target:65001:100  ← Imports routes with this RT

Result: PE1 and PE2 can exchange routes for same VPN

Hub-and-Spoke Topology:

Hub PE:
  Export RT: target:65001:200  ← Spoke VRFs import this
  Import RT: target:65001:100  ← Hub imports from spokes

Spoke PE:
  Export RT: target:65001:100  ← Hub imports this
  Import RT: target:65001:200  ← Spoke imports from hub

Result: Spokes can reach hub, but NOT each other (hub-and-spoke)

VRF (Virtual Routing and Forwarding)

A VRF is an isolated routing table on a router, enabling multiple routing instances.

Components:

  • Routing table: Separate from global routing table
  • Forwarding table: Independent FIB per VRF
  • RD: Makes routes unique in BGP
  • RT: Controls route import/export
  • Interfaces: Assigned to VRF

ExaBGP's Role: ExaBGP does NOT create VRFs. It announces/receives VPN routes. The PE router maintains VRFs and installs routes.

MPLS Labels

L3VPN uses MPLS labels to identify which VRF to use at the remote PE.

Label Stack:

[Outer Label: Transport LSP to remote PE]
[Inner Label: VPN label indicating VRF]
[IP Packet]

Process:

  1. Ingress PE pushes two labels: VPN label (inner) + transport label (outer)
  2. P routers swap transport label only
  3. Egress PE pops transport label, examines VPN label
  4. VPN label indicates which VRF to use for IP lookup
  5. PE forwards based on VRF routing table

ExaBGP's Role: ExaBGP includes the VPN label in BGP VPN route advertisements but does NOT push/pop labels (that's the router's job).

L3VPN vs EVPN

Feature L3VPN EVPN
Layer Layer 3 (IP routing) Layer 2 (MAC learning) + Layer 3
Primary Use IP VPN services Data center fabrics, L2VPN
Route Type IP prefixes MAC addresses, IP prefixes
Forwarding IP routing MAC forwarding + IP routing
Encapsulation MPLS MPLS or VXLAN
Multi-homing Active-standby (typically) Active-active
Address Family VPNv4/VPNv6 (SAFI 128/129) EVPN (AFI 25, SAFI 70)

When to Use L3VPN: IP-based enterprise/SP VPNs, WAN services, internet access

When to Use EVPN: Data center L2 stretch, VXLAN overlays, VM mobility

Configuration Examples

Basic L3VPN Configuration

# /etc/exabgp/l3vpn.conf

neighbor 192.0.2.1 {
    router-id 192.0.2.2;
    local-address 192.0.2.2;
    local-as 65001;
    peer-as 65000;

    # Enable VPNv4 address family
    family {
        ipv4 vpn;
        ipv6 vpn;
    }

    # API process for dynamic VPN route announcements
    api {
        processes [ vpn-controller ];
    }
}

process vpn-controller {
    run python3 /etc/exabgp/vpn-announce.py;
    encoder text;
}

VPN Route Announcement Script

#!/usr/bin/env python3
# /etc/exabgp/vpn-announce.py

import sys
import time

def announce_vpn_route(prefix, rd, rt, label, nexthop="self"):
    """Announce L3VPN route"""
    print(f"announce vpn {prefix} "
          f"next-hop {nexthop} "
          f"route-distinguisher {rd} "
          f"extended-community [ target:{rt} ] "
          f"label [ {label} ]")
    sys.stdout.flush()

def withdraw_vpn_route(prefix, rd, rt, label, nexthop="self"):
    """Withdraw L3VPN route"""
    print(f"withdraw vpn {prefix} "
          f"next-hop {nexthop} "
          f"route-distinguisher {rd} "
          f"extended-community [ target:{rt} ] "
          f"label [ {label} ]")
    sys.stdout.flush()

# Announce customer route
announce_vpn_route(
    prefix="10.1.0.0/24",
    rd="65001:100",
    rt="65001:100",
    label=10000
)

# Keep process running
while True:
    time.sleep(60)

API Examples

Announce VPNv4 Route (Text API)

Basic VPN route:

print("announce vpn 10.1.0.0/24 "
      "next-hop self "
      "route-distinguisher 65001:100 "
      "extended-community [ target:65001:100 ] "
      "label [ 10000 ]")
sys.stdout.flush()

With multiple attributes:

print("announce vpn 10.1.0.0/24 "
      "next-hop self "
      "route-distinguisher 65001:100 "
      "extended-community [ target:65001:100 ] "
      "label [ 10000 ] "
      "local-preference 200 "
      "med 50 "
      "community [ 65001:100 ]")
sys.stdout.flush()

Announce VPNv6 Route

print("announce vpn 2001:db8:1::/48 "
      "next-hop self "
      "route-distinguisher 65001:100 "
      "extended-community [ target:65001:100 ] "
      "label [ 10000 ]")
sys.stdout.flush()

Withdraw VPN Route

print("withdraw vpn 10.1.0.0/24 "
      "next-hop self "
      "route-distinguisher 65001:100 "
      "extended-community [ target:65001:100 ] "
      "label [ 10000 ]")
sys.stdout.flush()

JSON API Format

{
  "exabgp": "5.0",
  "type": "update",
  "neighbor": {
    "address": {"local": "192.0.2.2", "peer": "192.0.2.1"},
    "message": {
      "update": {
        "announce": {
          "ipv4 vpn": {
            "10.1.0.0/24": {
              "attributes": {
                "route-distinguisher": "65001:100",
                "next-hop": "192.0.2.2",
                "label": [10000],
                "extended-community": ["target:65001:100"],
                "local-preference": 200
              }
            }
          }
        }
      }
    }
  }
}

Use Cases

1. Enterprise WAN Connectivity

Scenario: Enterprise with 100+ branch offices requiring secure connectivity to HQ and data centers.

How L3VPN Helps:

  • Single VRF for all sites (full mesh connectivity)
  • Hub-and-spoke topology (branches → HQ, no branch-to-branch)
  • Separate VRFs for different departments (HR, Finance, Engineering)

ExaBGP Role:

  • Inject routes for branch LANs
  • Announce data center services
  • Automate route provisioning
  • Integrate with orchestration systems

Example Topology:

Branch Offices (100+)
       │
       ├─→ [ExaBGP] ──VPNv4──→ [SP PE Routers]
       │                            │
       │                            ▼
       └────────────────────→ HQ + Data Centers

2. Service Provider VPN Services

Scenario: ISP offering managed VPN services to multiple enterprise customers.

How L3VPN Helps:

  • Each customer gets dedicated VRF
  • Overlapping address space supported (10.0.0.0/8 for all customers)
  • Centralized route management
  • SLA monitoring and TE

ExaBGP Role:

  • Automate customer onboarding (provision VRFs programmatically)
  • Inject default routes for internet access
  • Implement policy-based routing
  • Integration with OSS/BSS systems

3. Multi-Tenant Data Centers

Scenario: Cloud provider with multiple tenants requiring network isolation.

How L3VPN Helps:

  • Tenant isolation via VRFs
  • Shared services VRF (DNS, NTP, monitoring)
  • Inter-tenant routing (via route leaking)

ExaBGP Role:

  • Dynamic route announcements as VMs are created/destroyed
  • Integration with OpenStack, VMware, Kubernetes
  • Programmatic VRF management

4. Internet Access with Private VPN

Scenario: Enterprise needs both private WAN and internet access.

Architecture:

Customer VRF (Private):
  RD: 65001:100
  Export RT: target:65001:100
  Import RT: target:65001:100, target:65001:999

Internet VRF (Shared):
  RD: 65001:999
  Export RT: target:65001:999
  Routes: Default route 0.0.0.0/0

Result: Customer VRF imports private routes + default route

ExaBGP Role:

  • Announce default route into customer VRFs
  • Policy-based routing (specific destinations via VPN, rest via internet)

5. Carrier's Carrier (CsC)

Scenario: Service provider A is a customer of service provider B (nested VPNs).

How L3VPN Helps:

  • Outer VPN (SP-B provides connectivity for SP-A)
  • Inner VPN (SP-A provides services to end customers)
  • Label stacking (VPN label + transport label + outer VPN label)

ExaBGP Role:

  • Inject VPN routes at both layers
  • Test CsC configurations
  • Automate route propagation

6. Disaster Recovery and Data Center Interconnect

Scenario: Active-active or active-standby data centers with L3VPN connectivity.

How L3VPN Helps:

  • Stretch VRFs across data centers
  • Anycast service IPs with different metrics
  • Fast convergence (BGP + MPLS)

ExaBGP Role:

  • Announce service IPs with health-check-based metrics
  • Automatic failover (withdraw routes on failure)
  • Integration with load balancers

Common Errors and Solutions

Error: "Route Distinguisher required for VPN routes"

Cause: VPN routes must include a Route Distinguisher.

Solution: Always specify route-distinguisher in announcements.

# Incorrect
print("announce vpn 10.1.0.0/24 next-hop self label [ 10000 ]")

# Correct
print("announce vpn 10.1.0.0/24 "
      "next-hop self "
      "route-distinguisher 65001:100 "  # Required
      "label [ 10000 ]")

Error: "Route Target extended community missing"

Cause: Route Target controls import/export. Without RT, routes won't be imported into VRFs.

Solution: Include at least one Route Target extended community.

print("announce vpn 10.1.0.0/24 "
      "next-hop self "
      "route-distinguisher 65001:100 "
      "extended-community [ target:65001:100 ] "  # Required
      "label [ 10000 ]")

Error: "Label value out of range"

Cause: MPLS label values must be 0-1048575 (20-bit label field).

Solution: Use valid label range. Typically 16-1048575 (0-15 reserved).

# Valid
label [ 10000 ]

# Invalid
label [ 2000000 ]  # Too large

Error: "Routes announced but not imported into VRF"

Cause: Import RT on PE router doesn't match Export RT in announcement.

Solution: Verify RT configuration on PE router matches ExaBGP announcement.

PE Router (Example - Cisco IOS-XR):

vrf customer-a
 address-family ipv4 unicast
  import route-target
   65001:100     ← Must match ExaBGP's target:65001:100
  !
  export route-target
   65001:100
  !
 !
!

Error: "VPNv4 family not enabled on peer"

Cause: Remote router doesn't have VPNv4 address family configured.

Solution: Enable VPNv4 on both ExaBGP and the peer router.

Cisco IOS-XR:

router bgp 65000
 neighbor 192.0.2.2
  address-family vpnv4 unicast  ← Enable VPNv4
  !
 !
!

Juniper Junos:

protocols {
    bgp {
        group exabgp {
            family inet-vpn {  ← Enable VPNv4
                unicast;
            }
        }
    }
}

Error: "Routes received but not forwarding traffic"

Cause: ExaBGP does NOT install routes in FIB or program MPLS forwarding.

Solution: ExaBGP is for BGP protocol only. The PE router must:

  • Have VRF configured
  • Import routes based on RT
  • Have MPLS forwarding enabled
  • Have LDP or SR labels for transport

Remember: ExaBGP announces VPN routes via BGP but does NOT create VRFs or forward traffic.

Important Considerations

ExaBGP Does Not Manipulate RIB/FIB

⚠️ CRITICAL: ExaBGP is a BGP protocol engine. It does NOT:

  • Create VRFs on routers
  • Install VPN routes in RIB
  • Program MPLS forwarding tables
  • Push/pop MPLS labels
  • Forward L3VPN traffic

What ExaBGP DOES:

  • ✅ Send/receive VPN routes via BGP
  • ✅ Encode VPNv4/VPNv6 NLRIs with RD, RT, labels
  • ✅ Provide API for applications to control VPN routes
  • ✅ Handle BGP session management

External Infrastructure Required:

  • PE Routers: Cisco, Juniper, Nokia, Arista routers with VRF support
  • MPLS Network: LDP, RSVP-TE, or Segment Routing for transport labels
  • VRF Configuration: VRFs must be pre-configured on PE routers
  • Route Import: PE routers import routes based on RT configuration

Typical Architecture:

[Your Application]
       │
       ├─→ [ExaBGP] ─── BGP VPNv4 ───→ [PE Routers]
       │      (Control Plane)              │
       │                                   ├─ VRF Creation
       │                                   ├─ Route Import/Export
       │                                   └─ MPLS Forwarding
       │
       └─→ [Orchestration] ───NETCONF───→ [PE Routers]
              (VRF Provisioning)

Label Management

Important: The label value in ExaBGP announcements is just a number. The PE router must:

  • Allocate label from its label space
  • Map label to VRF
  • Program MPLS forwarding to use that label

Best Practice: Use consistent label allocation schemes:

  • Dynamic allocation: PE allocates labels automatically
  • Static allocation: Coordinate label values between ExaBGP and PE configuration

ExaBGP announces label, PE enforces it (if configured for static labels).

Performance Considerations

  • Route Scale: ExaBGP handles 100,000+ VPN routes
  • VRF Scale: Limited by PE router, not ExaBGP
  • BGP Convergence: Typically 1-5 seconds for VPN route updates
  • Memory Usage: ~1KB per VPN route in ExaBGP

Best Practices:

  • Use Route Reflectors for large VPN deployments (avoid full mesh)
  • Aggregate routes where possible
  • Use RT filtering to limit route distribution
  • Monitor BGP session stability

Security Considerations

  • BGP Authentication: Use MD5 or TCP-AO for BGP sessions
  • Route Filtering: Import/Export policies on PE routers
  • Label Security: Ensure labels are not leaked between VPNs
  • Access Control: Restrict who can inject VPN routes via ExaBGP API

See Also

ExaBGP Documentation

Use Cases

Operations

Getting Started

References

RFCs and Standards

ExaBGP Resources

Vendor Documentation

  • Cisco L3VPN Configuration: MPLS VPN configuration guides for IOS, IOS-XE, IOS-XR
  • Juniper L3VPN: Junos VPN routing instances and route distinguishers
  • Nokia SR OS: VPRN (Virtual Private Routed Network) configuration

Books and Articles

  • MPLS and VPN Architectures (Ivan Pepelnjak, Jim Guichard) - Comprehensive L3VPN guide
  • MPLS Fundamentals (Luc De Ghein) - MPLS and L3VPN deep dive

Home

Getting Started

Configuration

API

Address Families

Features

Use Cases

Tools

Operations

Reference

Integration

Migration

Community

External

Clone this wiki locally