Rayhaan JaufeerallyandClaude Fable 5.1
b800e3a322
Routes were announced and withdrawn through an HTTP form, each tagged with a free-text owner and checked against an allow-list and a per-owner limit. That was the lab's interface, not a router's. Routes now come from 'originate' entries in the configuration file and are in the local RIB before any session starts. The local RIB holds one route per prefix with no notion of owners or policy. local_route_policy is gone from the configuration. The HTTP API keeps its GET endpoints (status, config, peers, originated and received routes, events, metrics). The announce, withdraw, wire-bytes and well-known-community endpoints are removed, and the status page loses the announce form, the community presets and the byte decoder. Community text parsing moves from the web crate to bgp-packet so the configuration can use it. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2.3 KiB
BGP
This crate provides the bgp binary, which runs the Border Gateway Protocol
daemon together with its read-only HTTP status interface.
cargo run -- path/to/config.textpb
The configuration format is defined in crates/server/proto/config.proto;
testdata/server.textpb is a worked example. The daemon is configured
entirely through that file: peers, and the routes it originates
(originate { prefix: ... }). There is no way to change either at runtime.
When http_endpoint is set the binary also serves:
| Path | Purpose |
|---|---|
GET /statusz |
Status page: configuration, peers and session state, originated and received routes, live event log |
GET /api/status |
Router ID, ASN, uptime and table sizes |
GET /api/config |
The configuration file as read at startup |
GET /api/peers |
Configured peers and established sessions |
GET /api/routes/local |
Originated routes |
GET /api/routes/received |
Adj-RIB-In contents |
GET /api/events |
Server-sent events for session and route changes |
GET /metricz |
Prometheus metrics |
Everything under it is read-only and unauthenticated. Bind it to loopback or put it behind a reverse proxy.
What it does today
It establishes sessions (both dialling configured peers and accepting connections, with RFC 4271 collision detection), announces its originated routes to every peer with itself as next hop, and records what peers send in an Adj-RIB-In. It does not select best paths, re-advertise received routes or program a forwarding table, and it has no import or export policy.
Trying it without a router
fake_peer is a minimal BGP speaker that connects to the daemon, announces a
prefix, prints every UPDATE it receives and, with --echo, re-announces each
received prefix back with its own ASN prepended (dropping NO_EXPORT routes).
That makes originated prefixes show up in the received table as if they had
travelled through a neighbouring AS:
cargo run -- testdata/server.textpb
cargo run -p bgp-integration-tests --example fake_peer -- \
--server 127.0.0.1:179 --asn 65001 --announce 203.0.113.0/24 --echo
Please refer to the other implementation crates in this repository where most of the actual implementation lives.
Warning: This is still very much a work in progress and is not yet ready for production use.