Rayhaan JaufeerallyandClaude Fable 5.1
d49bab58a5
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>
42 lines
1.4 KiB
Protocol Buffer Text Format
42 lines
1.4 KiB
Protocol Buffer Text Format
# A worked example; the fields are documented in
|
|
# crates/server/proto/config.proto.
|
|
router_id: "10.0.0.1"
|
|
local_asn: 65000
|
|
|
|
# Where to accept BGP connections. Port 179 needs privileges; pick another
|
|
# port to run unprivileged against a peer that dials a custom port.
|
|
listen_endpoints { address: "127.0.0.1" port: 179 }
|
|
listen_endpoints { address: "::1" port: 179 }
|
|
|
|
# A peer we connect to (and accept connections from).
|
|
peers {
|
|
name: "r1"
|
|
endpoint { address: "127.0.0.1" port: 1791 }
|
|
remote_asn: 65001
|
|
hold_time_seconds: 30
|
|
# Offer only these families to the peer. Left out, all are offered.
|
|
address_families: IPV4_UNICAST
|
|
address_families: IPV6_UNICAST
|
|
# Take several routes for a prefix from this peer, if it offers to send
|
|
# them (ADD-PATH). Also ADD_PATH_SEND and ADD_PATH_BOTH. Off by default.
|
|
add_path: ADD_PATH_RECEIVE
|
|
}
|
|
connect_retry_seconds: 5
|
|
|
|
# Let a restarted peer replace a stale Established session immediately
|
|
# (RFC 4271 CollisionDetectEstablishedState). Default false.
|
|
collision_detect_established_state: false
|
|
|
|
# Routes this router originates, announced to every peer.
|
|
originate { prefix: "10.100.0.0/16" }
|
|
originate {
|
|
prefix: "2001:db8:100::/48"
|
|
med: 50
|
|
communities: "65000:100"
|
|
large_communities: "65000:1:2"
|
|
}
|
|
|
|
# Read-only status page, JSON API and metrics. It has no authentication:
|
|
# keep it on loopback or behind a reverse proxy.
|
|
http_endpoint { address: "127.0.0.1" port: 8080 }
|