ferrix/docs/content/docs/reference/rfcs.md at 9276bc9f7a443e75e0f2ea9f55e162ed105c61f4

0 Fork 0

Files

T

Rayhaan JaufeerallyandClaude Fable 5.1 ec5c9be454 export: advertise every route for a prefix with ADD-PATH (all_paths)

Before this change, a session on which ADD-PATH (RFC 7911) was
negotiated in the sending direction was sent path identifiers, but only
the best route for each prefix. A route collector such as bgp.tools
wants every route a router has accepted, from every neighbor, and from
one session: without this the collector saw one path per prefix, nearly
always the same neighbor's.

This change adds `all_paths` to the export policy. On a session with it,
and ADD-PATH send negotiated for a family, every accepted route for a
prefix of that family is advertised, each with a path identifier of its
own; for a family without ADD-PATH send the best route goes as before.
`all_paths` needs `learned_routes` (a configuration error otherwise) and
the peer's `add_path` to offer sending. The export policy, the role
rules, the well-known communities and the export limits apply to every
route alike, and the export limits count every route.

Implementation, in the advertiser:

* An exporter with `all_paths` follows the table's journal of all routes
  (`RibTable::reader_of_all_routes`, until now unused) instead of the
  best-route journal, and is given all the routes of a prefix whenever
  one of them changes (`News::Routes`).
* What the peer holds is `Announced`: the set of prefixes for a
  best-route session, as before; or for an all-paths session, for each
  prefix the routes announced, keyed by the peer they came from and that
  peer's own identifier, with the identifier they went out with and the
  form they went out in. A route keeps its identifier for as long as it
  is announced, goes out again only if it changed, and is withdrawn by
  its identifier; a new route gets the lowest identifier not in use for
  the prefix, from 1.
* Verdicts carry either kind (`Verdict::Best`, `Verdict::All`), and a
  reset of the table puts what was announced in doubt until heard of
  again, as before, with the same identifiers kept across the reset.
* The record for an all-paths session is about 50 bytes a route, some
  tens of megabytes for a full table from several neighbors; the
  best-route bookkeeping is unchanged in size.

Also, so that a collector session can be watched: the number of routes
advertised to each peer and not withdrawn since, every route counted
where several are sent for a prefix. The exporter keeps it in the
session's counters after every change; it is `advertised_routes` in
`/api/peers`, the "sent" column of the status page's neighbor table,
and the gauge `bgp_peer_advertised_routes{peer}`.

Documentation: a "Feeding a Route Collector" section in the guide to
passing routes on, with the configuration for a collector; `all_paths`
in the configuration reference; the ADD-PATH sections of the neighbor
guide and the standards reference; the limitation that was removed;
the new field, column and metric in the HTTP API, monitoring and
metrics references.

Testing: an integration test with two feeders and a collector that
negotiated ADD-PATH receive, which checks the two routes with their
identifiers, the withdrawal of one by its identifier, a changed route
keeping its identifier and a new route taking the free one; a
configuration test for `all_paths` without `learned_routes`; a new
`collector` phase of the interoperability lab in which FRR, as a route
collector, is told both of BIRD's routes for a prefix from BIRD's two
sessions and holds them apart, and loses one when its session is
disabled, with the advertised count checked at each step. The workspace tests, the kernel tests and every lab phase pass.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

2026-10-09 01:16:48 +02:00

14 KiB

Raw Blame History

+++ title = "Supported Standards" description = "Lists the RFCs and Internet-Drafts that Ferrix supports, and the implementation status of each feature." weight = 5

[extra] nav = "Supported Standards" +++

This topic lists the RFCs and Internet-Drafts that Ferrix supports, and the implementation status of each feature. Table 1 describes the status values.

Status	Meaning
✅	Supported.
🟡	Encoded and decoded only. Ferrix parses and generates the element but does not act on it.
❌	Not supported.

Core BGP

RFC 4271 — A Border Gateway Protocol 4 (BGP-4)

https://datatracker.ietf.org/doc/html/rfc4271

The base protocol specification.

Section	Description	Status
§4.1	Message framing (marker, length, type)	✅
§4.2	OPEN message	✅
§4.3	UPDATE message (path attributes, NLRI, withdrawn routes)	✅
§4.4	KEEPALIVE message	✅
§4.5	NOTIFICATION message (all error codes and subcodes)	✅
§8	FSM — passive (inbound) side: OpenSent → OpenConfirm → Established	✅
§8	FSM — active (outbound) side: dial configured peers, exponential retry	✅
§6.2	Bad Peer AS check against configured ASN	✅
§6.7 / RFC 4486	Cease / Administrative Shutdown sent to every peer on SIGINT or SIGTERM	✅
§6.8	Connection collision detection (BGP Identifier comparison, Cease / Connection Collision Resolution)	✅
§8.1.1	Optional `CollisionDetectEstablishedState` (`collision_detect_established_state`)	✅
§6.2	Bad BGP Identifier check (neighbor uses the local identifier, or 0.0.0.0)	✅
§9	Decision process / best-path selection	✅
§9.1.2	Best routes installed for forwarding (Linux kernel, over netlink)	✅
§9.1.2.1	Routes with an unresolvable next hop excluded from selection	✅ where routes are installed in the kernel: such a route is held out of the table until its next hop can be reached
§9.1.2.1	Next hops resolved through other routes	✅ (through the kernel's connected, static and IGP routes; not through BGP routes)
§9	Adj-RIB-In (per-peer table of received routes)	✅
§9	Locally originated routes, advertised to all established peers	✅
§9	Advertisement of the best path for each prefix to neighbors (`export.learned_routes`), with the local AS prepended and the local address as next hop; MED and LOCAL_PREF not sent to EBGP neighbors; LOCAL_PREF sent to IBGP neighbors (§5.1.4, §5.1.5, §9.1.3)	✅
§9.2.1	Routes learned from an IBGP neighbor not advertised to other IBGP neighbors, except by route reflection (RFC 4456)	✅
§9.1.3	Routes not advertised to a neighbor whose AS is in the AS path	✅
§5	Unknown optional transitive attributes advertised with the Partial bit set; unknown non-transitive attributes not advertised	✅
§9.2	Hold timer reset on any received message (not only KEEPALIVE)	✅

Capability and Session Extensions

RFC 6793 — BGP Support for Four-Octet Autonomous System (AS) Number Space

https://datatracker.ietf.org/doc/html/rfc6793

Feature	Status
`AS_TRANS` (23456) sentinel	✅
`FourByteAsn` capability advertisement and parsing	✅
4-byte AS_PATH segment encoding/decoding via `ParserContext`	✅
4-byte ASN negotiation in FSM	✅
AS4_PATH from a two-octet peer merged into AS_PATH on receipt (§4.2.3); one longer than AS_PATH ignored	✅

RFC 9774 — Deprecation of AS_SET and AS_CONFED_SET in BGP

https://datatracker.ietf.org/doc/html/rfc9774

Feature	Status
Routes with an AS_SET in the AS path rejected on import (configurable with `accept_as_sets`)	✅
AS_SET never sent	✅

RFC 9072 — Extended Optional Parameters Length for BGP OPEN Message

https://datatracker.ietf.org/doc/html/rfc9072

Feature	Status
Parsing extended-length OPEN (0xFF sentinel)	✅
Serialising extended-length OPEN when options exceed 255 bytes	✅

RFC 2918 — Route Refresh Capability for BGP-4

https://datatracker.ietf.org/doc/html/rfc2918

Feature	Status
`RouteRefresh` capability advertisement	✅
`ROUTE-REFRESH` message type (5) framing	✅
AFI/SAFI payload parsing	✅
Received ROUTE-REFRESH processed by readvertising all routes for the session, for all AFI/SAFIs	✅

RFC 7313 — Enhanced Route Refresh Capability for BGP-4

https://datatracker.ietf.org/doc/html/rfc7313

Feature	Status
`EnhancedRouteRefresh` capability wire format	🟡

RFC 4724 — Graceful Restart Mechanism for BGP

https://datatracker.ietf.org/doc/html/rfc4724

Feature	Status
`GracefulRestart` capability (parse, serialise)	✅
Receiving speaker: routes of a restarting neighbor retained as stale, and removed at its End-of-RIB or after the stale timer	✅
Restarting speaker: forwarding state preserved in the kernel over a restart (SIGUSR1); R and F bits	✅
End-of-RIB marker sent and received	✅
Route selection deferred until neighbors' End-of-RIB (for the removal of kept kernel routes and End-of-RIB markers for learned routes)	✅

RFC 4456 — BGP Route Reflection

https://datatracker.ietf.org/doc/html/rfc4456

Feature	Status
Route reflector: routes from clients to all IBGP neighbors, from other IBGP neighbors to clients	✅
ORIGINATOR_ID and CLUSTER_LIST added on reflection, not sent to EBGP neighbors	✅
Routes with the local router ID as ORIGINATOR_ID, or the local cluster ID in CLUSTER_LIST, rejected	✅
Configurable cluster ID	✅
Next hop unchanged on reflection	❌ The route reflector sets itself as the next hop
ORIGINATOR_ID and CLUSTER_LIST length as best path tie breakers (§9)	❌

RFC 8538 — Notification Message Support for BGP Graceful Restart

https://datatracker.ietf.org/doc/html/rfc8538

Feature	Status
N bit advertised and negotiated	✅
Routes retained after a NOTIFICATION other than Hard Reset, and after hold timer expiry	✅
Hard Reset sent for errors and for a stop, with the original NOTIFICATION as its data	✅

RFC 9494 — Long-Lived Graceful Restart for BGP

https://datatracker.ietf.org/doc/html/rfc9494

Feature	Status
`LongLivedGracefulRestart` capability wire format	🟡

RFC 8654 — Extended Message Support for BGP

https://datatracker.ietf.org/doc/html/rfc8654

Feature	Status
`ExtendedMessage` capability wire format	🟡
Raising `BGP_MAX_MSG_LEN` to 65535 when negotiated	❌

Multiprotocol and NLRI

RFC 2858 — Multiprotocol Extensions for BGP-4

https://datatracker.ietf.org/doc/html/rfc2858

Feature	Status
`MultiProtocol` capability advertisement (IPv4 and IPv6 unicast)	✅
`MP_REACH_NLRI` path attribute (parse, serialise)	✅
`MP_UNREACH_NLRI` path attribute (parse, serialise)	✅
IPv4 and IPv6 next-hop encoding	✅

RFC 8950 — Advertising IPv4 Network Layer Reachability Information (NLRI) with an IPv6 Next Hop

https://datatracker.ietf.org/doc/html/rfc8950

Feature	Status
`ExtendedNextHop` capability offered on sessions over IPv6 that carry IPv4 unicast, and used if the peer offers it	✅
IPv4 unicast routes advertised and withdrawn in MP_REACH_NLRI / MP_UNREACH_NLRI with the local IPv6 address as next hop	✅
IPv4 unicast routes received with an IPv6 next hop (global, or global and link-local)	✅
Such routes installed in the kernel (IPv4 route by way of an IPv6 neighbor)	✅
Other families than IPv4 unicast (VPN-IPv4, labelled)	❌
Sessions between link-local addresses (`fe80::1%eth0`), with link-local next hops	✅

Path Attributes and Communities

RFC 1997 — BGP Communities Attribute

https://datatracker.ietf.org/doc/html/rfc1997

Feature	Status
`COMMUNITIES` path attribute (parse, serialise)	✅
Attach to locally originated routes	✅
NO_EXPORT, NO_EXPORT_SUBCONFED, and NO_ADVERTISE observed when learned routes are advertised	✅
Communities added and removed by import and export policy	✅

RFC 4360 — BGP Extended Communities Attribute

https://datatracker.ietf.org/doc/html/rfc4360

Feature	Status
`EXTENDED_COMMUNITIES` path attribute (parse, serialise)	✅
AS-specific, IPv4-address-specific, opaque, route-target, route-origin subtypes	✅

RFC 8092 — BGP Large Communities Attribute

https://datatracker.ietf.org/doc/html/rfc8092

Feature	Status
`LARGE_COMMUNITIES` path attribute (parse, serialise)	✅
Attach to locally originated routes	✅

RFC 7999 — BLACKHOLE Community

https://datatracker.ietf.org/doc/html/rfc7999

Feature	Status
`BLACKHOLE` accepted as a community name in configuration	✅
Routes with BLACKHOLE from EBGP neighbors rejected on import by default (`blackhole request`)	✅
Blackhole routes for single addresses accepted with `accept_blackholes` (§3.2: prefix length limits relaxed, next hop not checked)	✅
Blackhole routing: a kernel blackhole route discards traffic for the prefix	✅
Blackhole routes advertised with the community, for providers to honor (§3.3)	✅
A blackhole route for a prefix this router originates	❌ (add a kernel blackhole route by hand)

Other Capabilities (Wire Format Only)

The following capabilities are parsed and serialised correctly but have no functional behaviour implemented beyond that.

RFC	Capability	Status
RFC 5291	Outbound Route Filtering (ORF)	🟡
RFC 8205	BGPsec	🟡

Error Handling

RFC 9687 — BGP Send Hold Timer

https://datatracker.ietf.org/doc/html/rfc9687

Feature	Status
`SendHoldTimer` error code (8) defined	✅
Send hold timer enforcement (a write that makes no progress ends the session)	✅

Route Security

RFC 6811 — BGP Prefix Origin Validation

https://datatracker.ietf.org/doc/html/rfc6811

Feature	Status
Validation states (valid, invalid, not found) for routes from external peers	✅
Invalid routes rejected, per neighbor (configurable with `accept_rpki_invalid`)	✅
Routes revalidated when the VRPs change, in both directions	✅
Validation of routes from internal peers and of originated routes	❌
Validity as a step of route selection (RFC 8097 communities)	❌

draft-ietf-sidrops-aspa-verification — BGP AS_PATH Verification Based on ASPA

https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-verification/

Implemented from version 24 of the draft.

Feature	Status
Upstream verification (routes from customers, peers, route servers and route server clients)	✅
Downstream verification (routes from providers)	✅
Per-peer role (`role`); paths of peers without one are not verified	✅
Invalid paths rejected, per neighbor (configurable with `accept_aspa_invalid`)	✅
Routes revalidated when the ASPAs change, in both directions	✅
Paths with an AS_SET invalid	✅
Verification on export	❌ (the AS paths of advertised routes are not verified)

RFC 7947 — Internet Exchange BGP Route Server

https://datatracker.ietf.org/doc/html/rfc7947

Feature	Status
§2.2.1 / §2.2.2: to a `ROUTE_SERVER_CLIENT` the path is not prepended and the next hop and MED are left as they came	✅
§2.2.2.2 / §4.6: communities with which a client restricts the advertisement of its routes to other clients (`control_communities`)	✅
Per-client best path selection (a different best route for each client)	❌ (every client receives the same best path)

RFC 9234 — Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages

https://datatracker.ietf.org/doc/html/rfc9234

Feature	Status
BGP Role capability sent for peers with a configured `role`	✅
Role Mismatch (OPEN Message Error, subcode 11) when the neighbor's role does not correspond to the local role, or the neighbor advertises conflicting roles	✅
Strict mode (`require_role`)	✅
Only to Customer attribute: parse, serialise, treat-as-withdraw when malformed	✅
Ingress: routes with OTC rejected from customers, route server clients, and (unless the OTC value is the peer's AS) peers	✅
Ingress: routes from providers, peers and route servers marked	✅
Egress: originated routes to customers, peers and route server clients marked	✅
Egress: marked routes not sent to providers, peers or route servers	✅

RFC 8210 — The RPKI to Router Protocol, Version 1 (RFC 6810, version 0; draft-ietf-sidrops-8210bis, version 2)

https://datatracker.ietf.org/doc/html/rfc8210

Version 2 is implemented from version 23 of the draft.

Feature	Status
Reset and serial queries, notifies, cache reset, incremental updates	✅
Refresh, retry and expire intervals; data dropped when it expires	✅
Version 2, with fallback to 1 and 0; several caches with failover	✅
ASPA PDU (version 2)	✅
Error Reports sent to the cache	✅
Version 2's ordering of PDUs enforced on what a cache sends	❌ (PDUs are accepted in any order)
Transport over plain TCP	✅
Transport over SSH, TLS, TCP-MD5 or TCP-AO	❌
Router keys (BGPsec)	🟡 read and ignored

RFC 7911 — Advertisement of Multiple Paths in BGP (ADD-PATH)

https://datatracker.ietf.org/doc/html/rfc7911

Feature	Status
Capability negotiation per family and direction	✅
Receiving several routes for a prefix	✅
Sending several routes for a prefix	✅ with `all_paths` in the export policy; the best path only otherwise

RFC 4271 §9.1.2 / RFC 4486 / operational practice — import policy

Feature	Status
Routes with the local AS in the AS path rejected (loop detection)	✅
Bogon prefixes and AS numbers, prefix length bounds, first-AS check	✅
Per-peer prefix and origin AS allow-lists	✅
Maximum prefixes with Cease / Maximum Number of Prefixes Reached and hold-down	✅

14 KiB Raw Blame History