Skip to content

bgp nlri srpolicy

Thomas Mangin edited this page Jun 24, 2026 · 2 revisions

Pre-Alpha. This page describes behavior that may change.

SR-Policy NLRI (SAFI 73, RFC 9830) carries Segment Routing policy information over BGP. Ze ships the bgp-nlri-srpolicy plugin for both IPv4 and IPv6 SR-Policy families. The family is decoded, encoded, and originated entirely through the plugin NLRI pipeline, not the legacy core path.

Category

Address families.

Families

Family Config name AFI / SAFI Encode Decode
IPv4 SR-Policy ipv4/sr-policy 1 / 73 Yes Yes
IPv6 SR-Policy ipv6/sr-policy 2 / 73 Yes Yes

Configuration

Enable SR-Policy as an address family on a peer:

bgp {
    peer controller {
        connection { remote { ip 10.0.0.1; } }
        session {
            asn { local 65000; remote 65100; }
            family {
                ipv4/sr-policy { prefix { maximum 10000; } }
                ipv6/sr-policy { prefix { maximum 10000; } }
            }
        }
    }
}

Plugin pipeline

The plugin registers as bgp-nlri-srpolicy and wires four in-process callbacks into the registry:

Callback Role
InProcessNLRIDecoder Decodes received SR-Policy NLRI hex into structured fields.
InProcessNLRIEncoder Encodes the NLRI key fields (distinguisher, color, endpoint) to wire hex.
InProcessRouteEncoder Builds a full UPDATE from a route command, including the Tunnel Encapsulation attribute.
InProcessConfigRouteParser Parses config and ExaBGP-migrated route text into a pre-built NLRI plus attribute bytes.

The two SR-Policy families also register with the NLRI splitter so the RIB and filter chain see them like any other family. Decoding, JSON rendering, and re-encoding all happen in the plugin, so the central config and reactor code carry no SR-Policy-specific knowledge.

NLRI format

Each SR-Policy NLRI encodes a Distinguisher (4 bytes), Color (4 bytes), and Endpoint address (4 bytes for IPv4, 16 bytes for IPv6). The NLRI is carried in MP_REACH_NLRI / MP_UNREACH_NLRI attributes.

JSON output

SR-Policy NLRIs render through the attribute JSON registry. The plugin's AppendJSON writes the fields directly into the output buffer with keys in alphabetical order (color, distinguisher, endpoint) so the result matches json.Marshal(map[string]any) and stays ExaBGP-compatible.

{"color":100,"distinguisher":0,"endpoint":"10.0.0.1"}

Tunnel Encapsulation attribute

SR-Policy routes carry the Tunnel Encapsulation attribute (type 23, RFC 9012) holding the candidate path: preference, binding SID, SRv6 binding SID, one or more segment lists, and optional policy or candidate-path names. Ze parses Tunnel Encapsulation TLVs on received updates and preserves them on forwarded updates.

Sub-TLVs are parsed on demand: the attribute keeps each Tunnel Type TLV as raw bytes and only walks the sub-TLVs when a caller asks for a field (for example the Preference value). Sub-TLV types 0-127 use a 1-byte length and 128-255 use a 2-byte length per RFC 9012 Section 3. Unknown tunnel types and sub-TLVs are preserved unchanged for forwarding.

The config route parser builds the Tunnel Encapsulation attribute from a route command:

neighbor controller announce route \
    distinguisher 0 color 100 endpoint 10.0.0.1 next-hop 10.0.0.254 \
    preference 200 \
    binding-sid mpls 24000 \
    segment-list weight 1 \
        segment type-a mpls 16001 \
        segment type-b srv6 2001:db8::1

The TunnelEncap sub-TLV building lives entirely in the plugin, following the registration pattern. Segment type-A (MPLS) and type-B (SRv6) sub-sub-TLVs use the draft numbering (type 1 and type 13) that ExaBGP emits, which is intentional for migration wire-format compatibility.

ExaBGP bridge

SR-Policy NLRIs are supported through the ExaBGP bridge (ze exabgp plugin), allowing existing scripts to announce and withdraw SR-Policy routes. The ExaBGP config migration pipeline also routes ipv4/sr-policy and ipv6/sr-policy blocks to the plugin's config route parser, so migrated SR-Policy routes build correctly instead of falling through to the standard prefix parser.

Behaviour

The plugin registers the two SR-Policy families with the NLRI splitter. It decodes incoming SR-Policy NLRIs, makes them available to the RIB and filter chain, and re-encodes them on the egress path. SR-Policy NLRIs do not use ADD-PATH.

Interactions

Plugin Interaction
bgp-rib Stores SR-Policy routes alongside other families.
bgp-rs Route server forwards SR-Policy NLRIs to clients.
bgp-filter-community Community filters apply to SR-Policy routes.

Source

main/internal/component/bgp/plugins/nlri/srpolicy/

See also

Adapted from the srpolicy plugin source code and RFC 9830 / RFC 9012.

Home

About

First Steps

Configuration

Operation

Interfaces

Plugins

Plugin Development

Chaos Testing

Blueprints

Development

Reference

Clone this wiki locally