Limitations: the capability exchange
Scheduling and the dead-man bound, from the bare-metal runs The unit now runs the engine SCHED_FIFO 60 (#26) and the dead-man bound defaults to 3 s (#25). Why, with the bare-metal numbers, and which sessions need the engine scheduled at all.
Authentication: works with FRR master since #23331
Limitations: --max-sessions, measured to 8192, and the neighbour table
Finals within a budget, packets no faster than the peer may send RFC conformance names the Poll budget as deviation 4 and the spacing as a note; Monitoring lists too-fast and changes-lost; the security model adds the churning-timer flood; Limitations has the engine at 2% for 1024.
1024 sessions, and the registration burst a released bfdd loses The engine holds 1024 sessions. A released bfdd offloads only about 58 of them per connect; #22645 on master fixes it, and the measured numbers are from master.
Rewrite the wiki as pages a reader can use The first pass moved the old README sections across as they were, which gave a Deployment page that was six caveats in a bullet list and nothing telling anyone how to deploy anything. Written properly this time, for someone arriving without the project in their head: install it, wire it to FRR in an order that works, then check the fast path is really carrying the traffic rather than trusting show bfd peer, which looks identical either way. Two new pages carry most of the value. Troubleshooting is symptom first and covers what actually goes wrong: a peer configured on one side only, the 64 session ceiling, sessions stranded by an engine restart, the three separate reasons an authenticated session never comes up, a snapshot file left behind by a previous engine, and the observer quietly stealing the XDP attach. Monitoring explains the snapshot and all eighteen counters, since a number nobody can interpret is not monitoring. Limitations is prose with the reasoning and the upstream links rather than a list of bullets.
Seed the wiki: deployment, limitations, conformance, kernels, security, testing The README was cut back to what a reader needs first. This is the rest of it: the deployment notes and the reserved-port trap, the deviations from stock bfdd and from the RFC, the kernels the object is known to load on, the threat model and the flood measurements, and what each test suite covers and needs.