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.

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/