Rayhaan JaufeerallyandClaude Fable 5.1 d49bab58a5 Add ADD-PATH (RFC 7911): several routes for a prefix from one peer
A peer can now send several routes for one prefix, told apart by a path
identifier, and each is a route of its own in the table.

Wire:
- The ADD-PATH capability lists several address families. It was read as
  exactly one, so the OPEN of a router offering it for IPv4 and IPv6 was
  malformed and the session never came up.
- Prefixes in UPDATEs are `Nlri`: a prefix and a path identifier. The
  identifier is on the wire, in the body and in MP_REACH/MP_UNREACH, for
  the families the session uses ADD-PATH for in that direction. Sending
  and receiving are settled separately, so a session has one codec context
  for each.

Negotiation:
- `add_path` on a peer in the configuration: off (the default), receive,
  send or both, offered for every family offered to the peer.
- In use for a family and a direction when one side offered to send and
  the other to receive. Shown on /statusz and in /api/peers.

Table:
- A route is known by its peer and path identifier together. Identifiers
  are stored only in rows that have a non-zero one, so routes of peers
  that send one route each cost nothing more.
- Equal routes from one peer are chosen between by the lower identifier.
- /api/routes/received gives each route's path_id.

Journal:
- A second journal in each shard records every change to any route, for
  followers that want all the routes of a prefix and not only the best:
  RibTable::reader_of_all_routes and Event::Routes. This is what sending
  several routes to a peer will read. It costs nothing while nobody
  follows it.

Sending: prefixes go out with a path identifier where that was agreed, but
there is still one route for each prefix to send: only originated routes
are announced.

Tested with the table and journal model tests extended to path identifiers
and to followers of all routes, the codec property tests and fuzz targets
extended to ADD-PATH sessions, and end to end in both directions and for
the case where only one side offers it.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2026-10-02 00:57:15 +02:00
2026-10-01 21:01:26 +02:00

BGP

The bgp crate is an implementation of the Border Gateway Protocol, which is used to exchange routing and control plane information between Autonomous Systems.

The aim of this project is to provide a modern, high performance, secure, programmatic and customizable software package that can be useful to network operators, researchers, and people interested in Internet.

Current status.

The project is currently being rewritten from scratch to be more modular and maintainable, as well as to fix deeper issues with the previous implementation.

⚠️ Warning: This is currently a work in progress and not ready for use.

🛣️ Roadmap to v1.0

We aim for the 1.0 release to be functional and stable to operate peering sessions, and to install routes in the Linux Kernel.

  • ☐ Implement basic parsers for the fundamental types required
    • ✅ Path Attributes from RFC4271
    • ✅ Open message
      • ✅ Capabilities from RFC4271
    • ✅ Update message
    • ☐ Notification message
  • ✅ Implement scaffolding required to start and configure a server
  • ✅ Implement connection logic to establish sessions with peers (passive and active)
  • ✅ Routes originated from the configuration, with communities, announced to all peers
  • ✅ Read-only HTTP API, status page and Prometheus metrics
  • ☐ Implement an efficient data structure for storing prefixes (e.g. Poptrie)
  • ☐ Filtering for peer RIB in / out
  • ☐ Main / auxiliary RIBs for exchanging routes between peers

Development

CI runs these three on every push, and fails on any warning:

cargo fmt --all -- --check
cargo clippy --workspace --all-targets -- -D warnings
cargo test --workspace

Lints are configured once, under [workspace.lints] in the root Cargo.toml. unsafe code is forbidden throughout.

cargo test includes property tests: generated messages must survive being written and read back, and no input, however damaged, may make a parser panic. They take about a second; for a longer hunt:

PROPTEST_CASES=1000000 cargo test --release -p bgp-packet --test properties

Coverage-guided fuzz targets for the same parsers are in fuzz/; see fuzz/README.md. CI runs each of them for a minute.

License

Apache License 2.0; see LICENSE.

S
Description
Ferrix BGP Speaker
Readme
5 MiB
0 Stars 0 Watchers 0 Forks
Languages
Rust 92.3%
Shell 4.2%
HTML 3.5%