66 lines
2.7 KiB
INI
66 lines
2.7 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 -> Base-1001 -> Peers Table
|