Module wire 

BGP-4 wire format: encoding, decoding, and the model-facing JSON projection.

Why netgauze rather than a hand-rolled codec

Everything on this path is attacker-controlled. Capability TLVs, path-attribute flags, extended attribute lengths, the two-byte/four-byte AS_PATH ambiguity of RFC 6793 and the multiprotocol attributes of RFC 4760 are all places where a plausible-looking hand-rolled parser silently disagrees with a real router. netgauze-bgp-pkt was already a declared dependency of the bgp feature and was not used by a single line of code; it is a maintained implementation of RFC 4271 and the surrounding RFCs, so all parsing and the structurally interesting encodings (OPEN, UPDATE) now go through it.

Access is via netgauze_bgp_pkt::codec::BgpCodec, which implements tokio_util’s Encoder/Decoder. That matters for a mundane reason: netgauze’s more direct WritablePdu/ReadablePduWithOneInput traits live in netgauze-parse-utils, which is not a declared dependency of this crate, and neither is ipnet. The codec route needs only netgauze-bgp-pkt, tokio-util and bytes, all of which are already present.

Two consequences of that constraint are visible below and both would disappear if netgauze-parse-utils and ipnet were added to Cargo.toml:

• ipv4_unicast builds an Ipv4Unicast through serde instead of Ipv4Net.
• A per-message codec is constructed rather than reusing one.

What is deliberately not netgauze

KEEPALIVE and NOTIFICATION are hand-encoded. KEEPALIVE is a bare header. NOTIFICATION is a header plus two octets, and netgauze models it as a closed enum of the (code, subcode) pairs it knows, which cannot represent an arbitrary subcode. Since send_bgp_notification is an LLM-facing action taking numeric codes, hand-encoding is both simpler and strictly more expressive. Neither message has any structure to get wrong.

Structs

DecodeError

A message that could not be parsed, together with the NOTIFICATION it earns.

UpdateIntent

Everything send_bgp_update needs, already validated.

Enums

HeaderError

Why a 19-octet header was rejected, and the NOTIFICATION it earns.

Constants

AS_TRANS

RFC 6793: the reserved two-octet ASN a four-octet speaker puts in the OPEN My Autonomous System field when its real ASN does not fit.

BGP_HEADER_LEN

Marker (16) + length (2) + type (1).

BGP_MARKER

Every BGP message begins with 16 octets of ones (RFC 4271 section 4.1).

BGP_MAX_MESSAGE_LEN

RFC 4271 section 4: no message may exceed 4096 octets. RFC 8654 raises this for peers that negotiate the extended-message capability; NetGet does not advertise it, so the hard limit applies in both directions and is enforced on input before a single body byte is read.

ERR_CEASE

ERR_FSM

ERR_HEADER

ERR_HOLD_TIMER_EXPIRED

ERR_OPEN

ERR_UPDATE

MSG_KEEPALIVE

MSG_NOTIFICATION

MSG_OPEN

BGP message type octets (RFC 4271 section 4.1).

MSG_ROUTE_REFRESH

MSG_UPDATE

SUB_BAD_BGP_IDENTIFIER

SUB_BAD_MESSAGE_LENGTH

SUB_BAD_MESSAGE_TYPE

SUB_BAD_PEER_AS

SUB_CEASE_ADMIN_SHUTDOWN

SUB_CEASE_CONNECTION_REJECTED

RFC 4486 section 4: the speaker is rejecting this connection. Permanent as far as the peer is concerned — it should not treat the rejection as a transient resource condition.

SUB_CEASE_OUT_OF_RESOURCES

RFC 4486 section 8: the speaker cannot carry the peering right now for want of resources. A conforming implementation applies a damping/backoff to this subcode and retries, which is exactly the behaviour a saturated backend wants.

SUB_CONNECTION_NOT_SYNCHRONIZED

SUB_FSM_ESTABLISHED

SUB_FSM_OPENCONFIRM

SUB_FSM_OPENSENT

SUB_UNACCEPTABLE_HOLD_TIME

SUB_UNSUPPORTED_VERSION

Functions

build_open

Build our OPEN.

build_update

Build an UPDATE.

capabilities_to_json

Describe our own capabilities and the peer’s for the bgp_open event.

decode

Decode one complete BGP message (header included).

encode

Encode a message netgauze can represent (OPEN, UPDATE, KEEPALIVE, ROUTE-REFRESH).

encode_intent

Turn the validated intent produced by a send_bgp_* action into wire bytes.

encode_keepalive

A bare 19-octet KEEPALIVE (RFC 4271 section 4.4).

encode_notification

A NOTIFICATION (RFC 4271 section 4.5): header, error code, error subcode, opaque data.

error_name

Human-readable RFC 4271 section 6 error names, for logs and for the model.

error_subcode_name

ipv4_unicast

Parse a.b.c.d/len into a netgauze NLRI prefix, masking host bits.

parse_header

Validate a BGP message header without touching the body.

update_to_json

Render a decoded UPDATE as the structured JSON handed to the model.

Type Aliases

NotifyCode

A NOTIFICATION (error code, error subcode) pair.