sam
0c91cad55f
The stack side is portable; the router side had no reference material -- a
new operator standing up OBMP has no guide for what to configure on their
devices to feed it. Adds two artifacts, both vendor-neutral in intent,
IOS-XR-specific in syntax:
docs/router-integration.md
Multi-path tour of the four ingest paths (BMP, BGP-LS, gNMI,
NETCONF) with a bring-up checklist and cross-references. The BMP
section is deliberately thin -- it hands off to docs/router-bmp-config.md
for the address-selection, port-choice, and RR-scope activation
detail already covered there.
router-blueprints/iosxr/*.cfg
Copy-paste config fragments, one per ingest path plus a
role-route-reflector overlay. All values are <PLACEHOLDER>
substitutions -- no hardcoded IPs, no lab-gear names. Fragments
align to the ROUTER_FACING_IP / ROUTER_FACING_PORT convention
introduced in docs/router-bmp-config.md.
router-blueprints/README.md
Substitution legend + layout, cross-links to PORTABILITY-FINDINGS.md
finding 4 (why routers can't target HOST_IP on WSL).
Also appends the multi-path guide link to the Greenfield deploy section
in README.md so router-side integration is discoverable from the top.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
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
|