-
Notifications
You must be signed in to change notification settings - Fork 2
bgp nlri srpolicy
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.
Address 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 |
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; } }
}
}
}
}
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.
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.
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"}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.
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.
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.
| 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. |
main/internal/component/bgp/plugins/nlri/srpolicy/
- Address Families for the full family list.
- SRv6 for Segment Routing over IPv6 with Prefix-SID.
- Plugins for the plugin catalogue.
Adapted from the srpolicy plugin source code and RFC 9830 / RFC 9012.
Unreviewed draft. This wiki was authored in bulk and has not been reviewed. File corrections on the issue tracker.
- Overview
- YANG Model
- Editor Workflow
- Archive and Rollback
- System
- Interfaces
- VRRP
- BFD
- FIB
- OSPF
- IS-IS
- MPLS / LDP / RSVP-TE
- RSVP-TE
- SRv6
- Static Routes
- Policy Routing
- Firewall
- Traffic Control
- Class of Service
- L2TP/PPP
- PPPoE
- VPP Data Plane
- RPKI
- IPsec VPN
- TACACS+ AAA
- RADIUS AAA
- AS112 DNS
- Authorization
- Fleet
- BGP
- Starting and Stopping
- Show Commands
- Monitoring
- Flow Export
- DDoS Mitigation
- Anomaly Detection
- Health Checks
- Audit Trail
- Production Diagnostics
- Logging
- Operational Reports
- Healthcheck
- Self-Update
- Zero-Touch Provisioning
- MRT Analysis
- Upgrade and Restart
- Storage
- Policy
- Core
- Resilience
- Validation
- Capabilities
- Address Families
- Protocol
- Subsystems
- Infrastructure
- Route Server at an IXP
- Transit Edge with RPKI
- Public Looking Glass
- ExaBGP Migration Walkthrough
- FlowSpec Injection
- Chaos-Tested Peering
- AS Path Topology