BMP (BGP Monitoring Protocol)

Configuration

BMP receiver is configured under environment { bmp { ... } } (like SSH, web, looking glass). Sender config lives under bgp { bmp { ... } }.

Receiver

The receiver listens for TCP connections from BMP-enabled routers. Configured under environment to follow ze's service listener pattern.

environment {
    bmp {
        enabled true;
        server default {
            ip 0.0.0.0;
            port 11019;
        }
        max-sessions 100;
    }
}

Multiple listeners are supported (same pattern as SSH/web):

environment {
    bmp {
        enabled true;
        server ipv4 {
            ip 0.0.0.0;
            port 11019;
        }
        server ipv6 {
            ip "::";
            port 11019;
        }
    }
}

Port conflicts with other ze listeners are detected at config commit time via the YANG ze:listener extension.

Sender

The sender connects to one or more external BMP collectors and streams ze's own BGP peer state changes and route updates.

bgp {
    bmp {
        sender {
            collector monitoring-station {
                address 10.0.0.100;
                port 11019;
            }
            route-monitoring-policy pre-policy;
            loc-rib true;
            statistics-timeout 0;
        }
    }
}

The sender reconnects automatically with exponential backoff (30s to 720s) per RFC 7854 recommendations.

CLI Commands

Protocol Details

Message Types

Ze handles all 7 BMP message types defined in RFC 7854:

Receiver Behavior

• Validates BMP version 3; rejects other versions
• Malformed BMP header closes the session; other sessions unaffected
• Malformed inner BGP messages are logged; session stays open
• Session count capped at max-sessions
• 30-second read deadline ensures clean shutdown

Sender Behavior

• Sends Initiation with sysName="ze" on each connection
• Sends Peer Up for each BGP peer reaching Established state
• Sends Peer Down with mapped reason code on session close
• Wraps received BGP UPDATEs as Route Monitoring (pre-policy, Adj-RIB-In)
• Wraps sent BGP UPDATEs as Route Monitoring with O+L flags (post-policy, Adj-RIB-Out, RFC 8671)
• Route-monitoring-policy controls which direction(s) are streamed
• With loc-rib true, streams local RIB best-path changes as Loc-RIB Route Monitoring (RFC 9069, Peer Type 3): one Loc-RIB Peer Up per RIB instance with zero-length OPENs and the local router-id as Peer BGP ID, a full-table dump, and a Loc-RIB Peer Down on shutdown

Every Connection Is a Fresh BMP Session

A BMP session carries no state across TCP connections, so a collector that connects (or reconnects after a drop) is told everything again, in this order:

1. Initiation
2. Peer Up for every BGP peer that is currently established
3. With loc-rib true: the Loc-RIB Peer Up, a full fresh table dump, and an End-of-RIB marker for every family the dump OWES (RFC 4724 Section 2 form), which is IPv4 unicast and IPv6 unicast. A family the dump carried no route for gets its marker too, so a table with IPv6 populated and IPv4 empty closes both. RFC 4724 Section 4 requires the marker "including the case when there is no update to send" for an address family, and RFC 7854 Section 5 imports that definition for the BMP dump. A Loc-RIB with no best paths at all therefore still gets both markers, so a collector can tell an empty table from a dump still in flight.

Each dump carries a correlation token, and the RIB echoes it back on every batch that dump produces. Ze closes a family only for a batch whose token matches, so two collectors that connect together each get a complete dump of their own, and neither is told that a dump it never requested has finished. A replay that another subsystem asks for (sysrib emits one on the same handle) still reaches every collector as Route Monitoring, because those routes are real, but it closes no family.

Reconnection is not immediate: after a connection ends, ze waits out its reconnect interval before redialing, so a flapping collector cannot drive a dump loop.

A Slow Collector Cannot Stall BGP

Nothing that produces a BMP message writes to the collector socket. Each message is copied into that collector's transmit queue and written by the session's own goroutine, so an unresponsive collector costs the BGP RIB a memory copy rather than a blocking write.

The queue is bounded in bytes (256 MiB per collector, sized to absorb a full Loc-RIB dump). The bound is not what catches a collector that stops reading outright: that one is caught in seconds by the drain's per-write deadline, long before 256 MiB accumulates. The bound bites for the other shape -- a collector that keeps reading, but steadily slower than ze produces -- where every individual write succeeds and it is the backlog that grows. In either case ze logs bmp: collector connection stalled, resetting session and resets the session with a plain TCP close -- no Termination message, because the session is being abandoned rather than shut down. The collector's next connection gets a complete fresh session as described above. Messages are never silently dropped: either they are delivered, or the session that owed them is reset.

Shutdown

Stopping a collector session sends a Termination message (RFC 7854 Section 4.5) and then closes the TCP connection. If a socket write is already in flight to a collector that is not reading, ze gives it one second and then closes anyway rather than delaying the shutdown of the other collectors.

Looking Glass Integration

When the BMP receiver is enabled, monitored routes are stored in the BMP RIB (a separate protocol namespace). These routes are visible through show bmp rib and looking glass endpoints but never enter BGP best-path selection or the FIB.

The route-action leaf controls future behavior: - monitor (default): store in BMP RIB for visibility only - redistribute: store in BMP RIB AND redistribute into BGP best-path (not yet implemented)

CLI

BMP routes are separate from BGP routes: ze bgp rib show excludes BMP-monitored routes, and ze show bmp rib excludes real BGP routes.

API Endpoints

The {name} parameter is the composite peer key in <router>:<peer-address> format (e.g., 10.0.0.1:12345:192.168.1.1).

Responses follow the birdwatcher format for compatibility with Alice-LG and other looking glass frontends.

Route Lifecycle

• Injection: Route Monitoring messages inject BGP UPDATE routes under bmpProtocolID with composite keys <router>:<peer-address>.
• Peer Down: All routes for the monitored peer are withdrawn.
• Session disconnect: All routes for all peers of that router are withdrawn.
• Best-path isolation: BMP routes are stored under a separate ProtocolID. The best-path algorithm only iterates BGP peers, so BMP routes are automatically excluded with zero filter code.

Limitations

• Sender OPEN messages are synthetic: the plugin event system does not carry raw BGP OPEN PDUs. Peer Up messages contain minimal OPENs built from AS metadata. Capabilities are not reflected. This can be improved when the event schema is extended.
• No per-NLRI ribout dedup: all UPDATEs are forwarded to collectors as-is. Per-NLRI dedup requires parsing NLRIs from the raw UPDATE, which is a follow-up task.
• Loc-RIB Route Monitoring (RFC 9069) omits communities and LOCAL_PREF: the best-change feed it is built from does not carry them, and RFC 9069 forbids a RIB back-door for the full attribute set.
• Route Mirroring encoding on the sender side is not implemented.