The OPEN used to offer IPv4 and IPv6 unicast unconditionally, and what the peer offered was ignored apart from its four-octet AS number. Address families (RFC 4760): - A peer's `address_families` in the configuration says which to offer it; all of them by default. - A session carries the families both OPENs offered. A peer that sends no Multiprotocol capability is a plain RFC 4271 speaker: IPv4 unicast. - Routes of a family that was not negotiated are not sent, and are ignored when received; the rest of the UPDATE is applied and the session stays up. - A session with no family in common is refused with Unsupported Capability, naming the capabilities we needed (RFC 5492). - The negotiated families are shown on /statusz and in /api/peers. Bugs found on the way: - A capability naming an address family we have no constant for (EVPN, VPNv4, ...) failed the whole OPEN, so such a peer could never establish. It is now kept as an unknown capability and ignored. - An UPDATE could not be encoded for a peer without four-octet AS support, which ended the session on the first route. AS_PATH is now written two octets wide with AS_TRANS where needed, and AS4_PATH carries the real numbers (RFC 6793). 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.