Rayhaan JaufeerallyandClaude Fable 5.1
3b20576971
Whatever acts on the best routes (export to peers, the forwarding table, the status page) reads their changes from a per-shard journal through a table::Reader. Nothing uses it yet. - The journal records that a prefix's best route changed, not what to. A reader that comes to an entry is given the route as it is then. A prefix that changes a thousand times between reads is one event, and the journal never holds more live entries than the table has prefixes. - Each row keeps the sequence number of its latest change; an entry with another number is dead and is dropped when the journal is tidied. - Entries go once every reader has passed them. A reader that does not read cannot hold them back for ever: past a limit the oldest half is dropped, and that reader is given the whole table again (Reset, every best route, Synced). A new reader starts the same way. - With no reader nothing is recorded. - Reader::changed waits for there to be something to read. Tested against a mirror kept from the events: after any interleaving of announcements, withdrawals, session flaps, reads with small budgets and readers coming and going, with journals small enough to be tidied and overrun constantly, a reader that has caught up holds exactly the table's best routes. Also with writers on four threads and a reader on a fifth. The property test found one fault (a pass that resumed part-way claimed to have caught up) and catches three more put in on purpose. On the AMS-IX dump, 12 threads: loading takes 2.29 s with a follower reading throughout against 2.17 s with none, the journal peaking at 170,000 entries for 1.39 million prefixes. With a follower that does not read, the journal ends at 1.74 million entries, and the follower then catches up in 0.08 s. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
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.