obmp-docker/docs/router-bmp-config.md

# Router BMP configuration (IOS-XR)

How to point routers at the OpenBMP collector, and which address/port they
must target depending on where the stack runs. Companion automation:
`cml/proxmox_bmp_config.py` (applies the block below over SSH to the Proxmox
lab routers) and `cml/xrd-node-definition.yaml` (bakes it into XRd images).

## What address do routers target?

**Never `HOST_IP` on a WSL deployment.** `HOST_IP` is the WSL VM's NAT
address — unreachable from physical routers and changed by `wsl --shutdown`.
deploy.sh records the correct target in `.env` as
`ROUTER_FACING_IP` / `ROUTER_FACING_PORT`:

| Stack host | Routers target | Path to the collector |
|---|---|---|
| Native Linux | `ROUTER_FACING_IP` (= host IP) : `ROUTER_FACING_PORT` | compose publishes `ROUTER_FACING_PORT:5000` |
| WSL2 | Windows LAN IP : `ROUTER_FACING_PORT` | `netsh portproxy` (Windows, same port) -> WSL -> compose `ROUTER_FACING_PORT:5000` |

On WSL the Windows-side forwarding must exist first — run
`scripts/wsl-portproxy.ps1` in an **elevated** PowerShell, and re-run it after
every WSL restart (the WSL address changes).

The router-facing port is **1790** (the IANA-registered BMP port; decided
2026-07 — the lab's historical 5000 is being retired). The collector always
listens on **5000 inside the container**; compose maps
`${ROUTER_FACING_PORT:-1790}` down to it, and setup.sh renders the same port
into gobgp's BMP export. Routers still configured for 5000 must be updated
(`cml/proxmox_bmp_config.py` applies the current values from `.env`).

## `bmp server` block

Flat formal form (submode-free, safe to paste line-by-line at `(config)#` —
the form `proxmox_bmp_config.py` applies):

```
bmp server 1 host <ROUTER_FACING_IP> port <ROUTER_FACING_PORT>
bmp server 1 description OpenBMP-Collector
bmp server 1 update-source MgmtEth0/RP0/CPU0/0
bmp server 1 initial-delay 60
bmp server 1 stats-reporting-period 300
bmp server 1 initial-refresh delay 60 spread 30
```

The `initial-refresh delay/spread` staggering matters at scale: it spreads
the full-RIB dumps out when many routers (re)connect at once, which is the
burst that sizes the whole store tier (DEPLOYMENT-TYPES.md).

## Activating monitoring on BGP sessions

BMP only reports sessions that are `bmp-activate`d:

```
router bgp <ASN>
 neighbor-group RR-CLIENT
  bmp-activate server 1
 !
!
```

**Monitor on the RRs, pre-policy, not on every client session.** In an RR
topology the same full table is reflected to every client; activating BMP on
all reflected sessions makes the collector ingest full-table x sessions
copies simultaneously. Activating on the RR side only is the single biggest
load reduction available.

## Verification

Router side:

```
show bgp bmp server 1        ! state should be ESTAB, uptime climbing
show bgp bmp summary
```

Collector side:

```
docker logs obmp-collector --tail 20        # look for ROUTER_INIT / PEER_UP
docker exec -i obmp-psql psql -U openbmp -d openbmp \
  -c "SELECT name, ip_address, bgp_id, isconnected FROM routers ORDER BY name;"
```

Grafana: the OBMP-Operations / Inventory and Peer Detail dashboards populate
within a minute of the first PEER_UP; RIB contents follow as the initial dump
is consumed (large tables take longer — watch the OBMP-Telemetry / Kafka Lag
dashboard drain).

## Troubleshooting

- **Session cycles ESTAB -> idle:** the collector accepted TCP but the
  pipeline is backpressured (Postgres write latency) — check the stack
  dashboards, not the router.
- **No TCP at all from a WSL deployment:** portproxy rule missing/stale
  (re-run `scripts/wsl-portproxy.ps1`), or Windows firewall lacks the inbound
  allow for the router-facing port.
- **Router config rejected:** IOS-XR BMP config is not in the NETCONF YANG
  schema on the lab release — apply via SSH CLI (which is why
  `proxmox_bmp_config.py` drives the CLI).