Skip to content

Attribute Reference

Jump to bottom
Thomas Mangin edited this page Nov 15, 2025 · 7 revisions

BGP Attributes Reference

A-Z reference for all BGP path attributes supported by ExaBGP

This comprehensive guide covers all BGP attributes that ExaBGP can announce, receive, and manipulate.

Table of Contents

Overview

BGP Attribute Categories

BGP attributes are classified into four categories based on RFC 4271:

Category Propagation Required Examples
Well-Known Mandatory Always propagated Required in UPDATE ORIGIN, AS_PATH, NEXT_HOP
Well-Known Discretionary Always propagated Optional LOCAL_PREF, ATOMIC_AGGREGATE
Optional Transitive Propagated to neighbors Optional AGGREGATOR, COMMUNITY
Optional Non-Transitive Not propagated Optional MED, ORIGINATOR_ID

Attribute Format

In configuration files:

static {
    route 10.0.0.0/24 {
        next-hop 192.168.1.1;
        origin igp;
        as-path [ 65001 65002 ];
        community [ 65001:100 ];
        local-preference 200;
        med 50;
    }
}

Via Text API:

announce route 10.0.0.0/24 next-hop 192.168.1.1 origin igp as-path [ 65001 65002 ] community [ 65001:100 ]

Via JSON API:

{
  "exabgp": "4.0.1",
  "time": 1699999999.0,
  "host": "exabgp-host",
  "pid": 12345,
  "ppid": 1,
  "counter": 1,
  "type": "update",
  "neighbor": {
    "address": { "local": "192.168.1.2", "peer": "192.168.1.1" },
    "asn": { "local": 65001, "peer": 65000 }
  },
  "announcement": {
    "ipv4 unicast": {
      "192.168.1.1": [
        {
          "nlri": "10.0.0.0/24",
          "attribute": {
            "origin": "igp",
            "as-path": [ 65001, 65002 ],
            "next-hop": "192.168.1.1",
            "community": [ [ 65001, 100 ] ],
            "local-preference": 200,
            "med": 50
          }
        }
      ]
    }
  }
}

Well-Known Mandatory Attributes

These attributes MUST be present in every BGP UPDATE message advertising a route.

ORIGIN (Type 1)

Category: Well-Known Mandatory RFC: 4271 Purpose: Indicates the origin of the route information

Values:

  • igp (0) - Route learned from IGP (most preferred)
  • egp (1) - Route learned from EGP (historical)
  • incomplete (2) - Route learned by other means (e.g., static, redistribution)

Configuration:

static {
    route 10.0.0.0/24 {
        next-hop 192.168.1.1;
        origin igp;              # Most common
    }

    route 10.0.1.0/24 {
        next-hop 192.168.1.1;
        origin incomplete;       # For redistributed routes
    }
}

Text API:

announce route 10.0.0.0/24 next-hop 192.0.2.1 origin igp
announce route 10.0.1.0/24 next-hop 192.0.2.1 origin incomplete

Route Selection: IGP > EGP > Incomplete (in tie-breaking)

See also: RFC 4271 Section 5.1.1

AS_PATH (Type 2)

Category: Well-Known Mandatory RFC: 4271, 4893 (4-byte ASN) Purpose: Lists autonomous systems that routing information has traversed

Segment Types:

  • AS_SEQUENCE (Type 2) - Ordered list of ASNs
  • AS_SET (Type 1) - Unordered set of ASNs (for aggregation)
  • AS_CONFED_SEQUENCE (Type 3) - BGP confederation
  • AS_CONFED_SET (Type 4) - BGP confederation set

Configuration:

static {
    route 10.0.0.0/24 {
        next-hop 192.168.1.1;
        as-path [ 65001 65002 65003 ];     # AS_SEQUENCE
    }

    route 10.0.1.0/24 {
        next-hop 192.168.1.1;
        as-path [ ( 65001 65002 ) ];        # AS_SET (for aggregation)
    }
}

Text API:

announce route 10.0.0.0/24 next-hop 192.0.2.1 as-path [ 65001 65002 65003 ]
announce route 10.0.1.0/24 next-hop 192.0.2.1 as-path [ ( 65001 65002 ) ]

AS Path Prepending (for traffic engineering):

# Prepend AS 65001 three times to make path less preferred
announce route 10.0.0.0/24 next-hop 192.0.2.1 as-path [ 65001 65001 65001 ]

4-Byte ASN Support:

ExaBGP fully supports 4-byte ASNs (RFC 4893):

announce route 10.0.0.0/24 next-hop 192.0.2.1 as-path [ 4200000000 65001 ]

Route Selection: Shortest AS path length wins (major tie-breaker)

Loop Detection: Routes are rejected if local ASN appears in AS_PATH

See also: RFC 4271 Section 5.1.2, RFC 4893

NEXT_HOP (Type 3)

Category: Well-Known Mandatory (for IPv4 unicast) RFC: 4271 Purpose: Specifies the IP address to forward packets to

Configuration:

static {
    route 10.0.0.0/24 {
        next-hop 192.168.1.1;        # Explicit next-hop
    }

    route 10.0.1.0/24 {
        next-hop 192.168.1.1;        # Explicit next-hop (recommended)
    }
}

⚠️ Warning: next-hop self is an EXPERIMENTAL feature. For production use, specify an explicit next-hop IP address instead.

Text API:

announce route 10.0.0.0/24 next-hop 192.168.1.1
announce route 10.0.1.0/24 next-hop 192.168.1.1

EBGP Behavior: Next-hop is changed to advertising router's IP IBGP Behavior: Next-hop is preserved (not changed) Route Reflector: Can preserve or change next-hop

IPv6 Next-Hop:

For IPv6, next-hop is carried in MP_REACH_NLRI (not NEXT_HOP attribute):

announce route 2001:db8::/64 next-hop 2001:db8::1
announce route 2001:db8:1::/64 next-hop 2001:db8::1

See also: RFC 4271 Section 5.1.3

Well-Known Discretionary Attributes

These attributes are well-known but not required in every UPDATE.

LOCAL_PREF (Type 5)

Category: Well-Known Discretionary RFC: 4271 Purpose: Indicates degree of preference for a route (IBGP only)

Range: 0-4294967295 (32-bit unsigned integer) Default: 100 (implementation-dependent) Higher value = More preferred

Configuration:

static {
    route 10.0.0.0/24 {
        next-hop 192.168.1.1;
        local-preference 200;        # Highly preferred
    }

    route 10.0.1.0/24 {
        next-hop 192.168.1.1;
        local-preference 50;         # Less preferred
    }
}

Text API:

announce route 10.0.0.0/24 next-hop 192.0.2.1 local-preference 200
announce route 10.0.1.0/24 next-hop 192.0.2.1 local-preference 50

Use Cases:

  • Primary/backup links: Higher LOCAL_PREF on primary
  • Traffic engineering: Control inbound traffic preference
  • Policy routing: Prefer certain paths within AS

Route Selection: LOCAL_PREF is checked FIRST (after weight, if supported)

EBGP: LOCAL_PREF is stripped when advertising to EBGP peers

See also: RFC 4271 Section 5.1.5

ATOMIC_AGGREGATE (Type 6)

Category: Well-Known Discretionary RFC: 4271 Purpose: Indicates route was aggregated and information was lost

Configuration:

static {
    route 10.0.0.0/16 {
        next-hop 192.168.1.1;
        atomic-aggregate;            # No value needed
    }
}

Text API:

announce route 10.0.0.0/16 next-hop 192.0.2.1 atomic-aggregate

Purpose: Informs downstream routers that AS path information may be incomplete due to aggregation.

Used with: AGGREGATOR attribute

See also: RFC 4271 Section 5.1.6

Optional Transitive Attributes

Propagated to neighbors even if not recognized.

AGGREGATOR (Type 7)

Category: Optional Transitive RFC: 4271, 4893 Purpose: Identifies the AS and router that performed route aggregation

Format: <ASN>:<IP>

Configuration:

static {
    route 10.0.0.0/16 {
        next-hop 192.168.1.1;
        atomic-aggregate;
        aggregator 65001:192.168.1.2;    # AS:IP
    }
}

Text API:

announce route 10.0.0.0/16 next-hop 192.0.2.1 aggregator 65001:192.168.1.2

4-Byte ASN Support:

announce route 10.0.0.0/16 next-hop 192.0.2.1 aggregator 4200000000:192.168.1.2

See also: RFC 4271 Section 5.1.7, Configuration Example

COMMUNITY (Type 8)

Category: Optional Transitive RFC: 1997 Purpose: Tags routes for policy application

Format: <ASN>:<Value> (both 16-bit, 0-65535)

Well-Known Communities:

  • NO_EXPORT (65535:65281 / 0xFFFFFF01) - Don't advertise to EBGP peers
  • NO_ADVERTISE (65535:65282 / 0xFFFFFF02) - Don't advertise to any peer
  • NO_EXPORT_SUBCONFED (65535:65283 / 0xFFFFFF03) - Don't export outside confederation
  • NOPEER (65535:65284 / 0xFFFFFF04) - Don't advertise to peers (RFC 3765)

Configuration:

static {
    route 10.0.0.0/24 {
        next-hop 192.168.1.1;
        community [ 65001:100 ];               # Single community
    }

    route 10.0.1.0/24 {
        next-hop 192.168.1.1;
        community [ 65001:100 65001:200 ];     # Multiple communities
    }

    route 10.0.2.0/24 {
        next-hop 192.168.1.1;
        community no-export;                   # Well-known community
    }

    route 10.0.3.0/24 {
        next-hop 192.168.1.1;
        community [ 65001:100 no-advertise ];  # Mixed
    }
}

Text API:

announce route 10.0.0.0/24 next-hop 192.0.2.1 community [ 65001:100 ]
announce route 10.0.1.0/24 next-hop 192.0.2.1 community [ 65001:100 65001:200 ]
announce route 10.0.2.0/24 next-hop 192.0.2.1 community no-export
announce route 10.0.3.0/24 next-hop 192.0.2.1 community [ 65001:100 no-advertise ]

Common Use Cases:

  • Traffic engineering: Tag routes for specific policies
  • Customer identification: Tag customer routes
  • Geographic tagging: Identify route origin location
  • Blackhole triggering: Trigger remote blackhole (RTBH)
  • DDoS mitigation: Trigger FlowSpec rules

Example - Remote Triggered Blackhole (RTBH):

# Cisco/Juniper RTBH: Tag with 65535:666 (blackhole community)
announce route 10.0.0.1/32 next-hop 192.0.2.1 community [ 65535:666 ]

See also: RFC 1997, Configuration Example

EXTENDED_COMMUNITY (Type 16)

Category: Optional Transitive RFC: 4360, 5668 Purpose: Extended community tags (8 bytes vs 4 bytes for standard communities)

Types:

  • Route Target (RT): target:ASN:Value - VPN route filtering
  • Route Origin (RO): origin:ASN:Value - VPN route origin
  • Route Distinguisher (RD): rd:ASN:Value - VPN instance identifier
  • Link Bandwidth: bandwidth:ASN:Value - Unequal cost multipath
  • Redirect: redirect:ASN:Value - FlowSpec traffic redirect
  • Traffic Rate: rate-limit:Value - FlowSpec rate limiting
  • Traffic Action: traffic-action:Sample:Terminal - FlowSpec actions
  • Traffic Marking: mark:Value - FlowSpec DSCP marking

Configuration:

static {
    # VPN route with Route Target
    route 10.0.0.0/24 {
        rd 65001:100;
        next-hop 192.168.1.1;
        extended-community [ target:65001:100 ];
    }

    # FlowSpec redirect
    flow {
        route block-attack {
            match { source 10.0.0.0/8; }
            then { redirect 65001:666; }        # Extended community redirect
        }
    }
}

Text API:

# VPN route
announce route 10.0.0.0/24 rd 65001:100 next-hop 192.0.2.1 extended-community [ target:65001:100 ]

# FlowSpec redirect
announce flow route { match { source 10.0.0.0/8; } then { redirect 65001:666; } }

FlowSpec Extended Communities:

# Rate limit to 1 Mbps
announce flow route { match { source 10.0.0.0/8; } then { rate-limit 1000000; } }

# Mark DSCP
announce flow route { match { source 10.0.0.0/8; } then { mark 10; } }

# Redirect to VRF
announce flow route { match { source 10.0.0.0/8; } then { redirect 65001:100; } }

Format Variants:

  • target:ASN:Value - 2-byte ASN, 4-byte value
  • target:IP:Value - IPv4 address, 2-byte value
  • target:4ByteASN:Value - 4-byte ASN, 2-byte value

See also: RFC 4360, FlowSpec Actions

LARGE_COMMUNITY (Type 32)

Category: Optional Transitive RFC: 8092 Purpose: Large communities (12 bytes) for large ASNs

Format: <ASN>:<Value1>:<Value2> (all 32-bit unsigned integers)

Advantages over Standard Communities:

  • All three fields are 32-bit (vs 16-bit)
  • Supports 4-byte ASNs natively
  • More namespace for values

Configuration:

static {
    route 10.0.0.0/24 {
        next-hop 192.168.1.1;
        large-community [ 65001:100:200 ];
    }

    route 10.0.1.0/24 {
        next-hop 192.168.1.1;
        large-community [ 4200000000:1:2 ];    # 4-byte ASN
    }
}

Text API:

announce route 10.0.0.0/24 next-hop 192.0.2.1 large-community [ 65001:100:200 ]
announce route 10.0.1.0/24 next-hop 192.0.2.1 large-community [ 4200000000:1:2 ]

Use Cases:

  • Organizations with 4-byte ASNs
  • Need more than 65535 community values
  • Encoding additional metadata (location, customer ID, service tier)

See also: RFC 8092, Configuration Example

Optional Non-Transitive Attributes

Not propagated to neighbors.

MULTI_EXIT_DISC (MED, Type 4)

Category: Optional Non-Transitive RFC: 4271 Purpose: Influences route preference from neighboring AS (lower = better)

Range: 0-4294967295 (32-bit unsigned integer) Default: 0 (if not present) Lower value = More preferred

Configuration:

static {
    route 10.0.0.0/24 {
        next-hop 192.168.1.1;
        med 50;                  # More preferred
    }

    route 10.0.1.0/24 {
        next-hop 192.168.1.1;
        med 100;                 # Less preferred
    }
}

Text API:

announce route 10.0.0.0/24 next-hop 192.0.2.1 med 50
announce route 10.0.1.0/24 next-hop 192.0.2.1 med 100

Use Cases:

  • Multi-homed networks: Signal preferred entry point
  • Hot potato routing: Keep traffic on neighbor's network
  • Traffic engineering: Control inbound traffic from specific AS

Comparison Rules:

  • Only compared for routes from same neighboring AS
  • Missing MED treated as 0 (or infinity, depending on router config)

See also: RFC 4271 Section 5.1.4

ORIGINATOR_ID (Type 9)

Category: Optional Non-Transitive RFC: 4456 Purpose: Route reflector loop prevention

Created by: Route reflectors Value: Router ID of the route originator

Configuration:

ExaBGP automatically handles ORIGINATOR_ID when acting as a route reflector.

# Route reflector configuration
neighbor 192.168.1.1 {
    router-id 192.168.1.2;
    local-as 65001;
    peer-as 65001;

    # Route reflection enabled
    route-reflector-client;
}

Purpose: Prevents routing loops in route reflector topologies

See also: RFC 4456, Route Reflection

CLUSTER_LIST (Type 10)

Category: Optional Non-Transitive RFC: 4456 Purpose: Route reflector cluster loop prevention

Created by: Route reflectors Value: List of cluster IDs the route has passed through

Configuration:

ExaBGP automatically manages CLUSTER_LIST when acting as a route reflector.

neighbor 192.168.1.1 {
    router-id 192.168.1.2;
    local-as 65001;
    peer-as 65001;

    # Cluster ID (default = router-id)
    cluster-id 192.168.1.10;
    route-reflector-client;
}

Purpose: Prevents routing loops between route reflector clusters

See also: RFC 4456

Extended Attributes

MP_REACH_NLRI (Type 14)

Category: Optional Non-Transitive RFC: 4760 Purpose: Multiprotocol reachability (for non-IPv4 unicast)

Used for:

  • IPv6 unicast
  • VPNv4/VPNv6
  • FlowSpec
  • EVPN
  • BGP-LS
  • L2VPN/VPLS
  • MVPN

Configuration:

ExaBGP automatically encodes routes in MP_REACH_NLRI based on address family.

neighbor 192.168.1.1 {
    family {
        ipv6 unicast;        # Uses MP_REACH_NLRI
        ipv4 flow;           # Uses MP_REACH_NLRI
        l3vpn ipv4;          # Uses MP_REACH_NLRI
    }
}

static {
    # IPv6 route - automatically uses MP_REACH_NLRI
    route 2001:db8::/64 {
        next-hop 2001:db8::1;
    }
}

Text API:

# IPv6 - uses MP_REACH_NLRI
announce route 2001:db8::/64 next-hop 2001:db8::1

# FlowSpec - uses MP_REACH_NLRI
announce flow route { match { source 10.0.0.0/8; } then { discard; } }

See also: RFC 4760

MP_UNREACH_NLRI (Type 15)

Category: Optional Non-Transitive RFC: 4760 Purpose: Multiprotocol unreachability (withdraw non-IPv4 unicast routes)

Text API:

# Withdraw IPv6 route
withdraw route 2001:db8::/64

# Withdraw FlowSpec rule
withdraw flow route { match { source 10.0.0.0/8; } }

See also: RFC 4760

PMSI_TUNNEL (Type 22)

Category: Optional Transitive RFC: 6514 Purpose: Provider Multicast Service Interface (for MVPN)

Used in: MVPN configurations

Configuration:

# MVPN with PMSI_TUNNEL
flow {
    route mvpn-route {
        rd 65001:1;
        pmsi tunnel-type ingress-replication tunnel-identifier 192.168.1.1;
    }
}

See also: RFC 6514, MVPN Configuration

AIGP (Type 26)

Category: Optional Non-Transitive RFC: 7311 Purpose: Accumulated IGP Metric

Configuration:

static {
    route 10.0.0.0/24 {
        next-hop 192.168.1.1;
        aigp 100;
    }
}

Text API:

announce route 10.0.0.0/24 next-hop 192.0.2.1 aigp 100

Use Cases: Seamless MPLS, inter-domain metric comparison

See also: RFC 7311

PREFIX_SID (Type 40)

Category: Optional Transitive RFC: Draft (Segment Routing) Purpose: Segment Routing prefix segment identifier

Configuration:

static {
    route 10.0.0.0/24 {
        next-hop 192.168.1.1;
        prefix-sid [ 100 ];
    }
}

See also: SRv6 and MUP, Configuration Example

Generic Attribute Support

ExaBGP supports announcing arbitrary BGP attributes using generic attribute syntax.

Configuration:

static {
    route 10.0.0.0/24 {
        next-hop 192.168.1.1;
        attribute [ generic 255 0x01020304 ];  # Type 255, hex value
    }
}

Text API:

announce route 10.0.0.0/24 next-hop 192.0.2.1 attribute [ generic 255 0x01020304 ]

See also: Configuration Example

Alphabetical Index

Quick alphabetical lookup of all attributes.

Attribute Type Category RFC
AIGP 26 Optional Non-Transitive 7311
AGGREGATOR 7 Optional Transitive 4271
AS_PATH 2 Well-Known Mandatory 4271
ATOMIC_AGGREGATE 6 Well-Known Discretionary 4271
CLUSTER_LIST 10 Optional Non-Transitive 4456
COMMUNITY 8 Optional Transitive 1997
EXTENDED_COMMUNITY 16 Optional Transitive 4360
LARGE_COMMUNITY 32 Optional Transitive 8092
LOCAL_PREF 5 Well-Known Discretionary 4271
MED (MULTI_EXIT_DISC) 4 Optional Non-Transitive 4271
MP_REACH_NLRI 14 Optional Non-Transitive 4760
MP_UNREACH_NLRI 15 Optional Non-Transitive 4760
NEXT_HOP 3 Well-Known Mandatory 4271
ORIGIN 1 Well-Known Mandatory 4271
ORIGINATOR_ID 9 Optional Non-Transitive 4456
PMSI_TUNNEL 22 Optional Transitive 6514
PREFIX_SID 40 Optional Transitive Draft

Quick Reference Tables

Route Selection Attributes

BGP route selection order (simplified):

  1. Highest Weight (Cisco proprietary, not in ExaBGP)
  2. Highest LOCAL_PREF ← ExaBGP supports
  3. Locally originated (prefer local routes)
  4. Shortest AS_PATH ← ExaBGP supports
  5. Lowest ORIGIN (IGP < EGP < Incomplete) ← ExaBGP supports
  6. Lowest MED (from same AS) ← ExaBGP supports
  7. EBGP > IBGP
  8. Lowest IGP metric to NEXT_HOP
  9. Oldest route (stability)
  10. Lowest Router ID

Attributes ExaBGP can manipulate for traffic engineering:

  • LOCAL_PREF (IBGP preference)
  • AS_PATH (prepending for less preferred paths)
  • MED (hint to neighbor AS)
  • COMMUNITY (trigger policies)

Traffic Engineering Cheat Sheet

Goal Attribute Action
Prefer inbound path (IBGP) LOCAL_PREF Set higher value (e.g., 200)
Deprefer inbound path (IBGP) LOCAL_PREF Set lower value (e.g., 50)
Make path less attractive (outbound) AS_PATH Prepend local AS multiple times
Hint preferred entry (to neighbor AS) MED Set lower value (e.g., 50)
Trigger remote policy COMMUNITY Tag with agreed community
Blackhole traffic COMMUNITY Tag with 65535:666 (RTBH)
Don't advertise to EBGP COMMUNITY Add NO_EXPORT
Mark VPN route EXTENDED_COMMUNITY Set Route Target

FlowSpec Actions and Attributes

FlowSpec actions are implemented as Extended Communities.

Action Extended Community Type Example
Discard Traffic Action (0x8006) then { discard; }
Rate Limit Traffic Rate (0x8006) then { rate-limit 1000000; }
Redirect to VRF Redirect (0x8008) then { redirect 65001:100; }
Redirect to IP Redirect IP (0x8108) then { redirect 1.2.3.4; }
Mark DSCP Traffic Marking (0x8009) then { mark 10; }
Sample Traffic Action then { action sample; }
Terminal Traffic Action then { action terminal; }

See also: FlowSpec Actions Reference

VPN Attributes

L3VPN routes use Extended Communities for route filtering.

Attribute Type Purpose Example
Route Distinguisher (RD) Special VPN instance identifier rd 65001:100
Route Target (RT) Extended Community Import/export filter target:65001:100
Route Origin (RO) Extended Community VPN route origin origin:65001:100

Configuration:

static {
    route 10.0.0.0/24 {
        rd 65001:100;                             # Route Distinguisher
        next-hop 192.168.1.1;
        extended-community [ target:65001:100 ];  # Route Target
    }
}

See also: L3VPN Overview

See Also

Documentation

Address Families

Features

RFCs

Examples

👻 Ghost written by Claude (Anthropic AI)

🏠 Home

🚀 Getting Started

🔧 API

🛡️ Use Cases

🌐 Address Families

⚙️ Configuration

🔍 Operations

📚 Reference

🔄 Migration

🌍 Community

🔗 External

👻 Ghost written by Claude (Anthropic AI)

Clone this wiki locally