docs: add router-integration guide + router-blueprints/ fragments
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>
2026-07-20 16:31:06 -07:00
|
|
|
! ============================================================================
|
|
|
|
|
! role-route-reflector.cfg -- RR-specific overlay for CORE routers
|
|
|
|
|
! ============================================================================
|
|
|
|
|
! Apply ONLY on routers that act as iBGP route reflectors for their AS.
|
|
|
|
|
! Skip on the client routers -- there this overlay is a no-op at best and
|
|
|
|
|
! creates inadvertent reflection at worst.
|
|
|
|
|
!
|
|
|
|
|
! Complements 01-bmp-basic.cfg (defines the BMP-MONITORED neighbor-group)
|
|
|
|
|
! and 02-bgp-ls.cfg (which activates the LS AF toward peers). The
|
|
|
|
|
! RR-specific bit here is `route-reflector-client` under the AFs for
|
|
|
|
|
! every client neighbor.
|
|
|
|
|
!
|
|
|
|
|
! Two conventions worth preserving:
|
|
|
|
|
! - Put every RR client into a `RR-CLIENT` neighbor-group so the
|
|
|
|
|
! reflector attribute is set once at group scope.
|
|
|
|
|
! - Combine with BMP-MONITORED via `use neighbor-group` at the neighbor
|
|
|
|
|
! itself -- IOS-XR only allows one `use neighbor-group` per neighbor,
|
|
|
|
|
! so nest common bits by inheritance if you need multiple groups.
|
|
|
|
|
! ============================================================================
|
|
|
|
|
|
|
|
|
|
router bgp <LOCAL_ASN>
|
|
|
|
|
!
|
|
|
|
|
! Cluster-id -- set to the RR's loopback so RR<->RR pairs recognize each
|
|
|
|
|
! other's reflected routes and don't loop. Both RRs in a pair share the
|
|
|
|
|
! same cluster-id if you want them to act as a single logical RR.
|
|
|
|
|
bgp cluster-id <ROUTER_LOOPBACK>
|
|
|
|
|
!
|
|
|
|
|
! RR-CLIENT neighbor-group: applied to every iBGP client peer.
|
|
|
|
|
neighbor-group RR-CLIENT
|
|
|
|
|
remote-as <LOCAL_ASN>
|
|
|
|
|
update-source Loopback0
|
|
|
|
|
bmp-activate server 1
|
|
|
|
|
address-family ipv4 unicast
|
|
|
|
|
route-reflector-client
|
2026-07-20 16:49:40 -07:00
|
|
|
!
|
|
|
|
|
! *** NEXT-HOP-SELF CAVEAT *********************************************
|
|
|
|
|
! next-hop-self here ONLY rewrites the next-hop of eBGP-learned and
|
|
|
|
|
! locally-originated routes advertised to clients. That is exactly what
|
|
|
|
|
! this lab wants: the full table enters at the cores via eBGP (GoBGP/
|
|
|
|
|
! ExaBGP) and clients must resolve those routes via the RR's loopback.
|
|
|
|
|
!
|
|
|
|
|
! IOS-XR will NOT rewrite the next-hop of iBGP-REFLECTED routes unless
|
|
|
|
|
! you ALSO configure:
|
|
|
|
|
! router bgp <LOCAL_ASN>
|
|
|
|
|
! ibgp policy out enforce-modifications
|
|
|
|
|
! On a pure route reflector with no eBGP feed, this line is a silent
|
|
|
|
|
! no-op and clients must resolve next-hops via the IGP instead. Do not
|
|
|
|
|
! copy it into such a design expecting reflected-route NH rewrite.
|
|
|
|
|
! **********************************************************************
|
docs: add router-integration guide + router-blueprints/ fragments
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>
2026-07-20 16:31:06 -07:00
|
|
|
next-hop-self
|
|
|
|
|
!
|
|
|
|
|
address-family link-state link-state
|
|
|
|
|
route-reflector-client
|
|
|
|
|
!
|
|
|
|
|
!
|
|
|
|
|
!
|
|
|
|
|
|
|
|
|
|
! Per-client wiring (repeat per client, replacing <CLIENT_LOOPBACK>):
|
|
|
|
|
!
|
|
|
|
|
! router bgp <LOCAL_ASN>
|
|
|
|
|
! neighbor <CLIENT_LOOPBACK>
|
|
|
|
|
! use neighbor-group RR-CLIENT
|
|
|
|
|
! !
|
|
|
|
|
! !
|
|
|
|
|
|
|
|
|
|
! --- Verify -----------------------------------------------------------------
|
|
|
|
|
! show bgp neighbors <CLIENT_LOOPBACK> | include Route-Reflector
|
|
|
|
|
! show bgp summary ! all clients Established
|
|
|
|
|
! show bgp neighbors <CLIENT_LOOPBACK> advertised-routes | count
|
|
|
|
|
!
|
|
|
|
|
! On the stack side (once the routers are BMP-reporting and reflecting):
|
2026-07-20 16:49:40 -07:00
|
|
|
! Grafana -> OBMP-Reference -> RR Loc-RIB Diff (should populate)
|