bgp

Package bgp implements the Border Gateway Protocol version 4 (BGP-4) as described in RFC 4271 and related RFCs, covering the wire format, the finite state machine, and the peering lifecycle. It is MIT licensed and written in Go. The library is organized in layers, each usable without the layers above it: - Message types such as Open, Update, and Notification, with their binary encoding. - Conn, which frames messages over a connection. - FSM, which runs the RFC 4271 finite state machine over a Conn: one session attempt per Connect call, delivering zero-copy borrowed values to handlers. - Peer, which wraps an FSM with a retry loop and handlers whose values are fully owned. - Server, which coordinates many Peers, accepting connections on shared listeners. Most callers are expected to use Peer or Server; FSM is the expert layer for callers needing zero-copy delivery or a custom retry policy. The README shows an example speaker that announces one route to a neighbor and logs received routes. Run owns the connection lifecycle: dialing, the OPEN exchange, keepalives, and retrying dead sessions until the context is canceled. Canceling the context sends Cease / Administrative Shutdown. Package examples cover multiprotocol IPv6, dual stack, passive peers, and a hardened internet-facing configuration. Scope is deliberately limited: there is no routing table and no policy engine, permanently. An established session hands received UPDATE messages to the caller, who owns all routing decisions. A RIB plugs in at the Peer layer through its handlers, wiring methods into each PeerConfig and draining its Adj-RIB-Out through the send path. Companion projects such as BMP (RFC 7854) monitoring and BFD (RFC 5880) liveness build on the same seams and live in separate repositories. Platform support: the message, Conn, FSM, Peer, and Server layers are portable Go. TCP socket options a production BGP speaker needs, such as TCP-MD5, GTSM, and DSCP, are only supported on Linux; elsewhere setting them fails with an error wrapping errors.ErrUnsupported. Testing is done against real internet routing data and real routers: corpus tests parse every message of route collector archives and every route of a full internet table, requiring a byte-for-byte marshal round trip; fuzz targets cover message parsing, attribute parsing, and connection framing, seeded from the corpus; and an interop harness runs live sessions against FRRouting, covering establishment, capability negotiation, route exchange, TCP-MD5, and GTSM.