Skip to content

Overview

Thomas Mangin edited this page Nov 10, 2025 · 2 revisions

BGP-LS (BGP Link-State) Overview

BGP-LS (BGP Link-State) is a BGP extension that enables the distribution of IGP (Interior Gateway Protocol) topology information, including link-state data and Traffic Engineering (TE) attributes, via BGP. Defined in RFC 7752, BGP-LS provides a northbound interface for network controllers, path computation engines, and monitoring systems to gain visibility into the network topology without requiring direct access to IGP protocols.

ExaBGP provides receive-only BGP-LS support, making it ideal for collecting topology information from routers and feeding it to SDN controllers, path computation elements (PCE), or network monitoring tools.

Table of Contents


What is BGP-LS?

BGP-LS (BGP Link-State) extends BGP to carry IGP topology and Traffic Engineering information, enabling centralized visibility into the network's link-state database.

How BGP-LS Works

Traditional IGP protocols (OSPF, IS-IS) distribute topology information within a single routing domain. BGP-LS allows this information to be exported from the IGP and distributed via BGP to external systems.

[Network Topology Collection]

    β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
    β”‚     SDN Controller / PCE / Monitoring       β”‚
    β”‚        (ExaBGP receives BGP-LS data)        β”‚
    β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
                      β”‚ BGP-LS Session
                      β–Ό
              β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
              β”‚ Route Reflectorβ”‚
              β”‚  (BGP-LS RR)   β”‚
              β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
                 β”‚         β”‚
        ─────────┴─────────┴─────────
        β”‚                   β”‚
        β–Ό                   β–Ό
    β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”          β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”
    β”‚Router 1β”‚          β”‚Router 2β”‚
    β”‚ (OSPF) │◄────────►│ (OSPF) β”‚
    β””β”€β”€β”€β”€β”€β”€β”€β”€β”˜  IGP Linkβ””β”€β”€β”€β”€β”€β”€β”€β”€β”˜
        β”‚                   β”‚
    [Exports]           [Exports]
    BGP-LS NLRI         BGP-LS NLRI

Process:

  1. IGP Operation: Routers run OSPF or IS-IS, building link-state database (LSDB)
  2. BGP-LS Export: Routers export LSDB information as BGP-LS NLRIs
  3. BGP Distribution: Route Reflector distributes BGP-LS to controllers
  4. ExaBGP Reception: ExaBGP receives and decodes BGP-LS data
  5. Application Processing: External process analyzes topology for path computation, monitoring, etc.

What Information Does BGP-LS Carry?

BGP-LS distributes three main types of information:

  1. Node Information: Routers in the network (router IDs, capabilities, flags)
  2. Link Information: Connections between routers (bandwidth, TE metrics, SRLG)
  3. Prefix Information: IP prefixes advertised by nodes (IGP metrics, flags)

Why Use BGP-LS?

Advantages Over Direct IGP Access

Feature BGP-LS Direct IGP Access
Protocol Independence Single BGP session Multiple IGP protocols
Scalability BGP scalability IGP limitations
Security BGP authentication IGP domain access required
Multi-Domain Across AS boundaries Single IGP domain
Abstraction Northbound API Raw IGP data

Common Use Cases

  1. SDN Controllers: Topology discovery for centralized path computation
  2. Traffic Engineering: MPLS-TE and Segment Routing path calculation
  3. Network Monitoring: Real-time topology visualization and alerting
  4. PCE (Path Computation Element): Offline CSPF (Constrained Shortest Path First)
  5. Multi-Domain TE: Traffic engineering across multiple IGP domains
  6. Network Analytics: Topology analysis, capacity planning, SRG identification

ExaBGP BGP-LS Capabilities

ExaBGP provides receive-only BGP-LS support per RFC 7752:

Supported Features

βœ… All 4 NLRI Types:

  • Node NLRI (Type 1): Router/node information
  • Link NLRI (Type 2): Link/adjacency information
  • IPv4 Prefix NLRI (Type 3): IPv4 prefix topology
  • IPv6 Prefix NLRI (Type 4): IPv6 prefix topology

βœ… IGP Protocol Support:

  • OSPF (OSPFv2 and OSPFv3)
  • IS-IS (Level 1 and Level 2)
  • Multi-topology IGP

βœ… Traffic Engineering Attributes:

  • Administrative groups (color)
  • Maximum link bandwidth
  • Maximum reservable bandwidth
  • Unreserved bandwidth (8 priority levels)
  • TE metric
  • IGP metric
  • Shared Risk Link Groups (SRLG)
  • Link protection type

βœ… Segment Routing Extensions:

  • SR Capabilities (Node SID range)
  • Adjacency SIDs (Adj-SID)
  • Prefix SIDs (Prefix-SID)
  • SRv6 SID Information (RFC 9514)

βœ… Node Attributes:

  • Node flags (ABR, ASBR, overload)
  • Node name
  • IS-IS area identifier
  • Local TE router ID

Current Limitations

⚠️ Receive-Only: ExaBGP can receive and decode BGP-LS but cannot originate/encode BGP-LS NLRIs.

What This Means:

  • βœ… Use ExaBGP to collect topology from routers
  • ❌ Cannot use ExaBGP to inject topology information
  • βœ… Perfect for SDN controllers, monitoring, PCE
  • ❌ Not suitable for IGP emulation

Implementation: src/exabgp/bgp/message/update/nlri/bgpls/ (ExaBGP source)

RFC Support

  • RFC 7752: North-Bound Distribution of Link-State and TE Information Using BGP (fully implemented for receive)
  • RFC 9514: BGP-LS Extensions for SRv6 (fully implemented for receive)
  • Related: RFC 2328 (OSPF), RFC 5120 (IS-IS MT), RFC 5305 (IS-IS TE), RFC 7794 (IS-IS Prefix Attributes)

BGP-LS NLRI Types

BGP-LS defines 4 NLRI (Network Layer Reachability Information) types to represent different topology elements.

Node NLRI (Type 1)

Purpose: Represents a router or node in the IGP topology.

Key Information:

  • Node Descriptors: Autonomous System, BGP-LS Identifier, IGP Router ID, Area ID
  • Node Attributes: Node flags, node name, local TE router ID, SR capabilities

Example Use Case: Discover all routers in the network with their capabilities.

JSON Output Example:

{
  "ls-nlri-type": 1,
  "l3-routing-topology": 0,
  "protocol-id": 2,
  "node-descriptors": {
    "autonomous-system": 65000,
    "router-id": "172000160088"
  },
  "nexthop": "192.0.2.52"
}

Node Attributes (in attribute.bgp-ls):

"bgp-ls": {
  "node-flags": {
    "O": 0,  // Overload
    "T": 0,  // Attached
    "B": 0,  // ABR (Area Border Router)
    "E": 0   // External (ASBR)
  },
  "area-id": "490002",
  "local-te-router-id": "192.0.2.88",
  "node-name": "router-1.example.com"
}

Link NLRI (Type 2)

Purpose: Represents a link (adjacency) between two routers.

Key Information:

  • Local Node Descriptors: Source router identification
  • Remote Node Descriptors: Destination router identification
  • Link Descriptors: Interface/neighbor addresses, link identifiers
  • Link Attributes: Bandwidth, TE metrics, SRLG, admin groups

Example Use Case: Build a graph of network connections with TE attributes for path computation.

JSON Output Example:

{
  "ls-nlri-type": 2,
  "l3-routing-topology": 0,
  "protocol-id": 2,
  "local-node-descriptors": {
    "autonomous-system": 65000,
    "router-id": "172000160002"
  },
  "remote-node-descriptors": {
    "autonomous-system": 65000,
    "router-id": "172000160001"
  },
  "interface-address": {
    "interface-address": "192.0.2.25"
  },
  "neighbor-address": {
    "neighbor-address": "192.0.2.24"
  }
}

Link Attributes (in attribute.bgp-ls):

"bgp-ls": {
  "admin-group-mask": [0],
  "maximum-link-bandwidth": 125000000.0,
  "maximum-reservable-link-bandwidth": 125000000.0,
  "unreserved-bandwidth": [
    125000000.0, 125000000.0, 125000000.0, 125000000.0,
    125000000.0, 125000000.0, 125000000.0, 125000000.0
  ],
  "te-metric": 10,
  "igp-metric": 10,
  "link-name": "to-router-2"
}

IPv4 Prefix NLRI (Type 3)

Purpose: Represents an IPv4 prefix advertised by a node in the IGP.

Key Information:

  • Node Descriptors: Node advertising the prefix
  • IP Reachability TLV: The IPv4 prefix
  • Prefix Attributes: IGP metric, flags, tags, OSPF forwarding address

Example Use Case: Track which router advertises which prefix with associated metrics.

JSON Output Example:

{
  "ls-nlri-type": 3,
  "l3-routing-topology": 0,
  "protocol-id": 2,
  "node-descriptors": {
    "autonomous-system": 65000,
    "router-id": "100000000004"
  },
  "ip-reachability-tlv": "192.0.2.100/32",
  "nexthop": "192.0.2.1"
}

Prefix Attributes:

"bgp-ls": {
  "igp-flags": {
    "D": 0,  // Down
    "N": 0,  // No-unicast
    "L": 0,  // Local
    "P": 0   // Propagate
  },
  "prefix-metric": 10,
  "route-tag": [100]
}

IPv6 Prefix NLRI (Type 4)

Purpose: Represents an IPv6 prefix advertised by a node in the IGP.

Key Information: Same as IPv4 Prefix NLRI but for IPv6 prefixes.


Key Concepts

Protocol ID

Identifies the source IGP protocol:

Protocol ID IGP Protocol
1 IS-IS Level 1
2 IS-IS Level 2
3 OSPFv2
4 Direct
5 Static
6 OSPFv3

Node Descriptors

Uniquely identify a router in the topology:

  • Autonomous System: AS number
  • BGP-LS Identifier: Unique BGP-LS instance ID
  • IGP Router ID: OSPF Router ID or IS-IS System ID
  • Area ID: OSPF area or IS-IS area

Link Descriptors

Uniquely identify a link between routers:

  • Interface Address: Local interface IP
  • Neighbor Address: Remote interface IP
  • Link Local/Remote Identifiers: OSPF/IS-IS link IDs
  • Multi-Topology ID: For multi-topology IGP

Traffic Engineering Attributes

Admin Group (Color): 32-bit bitmask for administrative link groups (e.g., "gold", "silver", "bronze").

Maximum Link Bandwidth: Physical link capacity in bytes/second.

Maximum Reservable Bandwidth: Maximum bandwidth available for reservation.

Unreserved Bandwidth: Available bandwidth at 8 priority levels (0-7).

TE Metric: Traffic Engineering metric (may differ from IGP metric).

IGP Metric: Standard IGP routing metric.

SRLG (Shared Risk Link Group): Links sharing common failure risks (same conduit, router, etc.).

Segment Routing Attributes

SR Capabilities: Segment Routing Global Block (SRGB) range for the node.

Adjacency SID (Adj-SID): Segment ID for a specific link adjacency.

Prefix SID: Segment ID for a node's loopback prefix.

SRv6 SID: IPv6 Segment Routing SID information (RFC 9514).


Configuration Examples

Basic BGP-LS Receiver Configuration

# /etc/exabgp/bgp-ls.conf

# Process to handle received BGP-LS data
process topology-collector {
    run python3 /etc/exabgp/bgp-ls-receiver.py;
    encoder json;
}

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

    # Enable BGP-LS address family
    family {
        ipv4 link-state;
        ipv6 link-state;
    }

    # API configuration for receiving BGP-LS
    api {
        processes [ topology-collector ];
        receive {
            parsed;
            update;
        }
    }
}

BGP-LS Receiver Script

#!/usr/bin/env python3
# /etc/exabgp/bgp-ls-receiver.py

import sys
import json

def handle_node(nlri, attributes):
    """Process Node NLRI"""
    node_desc = nlri.get('node-descriptors', {})
    router_id = node_desc.get('router-id', 'unknown')
    bgp_ls_attrs = attributes.get('bgp-ls', {})

    print(f"[NODE] Router ID: {router_id}", file=sys.stderr)
    print(f"       Node Name: {bgp_ls_attrs.get('node-name', 'N/A')}",
          file=sys.stderr)
    print(f"       Area: {bgp_ls_attrs.get('area-id', 'N/A')}",
          file=sys.stderr)

def handle_link(nlri, attributes):
    """Process Link NLRI"""
    local_node = nlri.get('local-node-descriptors', {})
    remote_node = nlri.get('remote-node-descriptors', {})
    local_rid = local_node.get('router-id', 'unknown')
    remote_rid = remote_node.get('router-id', 'unknown')

    bgp_ls_attrs = attributes.get('bgp-ls', {})

    print(f"[LINK] {local_rid} <-> {remote_rid}", file=sys.stderr)
    print(f"       IGP Metric: {bgp_ls_attrs.get('igp-metric', 'N/A')}",
          file=sys.stderr)
    print(f"       TE Metric: {bgp_ls_attrs.get('te-metric', 'N/A')}",
          file=sys.stderr)
    print(f"       Max BW: {bgp_ls_attrs.get('maximum-link-bandwidth', 'N/A')}",
          file=sys.stderr)

def handle_prefix(nlri, attributes):
    """Process Prefix NLRI"""
    node_desc = nlri.get('node-descriptors', {})
    router_id = node_desc.get('router-id', 'unknown')
    prefix = nlri.get('ip-reachability-tlv', 'unknown')

    bgp_ls_attrs = attributes.get('bgp-ls', {})
    metric = bgp_ls_attrs.get('prefix-metric', 'N/A')

    print(f"[PREFIX] {prefix} from {router_id} (metric: {metric})",
          file=sys.stderr)

def main():
    while True:
        line = sys.stdin.readline()
        if not line:
            break

        try:
            msg = json.loads(line)

            if msg.get('type') != 'update':
                continue

            update = msg.get('neighbor', {}).get('message', {}).get('update', {})
            announce = update.get('announce', {})

            # Process BGP-LS announcements
            for family, routes in announce.items():
                if 'bgpls' not in family and 'link-state' not in family:
                    continue

                for nexthop, nlri_list in routes.items():
                    for nlri in nlri_list:
                        nlri_type = nlri.get('ls-nlri-type')
                        attributes = msg['neighbor']['message']['update'].get('attribute', {})

                        if nlri_type == 1:
                            handle_node(nlri, attributes)
                        elif nlri_type == 2:
                            handle_link(nlri, attributes)
                        elif nlri_type in [3, 4]:
                            handle_prefix(nlri, attributes)

        except json.JSONDecodeError as e:
            print(f"JSON parse error: {e}", file=sys.stderr)
        except Exception as e:
            print(f"Error: {e}", file=sys.stderr)

if __name__ == '__main__':
    main()

JSON Output Examples

Node NLRI Example

{
  "exabgp": "5.0",
  "type": "update",
  "neighbor": {
    "address": {
      "local": "192.0.2.5",
      "peer": "192.0.2.79"
    },
    "message": {
      "update": {
        "attribute": {
          "origin": "igp",
          "bgp-ls": {
            "node-flags": {
              "B": 0,
              "E": 0,
              "T": 0,
              "O": 0
            },
            "area-id": "490002",
            "local-te-router-id": "192.0.2.88",
            "sr-capability-flags": {
              "I": 1,
              "V": 0
            },
            "sids": [[501, 1000000]]
          }
        },
        "announce": {
          "bgpls bgp-ls": {
            "192.0.2.52": [
              {
                "ls-nlri-type": 1,
                "l3-routing-topology": 0,
                "protocol-id": 2,
                "node-descriptors": {
                  "autonomous-system": 65000,
                  "router-id": "172000160088"
                },
                "nexthop": "192.0.2.52"
              }
            ]
          }
        }
      }
    }
  }
}

Link NLRI Example

{
  "exabgp": "5.0",
  "type": "update",
  "neighbor": {
    "message": {
      "update": {
        "attribute": {
          "bgp-ls": {
            "admin-group-mask": [0],
            "maximum-link-bandwidth": 125000000.0,
            "maximum-reservable-link-bandwidth": 125000000.0,
            "unreserved-bandwidth": [
              125000000.0, 125000000.0, 125000000.0, 125000000.0,
              125000000.0, 125000000.0, 125000000.0, 125000000.0
            ],
            "te-metric": 10,
            "igp-metric": 10
          }
        },
        "announce": {
          "bgpls bgp-ls": {
            "192.0.2.52": [
              {
                "ls-nlri-type": 2,
                "l3-routing-topology": 0,
                "protocol-id": 2,
                "local-node-descriptors": {
                  "autonomous-system": 65000,
                  "router-id": "172000160002"
                },
                "remote-node-descriptors": {
                  "autonomous-system": 65000,
                  "router-id": "172000160001"
                },
                "interface-address": {
                  "interface-address": "192.0.2.25"
                },
                "neighbor-address": {
                  "neighbor-address": "192.0.2.24"
                }
              }
            ]
          }
        }
      }
    }
  }
}

Prefix NLRI Example

{
  "exabgp": "5.0",
  "type": "update",
  "neighbor": {
    "message": {
      "update": {
        "attribute": {
          "bgp-ls": {
            "sr-prefix-flags": {
              "N": 1,
              "P": 0,
              "E": 0,
              "V": 0,
              "L": 0
            },
            "sids": [200],
            "sr-algorithm": 0
          }
        },
        "announce": {
          "bgpls bgp-ls": {
            "192.0.2.1": [
              {
                "ls-nlri-type": 3,
                "l3-routing-topology": 0,
                "protocol-id": 2,
                "node-descriptors": {
                  "autonomous-system": 65000,
                  "router-id": "100000000004"
                },
                "ip-reachability-tlv": "192.0.2.100/32",
                "nexthop": "192.0.2.1"
              }
            ]
          }
        }
      }
    }
  }
}

Use Cases

1. SDN Controller Topology Discovery

Scenario: SDN controller needs complete network topology for centralized path computation.

How ExaBGP Helps:

  • Receives BGP-LS from all routers
  • Builds complete topology graph (nodes + links)
  • Feeds topology to SDN controller logic
  • Reacts to topology changes in real-time

Architecture:

[Router 1] ──┐
[Router 2] ─── BGP-LS
[Router 3] ──────────→ [ExaBGP] ──JSON──→ [SDN Controller]
[Router 4] ───                               β”‚
[Router 5] β”€β”€β”˜                               β”œβ”€β†’ Path Computation
                                             β”œβ”€β†’ Traffic Engineering
                                             └─→ Network Optimization

Example SDN Platforms:

  • OpenDaylight (ODL) with BGP-LS plugin
  • Cisco NSO (Network Services Orchestrator)
  • Custom Python-based SDN controllers

2. MPLS Traffic Engineering (TE)

Scenario: Compute optimal MPLS-TE LSP paths based on TE constraints.

How ExaBGP Helps:

  • Collects TE attributes (bandwidth, admin groups, SRLG)
  • Provides data for offline CSPF computation
  • Enables constraint-based path selection
  • Supports multi-domain TE

Constraints Supported:

  • Bandwidth requirements
  • Admin group inclusion/exclusion
  • TE metric optimization
  • SRLG diversity

3. Segment Routing Path Computation

Scenario: Calculate SR-TE policies with Segment Routing SIDs.

How ExaBGP Helps:

  • Receives SR capabilities (SRGB ranges)
  • Collects Prefix-SIDs for each node
  • Obtains Adj-SIDs for each link
  • Enables SR path computation with SID lists

SR-TE Path Example:

Goal: Traffic from A to D avoiding link B-C

Topology:
  A(SID:100) ── B(SID:200) ── C(SID:300) ── D(SID:400)
                     \                 /
                      ─── E(SID:500) ──

Computed SID List: [500, 400]
(Force via E, then to D)

4. Network Monitoring and Visualization

Scenario: Real-time network topology map with link utilization.

How ExaBGP Helps:

  • Receives topology updates via BGP-LS
  • Tracks link additions/removals
  • Monitors TE metric changes
  • Feeds visualization tools (Grafana, custom dashboards)

Visualization Data:

  • Network graph with nodes and links
  • Link bandwidth utilization
  • TE metrics and IGP metrics
  • Node capabilities and flags

5. Multi-Domain Traffic Engineering

Scenario: TE across multiple IGP domains or AS boundaries.

How ExaBGP Helps:

  • Collects BGP-LS from multiple domains
  • Aggregates topology information
  • Enables inter-domain path computation
  • Supports hierarchical PCE architectures

6. Capacity Planning and Analytics

Scenario: Analyze network topology for capacity planning.

How ExaBGP Helps:

  • Historical topology data collection
  • Link capacity analysis
  • SRLG identification for failure planning
  • Network growth modeling

Analytics Examples:

  • Identify bottleneck links
  • Calculate redundancy levels
  • Plan for link upgrades
  • Simulate failure scenarios

Segment Routing Support

ExaBGP supports Segment Routing (SR) extensions for BGP-LS, enabling SR-aware applications.

SR Capabilities (Node NLRI)

TLV 1034: SR Capabilities

  • SRGB (SR Global Block): SID range for the node
  • Flags: I (IPv4), V (IPv6)

Example:

"sr-capability-flags": {
  "I": 1,  // IPv4 SR enabled
  "V": 0   // IPv6 SR disabled
},
"sids": [[16000, 23999]]  // SRGB: 16000-23999

Adjacency SID (Link NLRI)

TLV 1099: Adj-SID

  • SID Value: Segment ID for the adjacency
  • Flags: B (Backup), V (Value), L (Local), S (Set), P (Persistent)
  • Weight: For load balancing across parallel adjacencies

Example:

"sr-adj-flags": {
  "V": 1,  // Value flag set
  "L": 1,  // Local significance
  "B": 0   // Not a backup path
},
"sids": [24001],
"sr-adj-weight": 0

Prefix SID (Prefix NLRI)

TLV 1158: Prefix-SID

  • SID Value: Segment ID for the prefix
  • Flags: N (Node-SID), P (No-PHP), E (Explicit-Null), V (Value), L (Local)
  • Algorithm: SR algorithm (default: 0)

Example:

"sr-prefix-flags": {
  "N": 1,  // Node-SID (loopback)
  "P": 0,  // PHP enabled
  "E": 0,  // No explicit-null
  "V": 0,
  "L": 0
},
"sids": [16001],
"sr-algorithm": 0

SRv6 Support (RFC 9514)

ExaBGP fully supports SRv6 extensions for BGP-LS:

  • SRv6 SID Information TLV
  • SRv6 Capabilities TLV
  • SRv6 End.X SID TLV
  • SRv6 Locator TLV

Implementation: src/exabgp/bgp/message/update/attribute/bgpls/link/srv6*.py


Router Configuration

Cisco IOS-XR

router isis core
 address-family ipv4 unicast
  mpls traffic-eng level-2
 !
 address-family ipv6 unicast
  mpls traffic-eng level-2
 !
!

router bgp 65000
 neighbor 192.0.2.2 remote-as 65001
 !
 address-family link-state link-state
  neighbor 192.0.2.2 activate
 !
!

Verification:

# Check BGP-LS routes
show bgp link-state link-state

# Check if routes are advertised to ExaBGP
show bgp link-state link-state neighbors 192.0.2.2 advertised-routes

Juniper Junos

protocols {
    bgp {
        group exabgp {
            type external;
            peer-as 65001;
            neighbor 192.0.2.2 {
                family traffic-engineering {
                    unicast;
                }
            }
        }
    }
    isis {
        traffic-engineering {
            family inet {
                shortcuts;
            }
            credibility-protocol-preference;
        }
        level 2 {
            wide-metrics-only;
        }
    }
}

routing-options {
    resolution {
        rib inet.3 {
            resolution-ribs inet.0;
        }
    }
}

Verification:

# Check link-state routes
show route table lsdist.0

# Check BGP-LS advertisements
show route advertising-protocol bgp 192.0.2.2 | match "NODE|LINK|PREFIX"

Common Errors and Solutions

Error: "BGP-LS address family not enabled"

Cause: Peer router not configured to advertise BGP-LS.

Solution: Enable BGP-LS on the router (see router configuration above).

Error: "No BGP-LS data received"

Cause: Router not exporting IGP data to BGP-LS.

Solution: Verify IGP has TE extensions enabled and is exporting to BGP.

Cisco Verification:

show isis database detail
# Look for TE TLVs

show bgp link-state link-state
# Should show NODE, LINK, PREFIX routes

Juniper Verification:

show route table lsdist.0
# Should show routes from IS-IS/OSPF

Error: "Cannot parse BGP-LS attributes"

Cause: Router sending unsupported TLV or malformed BGP-LS data.

Solution: Enable ExaBGP debugging and report issue with router vendor/version.

exabgp -d /etc/exabgp/bgp-ls.conf

Error: "BGP session established but no data"

Cause: Router filtering BGP-LS or no IGP data to export.

Solution:

  • Check router export policies
  • Verify IGP is running and has topology data
  • Confirm TE extensions are enabled in IGP

Error: "Segment Routing attributes missing"

Cause: Router not configured for Segment Routing or SR not advertised via BGP-LS.

Solution: Enable SR in IGP and ensure SR extensions are exported to BGP-LS.


Important Considerations

ExaBGP Does Not Manipulate RIB/FIB

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

  • Install BGP-LS routes in the RIB
  • Compute paths or LSPs
  • Program forwarding tables
  • Act as a PCE

What ExaBGP DOES:

  • βœ… Receive BGP-LS NLRIs via BGP
  • βœ… Decode topology information
  • βœ… Provide JSON output to external applications
  • βœ… Handle BGP session management

External Software Required:

  • Path Computation: Your application must implement CSPF or path algorithms
  • LSP Programming: Separate tools (PCEP, NETCONF, CLI) install computed paths
  • Topology Processing: Application parses JSON output and builds topology graph

Typical Architecture:

[Your SDN Controller/PCE Application]
       β”‚
       β”œβ”€β†’ [ExaBGP] ─── BGP-LS ───→ [Routers]
       β”‚      (Topology Collection)
       β”‚
       └─→ [Path Computation Engine]
                 β”‚
                 └─→ [PCEP/NETCONF] ───→ [Routers]
                        (LSP Programming)

Receive-Only Implementation

ExaBGP's BGP-LS support is receive-only:

Capability Supported
Receive BGP-LS βœ… Yes
Decode all NLRI types βœ… Yes
Parse TE attributes βœ… Yes
Segment Routing support βœ… Yes
Originate BGP-LS ❌ No
Encode/Send BGP-LS ❌ No

Why Receive-Only?

  • Primary use case: Topology collection for northbound systems
  • IGP routers are authoritative source for link-state data
  • ExaBGP focuses on BGP protocol, not IGP emulation

Performance Considerations

  • Topology Size: ExaBGP handles large topologies (1000+ nodes, 10000+ links)
  • Update Rate: Processes hundreds of BGP-LS updates per second
  • Memory Usage: Depends on topology size; typically < 100MB for medium networks
  • JSON Encoding: External process receives JSON; parse efficiently

Best Practices:

  • Use route reflectors for large BGP-LS deployments
  • Filter unnecessary BGP-LS data at source if possible
  • Process JSON asynchronously in external application
  • Store topology in efficient graph database (Neo4j, NetworkX)

Interoperability

Tested Platforms:

  • βœ… Cisco IOS-XR 6.1.1+ (Note: TLV 1158 bug in early versions)
  • βœ… Juniper Junos 15.1F6.9+ (Prefix NLRI supported from 17.2R1.13+)
  • βœ… Nokia SR OS
  • βœ… Arista EOS

Compatibility: ExaBGP should work with any RFC 7752 compliant BGP-LS implementation.


See Also

ExaBGP Documentation

Use Cases

Operations

Getting Started


References

RFCs and Standards

ExaBGP Resources

Vendor Documentation


πŸ‘» Ghost written by Claude (Anthropic AI)

Clone this wiki locally