Rayhaan JaufeerallyandClaude Fable 5.1
16a4e3b640
The library crates returned eyre reports, so a failure was a string and the session code could not tell a truncated UPDATE from a bad header. Whatever went wrong, the peer got an FSM error or nothing. Each crate now has its own error types: - bgp-primitives: PrefixError, UnknownAfi and UnknownSafi, and EncodeError for every to_wire. - bgp-packet: Message::decode returns a DecodeError naming the NOTIFICATION code, subcode and data for the failure (header errors per section 6.1, OPEN per 6.2, UPDATE per 6.3). InvalidValue and CommunityError replace the remaining strings. from_wire is now a thin wrapper around decode. - bgp-server: SessionError, ServerError and ConfigError. Every abnormal end of a session goes through one function that sends the NOTIFICATION the error maps to. The message length is checked against the 4096-octet maximum before the body is read. - bgp-web: serve returns io::Error. eyre remains in the binary and in tests. Bugs found and fixed on the way: - An OPEN with no optional parameters, which is valid, failed to parse. - An unsupported BGP version was reported as an unknown optional parameter. It now gets Unsupported Version Number with the version we speak as data. - A SAFI above 255 was truncated to its low octet and could match a known one. - Prefix text with a length beyond the address size (10.0.0.0/99) was accepted. - Message::to_wire truncated the body length to 16 bits before checking it. - A peer hold time above 65535 seconds in the configuration wrapped. 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.
License
Apache License 2.0; see LICENSE.