Sam 65fd88a0a2 blueprints: fix cross-references, flag next-hop-self caveat, sync XRd timers
Review findings from verifying the router-blueprints drop against the
deployed stack:

- router-blueprints/README.md linked docs/router-config-guide.md, which
  does not exist -- the guide is docs/router-integration.md
- router-integration.md still advised --router-port 5000 for lab routers;
  1790 is the standard now, the note points at re-applying via
  cml/proxmox_bmp_config.py instead
- verify sections referenced Grafana paths that don't exist in the
  provisioned UI: 'Base-1001 -> Peers Table' -> Inventory / Peer Detail,
  and folder 'OBMP-Learning' -> OBMP-Reference
- role-route-reflector.cfg: loud caveat block on next-hop-self -- it only
  rewrites eBGP-learned/local routes (what this lab wants); reflected
  iBGP routes need 'ibgp policy out enforce-modifications', so on a pure
  RR the line is a silent no-op
- cml/xrd-node-definition.yaml BMP timers synced to the blueprint values
  (initial-delay 60, refresh 60/30, drop flapping-delay) per the
  keep-hand-config-and-automation-in-sync rule

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-20 16:49:40 -07:00

67 lines
2.8 KiB
INI

! ============================================================================
! 01-bmp-basic.cfg -- BMP session from this router to the OpenBMP collector
! ============================================================================
! Without this fragment, the stack sees nothing from this router. Everything
! else (BGP-LS export, gNMI streaming, RIB polling) is additive telemetry;
! BMP is the primary data plane the collector, kafka pipeline, and Grafana
! dashboards are built around.
!
! BMP config on IOS-XR (verified through 24.3.1) is CLI-only -- the NETCONF
! YANG models do not cover `bmp server`, so any automation must push this
! block over SSH-CLI rather than NETCONF.
!
! Two-part configuration:
! Part A: define the BMP server (one per router).
! Part B: activate BMP on the peers you want to monitor.
!
! Apply after 00-netconf.cfg. Substitute <ROUTER_FACING_IP>,
! <ROUTER_FACING_PORT>, <LOCAL_ASN>, and <MGMT_INTERFACE> for your
! topology. See docs/router-bmp-config.md for the full reference,
! including WSL-vs-native address selection, port choice, and the
! RR-scope-only activation pattern this fragment assumes.
! ============================================================================
! --- Part A: BMP server definition ------------------------------------------
bmp server 1
host <ROUTER_FACING_IP> port <ROUTER_FACING_PORT>
description OpenBMP-Collector
update-source <MGMT_INTERFACE>
initial-delay 60
stats-reporting-period 300
initial-refresh delay 60 spread 30
!
! --- Part B: activation via neighbor-group ---------------------------------
! Recommended pattern in an RR topology: activate BMP on the RR sessions
! (see role-route-reflector.cfg -- the RR-CLIENT neighbor-group there
! already includes `bmp-activate server 1`), and leave BMP OFF on the
! client-router side of those iBGP sessions. Activating on both sides
! makes the collector ingest the full table x monitored-sessions
! simultaneously, which is the biggest avoidable load driver.
!
! For sessions the RR pattern doesn't cover -- e.g. an eBGP session to a
! transit or peer you want reported directly -- use a dedicated group:
router bgp <LOCAL_ASN>
neighbor-group BMP-MONITORED
bmp-activate server 1
!
!
! Then reference the group per-neighbor:
! router bgp <LOCAL_ASN>
! neighbor <PEER_ADDRESS>
! use neighbor-group BMP-MONITORED
! ...
! !
! !
! --- Verify -----------------------------------------------------------------
! show run formal bmp
! show bmp server 1
! show bmp neighbor ! peers currently reported to the server
!
! On the stack side:
! docker logs obmp-collector 2>&1 | grep -i "peer up"
! Grafana -> OBMP-Operations -> Inventory (router appears, connected)
! Grafana -> OBMP-Operations -> Peer Detail (per-session state + prefixes)