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 replay on enable, and a Loc-RIB Peer Down on shutdown

• Sends Termination before graceful disconnect

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.