RT Constraint

Route Target Constraint (RT-Constraint)

Route Target Constraint (RT-Constraint) is a BGP address family (AFI 1, SAFI 132) defined in RFC 4684 that enables BGP speakers to signal which Route Targets (RTs) they are interested in receiving. This mechanism dramatically reduces unnecessary VPN route propagation in large-scale L3VPN and EVPN deployments, improving scalability and reducing memory consumption on PE routers and Route Reflectors.

ExaBGP provides full RT-Constraint (SAFI 132) support, enabling applications to programmatically announce and receive RT-Constraint routes for automated VPN route filtering, dynamic VPN provisioning, and optimized BGP Route Reflector deployments.

What is RT-Constraint?

RT-Constraint (Route Target Constraint) is a BGP mechanism that allows PE routers to tell Route Reflectors (RRs) which VPN routes they actually need, based on Route Targets (RTs). Instead of RRs sending all VPN routes to all PEs, RRs only send routes matching the RTs that each PE has advertised interest in.

The Problem RT-Constraint Solves

Without RT-Constraint:

Route Reflector has 10,000 VPN routes:
  - 100 VRFs × 100 routes each
  - All 10,000 routes sent to EVERY PE router

PE Router only needs 100 routes (1 VRF):
  - Receives 10,000 routes
  - Imports 100 routes (matching RT)
  - Discards 9,900 routes (no matching RT)
  - Wastes memory, CPU, bandwidth

With RT-Constraint:

PE Router announces RT-Constraint:
  "I only want routes with target:65001:100"

Route Reflector:
  - Receives RT-Constraint from PE
  - Filters VPN routes before sending
  - Only sends 100 routes to PE (matching RT)
  - PE receives exactly what it needs

Result: 99% reduction in VPN routes sent to PE

Why Use RT-Constraint?

Advantages of RT-Constraint

Without RT-Constraint (Traditional VPN):

❌ RR sends all VPN routes to all PEs (O(N×M) routes, N=PEs, M=VPN routes)
❌ High memory consumption on PEs (millions of unnecessary routes)
❌ Slow BGP convergence (processing unnecessary routes)
❌ Bandwidth waste (sending routes that will be discarded)

With RT-Constraint (RFC 4684):

✅ RR sends only needed VPN routes to each PE (O(M) routes per PE)
✅ Reduced memory consumption (70-90% reduction typical)
✅ Faster BGP convergence (fewer routes to process)
✅ Lower bandwidth usage
✅ Scalable to 10,000+ VRFs

Scalability Comparison

Scenario	Without RT-Constraint	With RT-Constraint
100 PEs, 100 VRFs, 100 routes/VRF	1M routes stored on RR	1M routes stored on RR
Routes sent to each PE	1M routes (99% discarded)	~10K routes (only needed RTs)
Memory per PE	High (1M routes)	Low (10K routes)
BGP convergence	Slow (process 1M routes)	Fast (process 10K routes)

Typical Savings: 70-95% reduction in routes sent to PEs.

ExaBGP RT-Constraint Capabilities

ExaBGP provides full RT-Constraint (AFI 1, SAFI 132) support:

Supported Features

✅ RT-Constraint NLRI (SAFI 132):

Announce Route Target filters (which RTs a PE wants to receive)
Receive RT-Constraint routes from BGP peers
Signal interest in specific VPN Route Targets

✅ Route Target Formats:

Type 0: 2-byte AS : 4-byte value (e.g., 65001:100)
Type 1: IPv4 address : 2-byte value (e.g., 192.0.2.1:100)
Type 2: 4-byte AS : 2-byte value (e.g., 4200000000:100)

✅ Integration with L3VPN and EVPN:

Works with VPNv4 (SAFI 128)
Works with VPNv6 (SAFI 129)
Works with EVPN (SAFI 70)
Automatic Route Reflector filtering

✅ Standard BGP Attributes:

AS-PATH, COMMUNITIES (for RT-Constraint routes themselves)
Standard BGP route processing

Implementation:

src/exabgp/protocol/family.py (SAFI.rtc definition)
Route Target Constraint NLRI encoding/decoding

RFC Support

RFC 4684: Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs) - Fully Implemented

How RT-Constraint Works

RT-Constraint Flow

[RT-Constraint Architecture]

Step 1: PE announces RT-Constraint
────────────────────────────────────

PE1 (has VRF with RT 65001:100):
  │
  │ BGP RT-Constraint (SAFI 132)
  │ "I want routes with target:65001:100"
  ▼
Route Reflector:
  - Stores RT-Constraint from PE1
  - Creates RT filter for PE1


Step 2: RR receives VPN routes
───────────────────────────────

PE2:
  │ BGP VPNv4 (SAFI 128)
  │ Route: 10.1.0.0/24
  │ RT: target:65001:100  ◄─── Matches PE1's RT-Constraint
  ▼
Route Reflector:
  - Checks RT-Constraint filters
  - PE1 wants target:65001:100 ✓
  - PE3 doesn't want target:65001:100 ✗


Step 3: RR forwards filtered routes
────────────────────────────────────

Route Reflector:
  │ Only sends to PE1 (matches RT-Constraint)
  ▼
PE1:
  - Receives 10.1.0.0/24 with RT 65001:100
  - Imports into VRF (RT matches)

PE3:
  - Does NOT receive route (no RT-Constraint match)
  - Saves memory, CPU, bandwidth

RT-Constraint Message Format

RT-Constraint Announcement:

NLRI: Route Target = target:65001:100
AFI: 1 (IPv4)
SAFI: 132 (RT-Constraint)
Meaning: "Send me VPN routes with RT target:65001:100"

VPN Route with RT Extended Community:

NLRI: 10.1.0.0/24
AFI: 1, SAFI: 128 (VPNv4)
Extended Community: target:65001:100
Result: Route Reflector checks if any PE has RT-Constraint for 65001:100

Key Concepts

Route Target (RT)

The Route Target extended community controls VPN route import/export.

Format: target:ASN:Value

Example:

VPN Route:
  Prefix: 10.1.0.0/24
  RD: 65001:100
  RT: target:65001:100  ◄─── This is what RT-Constraint filters on

RT-Constraint:
  "I want routes with target:65001:100"

Key Point: RT-Constraint operates on the Route Target extended community, not the Route Distinguisher (RD).

RT-Filter

RT-Filter is the set of Route Targets a PE router wants to receive.

Example:

PE1 has 3 VRFs:
  VRF-A: Import RT = target:65001:100
  VRF-B: Import RT = target:65001:200
  VRF-C: Import RT = target:65001:300

PE1 announces 3 RT-Constraint routes:
  1. target:65001:100
  2. target:65001:200
  3. target:65001:300

Route Reflector creates RT-Filter for PE1:
  [ 65001:100, 65001:200, 65001:300 ]

VPN Route received at RR:
  Prefix: 10.1.0.0/24
  RT: target:65001:100

RR checks RT-Filter:
  - Does PE1 want target:65001:100? YES ✓
  - Does PE2 want target:65001:100? NO ✗

Result: RR sends route only to PE1

Outbound Route Filtering (ORF)

RT-Constraint vs ORF:

Feature	RT-Constraint (RFC 4684)	ORF (RFC 5291)
Filtering Mechanism	Route Target-based	Prefix-based or community-based
Use Case	VPN route filtering	General BGP route filtering
Scalability	Very high (VPN-specific)	Moderate
Deployment	L3VPN, EVPN	Any BGP

RT-Constraint is specialized for VPNs; ORF is general-purpose BGP filtering.

RT-Constraint NLRI

RT-Constraint NLRI encodes the Route Target being requested.

Format:

Origin AS: 4 bytes (ASN of the originator)
Route Target: Variable length (Route Target value)

Example:

RT-Constraint NLRI:
  Origin AS: 65001
  Route Target: target:65001:100

Meaning: "AS 65001 wants to receive VPN routes with RT target:65001:100"

Why Origin AS?: Allows Route Reflectors to distinguish RT-Constraints from different ASes in inter-AS VPN scenarios.

Configuration Examples

Basic RT-Constraint Configuration

# /etc/exabgp/rt-constraint.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 RT-Constraint address family
    family {
        ipv4 rtc;         # RT-Constraint (SAFI 132)
        ipv4 vpn;         # VPNv4 (SAFI 128) - for receiving filtered routes
    }

    # API process for dynamic RT-Constraint announcements
    api {
        processes [ rt-constraint-controller ];
    }
}

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

RT-Constraint with Multiple VPN Families

# /etc/exabgp/rt-constraint-multi-family.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 RT-Constraint for multiple VPN families
    family {
        ipv4 rtc;         # RT-Constraint
        ipv4 vpn;         # VPNv4
        ipv6 vpn;         # VPNv6
        l2vpn evpn;       # EVPN
    }

    api {
        processes [ rt-controller ];
    }
}

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

API Examples

Announce RT-Constraint (Text API)

Basic RT-Constraint announcement:

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

import sys
import time

def announce_rt_constraint(route_target):
    """
    Announce RT-Constraint to signal interest in routes with specific RT.

    Args:
        route_target: Route Target in format "ASN:Value" (e.g., "65001:100")
    """
    print(f"announce rtc {route_target}")
    sys.stdout.flush()

def withdraw_rt_constraint(route_target):
    """Withdraw RT-Constraint (no longer interested in routes with this RT)"""
    print(f"withdraw rtc {route_target}")
    sys.stdout.flush()

# Announce RT-Constraint for VRF-A
announce_rt_constraint("65001:100")

# Announce RT-Constraint for VRF-B
announce_rt_constraint("65001:200")

# Announce RT-Constraint for VRF-C (IPv4 address format)
announce_rt_constraint("192.0.2.1:100")

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

Dynamic RT-Constraint Based on VRF Configuration

#!/usr/bin/env python3
# /etc/exabgp/dynamic-rt-constraint.py

import sys
import time
import json

def read_vrf_config(config_file="/etc/exabgp/vrfs.json"):
    """
    Read VRF configuration to determine which RTs to announce.

    vrfs.json format:
    {
      "vrf-a": {"import_rt": ["65001:100", "65001:999"]},
      "vrf-b": {"import_rt": ["65001:200"]},
      "vrf-c": {"import_rt": ["65001:300"]}
    }
    """
    try:
        with open(config_file, 'r') as f:
            return json.load(f)
    except:
        return {}

def announce_rt(rt):
    print(f"announce rtc {rt}")
    sys.stdout.flush()

def withdraw_rt(rt):
    print(f"withdraw rtc {rt}")
    sys.stdout.flush()

# Track announced RTs
announced_rts = set()

while True:
    # Read current VRF configuration
    vrfs = read_vrf_config()

    # Determine needed RTs
    needed_rts = set()
    for vrf_name, vrf_config in vrfs.items():
        for rt in vrf_config.get("import_rt", []):
            needed_rts.add(rt)

    # Announce new RTs
    for rt in needed_rts - announced_rts:
        announce_rt(rt)
        announced_rts.add(rt)
        print(f"# Announced RT-Constraint for {rt}", file=sys.stderr)

    # Withdraw removed RTs
    for rt in announced_rts - needed_rts:
        withdraw_rt(rt)
        announced_rts.remove(rt)
        print(f"# Withdrawn RT-Constraint for {rt}", file=sys.stderr)

    time.sleep(30)  # Check for VRF config changes every 30 seconds

Text API Format Examples

Announce RT-Constraint:

# Standard format (2-byte AS)
print("announce rtc 65001:100")
sys.stdout.flush()

# IPv4 address format
print("announce rtc 192.0.2.1:100")
sys.stdout.flush()

# 4-byte AS format
print("announce rtc 4200000000:100")
sys.stdout.flush()

Withdraw RT-Constraint:

print("withdraw rtc 65001:100")
sys.stdout.flush()

JSON API Format

Received RT-Constraint route (JSON format from ExaBGP):

{
  "exabgp": "5.0",
  "type": "update",
  "neighbor": {
    "address": {"local": "192.0.2.2", "peer": "192.0.2.1"},
    "message": {
      "update": {
        "announce": {
          "ipv4 rtc": {
            "65001:100": {
              "attributes": {
                "origin": "igp",
                "as-path": [65000]
              }
            }
          }
        }
      }
    }
  }
}

Interpretation: Peer 192.0.2.1 wants to receive VPN routes with Route Target target:65001:100.

Use Cases

1. Large-Scale Service Provider VPN

Scenario: Service provider with 10,000 customer VRFs across 500 PE routers.

Without RT-Constraint:

Route Reflector has 1,000,000 VPN routes (10,000 VRFs × 100 routes each)
RR sends all 1M routes to EVERY PE
Each PE only needs ~2,000 routes (20 VRFs × 100 routes)
99.8% of routes discarded by PEs

With RT-Constraint:

Each PE announces RT-Constraint for its 20 VRFs
RR filters and sends only ~2,000 routes to each PE
99.8% reduction in routes sent
Massive memory and CPU savings

ExaBGP Role:

PE announces RT-Constraint for each VRF's import RTs
Dynamic RT-Constraint updates when VRFs added/removed
Integration with VRF provisioning systems

2. Hub-and-Spoke VPN with Route Reflectors

Scenario: Enterprise hub-and-spoke VPN with 1,000 spoke sites.

Topology:

Hub PE (imports all spoke RTs):
  - RT-Constraint: target:65001:* (all spoke RTs)

Spoke PEs (only import hub RT):
  - RT-Constraint: target:65001:999 (hub RT only)

Route Reflector:
  - Sends all spoke routes to Hub PE
  - Sends only hub routes to Spoke PEs

Benefit: Spoke PEs don't receive routes from other spokes (unnecessary traffic).

ExaBGP Role:

Spoke PEs announce single RT-Constraint (hub RT)
Hub PE announces multiple RT-Constraints (all spoke RTs)
Automated provisioning when new spokes added

3. Multi-Tenant Data Center

Scenario: Cloud provider with 5,000 tenants, each with dedicated L3VPN.

Without RT-Constraint:

Each PE receives routes for ALL 5,000 tenants
PE hosts only 100 tenants but stores 5,000 tenants' routes
Wasted memory on 4,900 unused tenants

With RT-Constraint:

PE announces RT-Constraint for its 100 tenants only
RR sends routes for 100 tenants only
98% memory reduction

ExaBGP Role:

Dynamic RT-Constraint based on tenant placement
Integration with cloud orchestration (OpenStack, Kubernetes)
Automatic RT-Constraint updates during tenant migration

4. Inter-AS VPN with Selective Route Exchange

Scenario: Two service providers (AS 65001 and AS 65002) exchanging VPN routes for specific customers only.

RT-Constraint Usage:

AS 65001 announces RT-Constraint to AS 65002:
  - target:65002:100 (Customer A)
  - target:65002:200 (Customer B)

AS 65002 only sends VPN routes matching these RTs to AS 65001.

Result: AS 65001 doesn't receive routes for AS 65002's other 1,000 customers.

ExaBGP Role:

Border PE announces RT-Constraint for inter-AS customers
Policy-based RT-Constraint filtering
Security: Only authorized RTs exchanged

5. EVPN with RT-Constraint

Scenario: Data center EVPN deployment with 1,000 VNIs.

Without RT-Constraint:

Route Reflector has 100,000 EVPN routes (1,000 VNIs × 100 MACs each)
All EVPN routes sent to every VTEP
Each VTEP only needs routes for 10 VNIs

With RT-Constraint:

VTEP announces RT-Constraint for its 10 VNIs
RR sends only routes for 10 VNIs
99% reduction in EVPN routes sent

ExaBGP Role:

VTEP announces RT-Constraint per VNI
Integration with VXLAN orchestration
Dynamic RT-Constraint as VMs migrate

Common Errors and Solutions

Error: "RT-Constraint family not enabled"

Cause: BGP session doesn't have ipv4 rtc family configured.

Solution: Enable RT-Constraint family on both PE and RR.

ExaBGP (PE):

neighbor 192.0.2.1 {  # Route Reflector
    family {
        ipv4 rtc;  # RT-Constraint
        ipv4 vpn;  # VPNv4
    }
}

Cisco IOS-XR (Route Reflector):

router bgp 65000
 address-family ipv4 rtfilter unicast  ← RT-Constraint (rtfilter = rtc)
 !
 neighbor 192.0.2.2
  address-family ipv4 rtfilter unicast
  !
  address-family vpnv4 unicast
  !
 !
!

Juniper Junos (Route Reflector):

protocols {
    bgp {
        group pe-routers {
            family inet-vpn {
                unicast;
            }
            family route-target {  ← RT-Constraint
            }
        }
    }
}

Error: "Still receiving all VPN routes despite RT-Constraint"

Cause: Route Reflector not filtering based on RT-Constraint.

Solution: Verify RR has RT-Constraint enabled and is applying filters.

Cisco IOS-XR - Verify RT-Constraint:

# Check RT-Constraint routes received
show bgp ipv4 rtfilter unicast

# Check if RR is filtering VPN routes
show bgp vpnv4 unicast neighbor 192.0.2.2 advertised-routes

Common Issue: RR configured with next-hop-self or other policies that override RT-Constraint filtering.

Error: "RT-Constraint route not accepted"

Cause: Invalid Route Target format.

Solution: Use correct Route Target format.

# Valid formats
print("announce rtc 65001:100")        # 2-byte AS
print("announce rtc 192.0.2.1:100")    # IPv4 address
print("announce rtc 4200000000:100")   # 4-byte AS

# Invalid formats
print("announce rtc target:65001:100") # Don't include "target:" prefix
print("announce rtc 65001")            # Missing value portion

Error: "PE not receiving needed VPN routes"

Cause: RT-Constraint not announced for required Route Targets.

Solution: Ensure RT-Constraint matches VRF import RTs.

Example:

VRF-A configuration:
  Import RT: target:65001:100
  Import RT: target:65001:999  ← Also imports shared services RT

RT-Constraint announcements needed:
  announce rtc 65001:100  ← For VRF-A routes
  announce rtc 65001:999  ← For shared services routes

Verify:

# List all import RTs from VRFs
vrfs = {
    "vrf-a": ["65001:100", "65001:999"],
    "vrf-b": ["65001:200", "65001:999"]
}

# Announce RT-Constraint for each unique RT
unique_rts = set()
for vrf_rts in vrfs.values():
    unique_rts.update(vrf_rts)

for rt in unique_rts:
    print(f"announce rtc {rt}")

Error: "RT-Constraint working but VPN routes delayed"

Cause: RT-Constraint convergence delay (RR needs to receive RT-Constraint before filtering).

Solution: This is normal behavior. RT-Constraint should be announced BEFORE VPN routes.

Best Practice:

PE announces RT-Constraint (e.g., "I want 65001:100")
Wait for RT-Constraint to propagate to RR
RR receives VPN routes and applies RT-Constraint filter
RR sends filtered VPN routes to PE

Timing: Typically 1-2 seconds for RT-Constraint propagation.

Important Considerations

ExaBGP Does Not Manipulate RIB/FIB

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

Filter VPN routes locally (RT-Constraint signals to RR to filter)
Install VPN routes in VRFs
Create VRFs
Program MPLS forwarding

What ExaBGP DOES:

✅ Send RT-Constraint routes to Route Reflectors (SAFI 132)
✅ Receive filtered VPN routes from Route Reflectors
✅ Provide API for applications to control RT-Constraints
✅ Handle BGP session management

RT-Constraint Flow:

[ExaBGP] ─── RT-Constraint ───→ [Route Reflector]
                                       │
                                       ├─ Stores RT-Constraint
                                       ├─ Filters VPN routes
                                       └─ Sends filtered routes

[ExaBGP] ◄── Filtered VPN routes ──┘

External Infrastructure Required:

Route Reflector: Must support RT-Constraint (SAFI 132)
PE Routers: Must have VRFs configured to import received VPN routes
MPLS: For VPN traffic forwarding

Route Reflector Requirements

Not all Route Reflectors support RT-Constraint. Verify support:

Supported Route Reflectors:

Cisco IOS-XR (all versions)
Juniper Junos (all versions)
Nokia SR OS
Arista EOS
Huawei VRP
GoBGP (open-source)

Configuration Required: Route Reflector must have RT-Constraint enabled (see configuration examples).

RT-Constraint Deployment Strategies

Big Bang:

Enable RT-Constraint on all PEs and RRs simultaneously
Requires maintenance window
Immediate benefits

Gradual Rollout (Recommended):

Enable RT-Constraint on Route Reflectors first
Enable RT-Constraint on PEs gradually
Mixed environment supported (PEs without RT-Constraint receive all routes as before)

No Disruption: Enabling RT-Constraint does not disrupt existing VPN services.

Performance Considerations

Benefits:

Memory Reduction: 70-95% reduction in VPN routes stored on PEs
CPU Reduction: Less route processing on PEs
Bandwidth Savings: Fewer routes transmitted from RR to PEs
Faster Convergence: Fewer routes to process during BGP updates

Costs:

RT-Constraint Overhead: Minimal (1 RT-Constraint route per import RT)
RR Filtering Overhead: Moderate (RR must check RTs before sending routes)

Typical RT-Constraint Overhead:

1,000 PEs × 20 VRFs × 2 import RTs = 40,000 RT-Constraint routes
VPN routes saved: 1,000 PEs × 1M routes = 1B routes (without RT-Constraint)
                  1,000 PEs × 2K routes = 2M routes (with RT-Constraint)
Savings: 99.8% reduction in routes sent to PEs

Security Considerations

RT-Constraint Security:

BGP Authentication: Use MD5 or TCP-AO for BGP sessions
RT Filtering: Ensure RR only accepts valid RT-Constraints from authorized PEs
Route Leaking Prevention: RT-Constraint prevents accidental route leaks (PE can't receive routes for RTs it doesn't request)

Best Practice: Use BGP policies on RR to validate RT-Constraint announcements.

References

RFCs and Standards

RFC 4684: Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)
- RT-Constraint specification (SAFI 132)
- Route Target NLRI encoding
- Route Reflector filtering behavior
- https://datatracker.ietf.org/doc/html/rfc4684
RFC 4364: BGP/MPLS IP Virtual Private Networks (VPNs)
- L3VPN specification with Route Targets
- Context for RT-Constraint usage
- https://datatracker.ietf.org/doc/html/rfc4364
RFC 4360: BGP Extended Communities Attribute
- Route Target extended community format
- https://datatracker.ietf.org/doc/html/rfc4360
RFC 4760: Multiprotocol Extensions for BGP-4
- SAFI 132 definition
- https://datatracker.ietf.org/doc/html/rfc4760

ExaBGP Resources

ExaBGP GitHub: https://github.com/Exa-Networks/exabgp
RFC Implementation: RFC-Information.md
Source Code: src/exabgp/protocol/family.py (SAFI.rtc definition)

Vendor Documentation

Cisco RT-Constraint Configuration: IOS-XR rtfilter configuration
Juniper RT-Constraint: Junos route-target filtering
Nokia SR OS: RT-Constraint for VPRN

Books and Articles

MPLS and VPN Architectures (Ivan Pepelnjak, Jim Guichard) - RT-Constraint chapter
MPLS Fundamentals (Luc De Ghein) - VPN route filtering

Performance Studies

RT-Constraint Deployment Case Studies: Service provider experiences with RT-Constraint showing 70-95% memory reduction on PE routers

👻 Ghost written by Claude (Anthropic AI)

🏠 Home

🚀 Getting Started

🔧 API

🛡️ Use Cases

🌐 Address Families

FlowSpec
- Match Conditions
- Actions Reference

⚙️ Configuration

🔍 Operations

📚 Reference

🔄 Migration

🌍 Community

🔗 External

GitHub Repo ↗
Slack ↗
Issues ↗

👻 Ghost written by Claude (Anthropic AI)

RT Constraint

Route Target Constraint (RT-Constraint)

Table of Contents

What is RT-Constraint?

The Problem RT-Constraint Solves

Why Use RT-Constraint?

Advantages of RT-Constraint

Scalability Comparison

ExaBGP RT-Constraint Capabilities

Supported Features

RFC Support

How RT-Constraint Works

RT-Constraint Flow

RT-Constraint Message Format

Key Concepts

Route Target (RT)

RT-Filter

Outbound Route Filtering (ORF)

RT-Constraint NLRI

Configuration Examples

Basic RT-Constraint Configuration

RT-Constraint with Multiple VPN Families

API Examples

Announce RT-Constraint (Text API)

Dynamic RT-Constraint Based on VRF Configuration

Text API Format Examples

JSON API Format

Use Cases

1. Large-Scale Service Provider VPN

2. Hub-and-Spoke VPN with Route Reflectors

3. Multi-Tenant Data Center

4. Inter-AS VPN with Selective Route Exchange

5. EVPN with RT-Constraint

Common Errors and Solutions

Error: "RT-Constraint family not enabled"

Error: "Still receiving all VPN routes despite RT-Constraint"

Error: "RT-Constraint route not accepted"

Error: "PE not receiving needed VPN routes"

Error: "RT-Constraint working but VPN routes delayed"

Important Considerations

ExaBGP Does Not Manipulate RIB/FIB

Route Reflector Requirements

RT-Constraint Deployment Strategies

Performance Considerations

Security Considerations

See Also

ExaBGP Documentation

Use Cases

Operations

Getting Started

References

RFCs and Standards

ExaBGP Resources

Vendor Documentation

Books and Articles

Performance Studies

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!