Module bfd 

BFD speaker (RFC 5880 Asynchronous mode over UDP: RFC 5881 single-hop, RFC 5883 multihop), in the passive role: a peer that starts sending is a session request for the model; an accepted session is run in Rust (runner.rs) and every state change is the model’s to react to. Deliberately silent: BFD has no refusal, so a peer that is not accepted — or a backend failure — is never answered and its session stays Down.

Modules

actions

What the model decides for a BFD speaker: which peers get a session and with what timers, and what to do when a session changes state. The packets themselves — every few hundred milliseconds, with jitter, Poll and Final — are Rust’s job (runner.rs); a model cannot keep a 300 ms clock.

packet

The BFD Control packet (RFC 5880 §4) and its authentication section (§4.2–4.4, §6.7). Shared by the server and the client (src/client/bfd/). Everything here is pure: the session state machine is in session.rs.

runner

Runs one Session against the network: periodic transmission with jitter, the Final answer to a Poll, the Detection Time, and commands from the model or the dashboard. The server and the client each run one of these per session; the model is consulted outside it, through the Notes it sends.

session

One BFD session in Asynchronous mode (RFC 5880 §6.8): the state machine, the timers, the Poll Sequence and the authentication sequence numbers. Pure apart from the clock it is handed, so the server (passive role) and the client (active role) run the same code. Demand mode and the Echo function are not implemented: NetGet never sets the D bit and always advertises a Required Min Echo RX Interval of zero.

ttl

Receiving with the IP TTL, for RFC 5881 §5: a single-hop BFD packet whose TTL is not 255 came from more than one hop away and is discarded (the GTSM check). Tokio’s recv_from does not expose ancillary data, so this asks for IP_RECVTTL and reads it from recvmsg.

Constants

DECLINE_HOLD

A peer the model did not accept is not asked about again for this long (a Down peer sends once a second, and each packet would otherwise be a model call).

MAX_FOLLOWUP_DEPTH

How many model turns may follow from one another on one session.

SESSION_IDLE

A session that is Down with nothing heard from its peer for this long ends.

Functions

spawn