! ============================================================================
! 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)