bgp adj rib in

Pre-Alpha. This page describes behavior that may change.

Per-peer Adj-RIB-In store with raw hex replay for forensic analysis and route server convergence.

Category

Storage.

Configuration

plugin {
    internal adj-rib-in { use bgp-adj-rib-in }
}

bgp {
    peer upstream {
        process adj-rib-in { receive [ update state ] }
    }
}

receive [ update state ] captures every incoming UPDATE as raw bytes, plus the peer state transitions needed to know when a session is usable.

Behaviour

The plugin stores received UPDATEs as raw hex keyed by peer and prefix. Nothing is parsed or re-encoded on the way in: the cache is the wire bytes exactly as they arrived.

Two use cases:

• Forensic replay. After an incident, dump the raw stored updates with ze cli -c "rib routes received <peer>". The bytes are identical to what the peer sent, which is the ground truth for "did this peer actually send this route".
• Route server convergence. When a peer reconnects to a route server, the server replays the stored updates from every other peer. bgp-adj-rib-in is what makes that replay possible.

The plugin also provides the validation gate for RPKI: when bgp-rpki is loaded, the adj-rib-in holds pending routes until validation returns.

Replay cursors

The replay is driven by a resume cursor, not a bookmark. The caller passes the first sequence it still wants, and the plugin returns the last sequence it delivered, so the caller must resume from one past that. A delta replay whose cursor is fed straight back re-relays its boundary route on every iteration, which is what happened until the parameter and the return value were given distinct meanings.

Replay is bounded by the route server's peer-up cut, carried as presence plus value: supplying a maximum message id of zero bounds the replay at zero, and omitting it means unbounded. Zero is the ordinary value of that cut (the route server has seen no UPDATE yet), so treating it as "no cut" made the bound fail open and delivered every UPDATE on both rails.

When the route server claims the bgp-peer-up-replay role, bgp-adj-rib-in stands its own peer-up replay down. It learns that from the Stage-2 configure callback, which completes before any peer starts. Deriving it later raced session establishment, and both plugins replaying produced byte-identical duplicate UPDATEs.

Replay carries announcements only: a withdrawal deletes the entry, so nothing is left to replay. That is why a replayed announce arriving after a live withdrawal, before the cut existed, could resurrect a withdrawn route.

Interactions

• bgp-rpki uses the plugin's validation gate to hold pending routes.
• bgp-rs reads from the plugin during the convergent replay on peer reconnect.
• bgp-rib receives the validated updates for best-path selection.

Source

main/internal/component/bgp/plugins/adj_rib_in/