diff --git a/README.md b/README.md index bd77960..1c385f9 100644 --- a/README.md +++ b/README.md @@ -54,7 +54,9 @@ branch + commit with the deployment. Deployment types (`--scope full-stack|remote|central-store`) are described in [docs/DEPLOYMENT-TYPES.md](docs/DEPLOYMENT-TYPES.md). Router-side BMP config: -[docs/router-bmp-config.md](docs/router-bmp-config.md). +[docs/router-bmp-config.md](docs/router-bmp-config.md); multi-path integration +(BGP-LS, gNMI, NETCONF, RR overlay): [docs/router-integration.md](docs/router-integration.md), +with copy-paste IOS-XR fragments under [router-blueprints/iosxr/](router-blueprints/iosxr/). ## Using Docker Compose to run everything diff --git a/docs/router-integration.md b/docs/router-integration.md new file mode 100644 index 0000000..189ff18 --- /dev/null +++ b/docs/router-integration.md @@ -0,0 +1,260 @@ +# Router Integration Guide + +The stack side of an OpenBMP deployment is covered by [deploy.sh](../deploy.sh) +and [setup.sh](../setup.sh) — see [DEPLOYMENT-TYPES.md](DEPLOYMENT-TYPES.md) +for the three scopes (`full-stack`, `remote`, `central-store`). This +document covers the other side: what to configure on the routers you want +to feed into it. + +The stack supports four ingest paths. This guide is the tour of all four +and the order to bring them up in. For the BMP path specifically — the +mandatory one — the detailed reference lives in +[router-bmp-config.md](router-bmp-config.md) (address selection on WSL +vs native Linux, port choice, RR-scope activation, verification). Read +this file to understand the shape, then follow router-bmp-config.md when +you actually configure BMP. + +Two artifacts per path: + +1. **Hand-config reference** — copy-paste IOS-XR fragments under + [`router-blueprints/iosxr/`](../router-blueprints/iosxr/). +2. **Automation** — for fleets, drive the same config with `ncclient` + (NETCONF) or SSH-CLI. Reference implementations for a specific lab + live under [`cml/`](../cml/) and [`exabgp/`](../exabgp/); those are + examples of the automation shape, not required. + +The two are meant to stay in sync — if you change one, mirror the other, +or the drift will surface as either a broken fleet run or a fragment that +no longer matches how you actually deploy. + +--- + +## The four ingest paths (and what each costs you if you skip it) + +| Path | What lights up if you configure it | What you lose if you don't | Mandatory? | +|-------------------|-----------------------------------------------|-------------------------------------------------------|---------------------| +| BMP session | Everything BGP: peers, RIB, churn, dashboards | The stack sees nothing. Grafana panels are empty. | Yes | +| BGP-LS export | LinkState folder: ls_nodes/links, LS Topology | LinkState dashboards are empty; Maps folder degraded. | Only for topology | +| gNMI streaming | Telemetry-3001 folder: interface counters etc | Container-level Stack Resources still works, but per-router interface telemetry is missing. | Only for interface | +| NETCONF | Programmatic config + polling automation | You can still do everything by hand on the router CLI, but there's no automation path. | Only for automation | + +Bring these up incrementally — BMP first, then layer on the others as +you use the dashboards that consume them. + +--- + +## Prerequisite: NETCONF over SSH + +Nearly every automation entry point in this repo connects with `ncclient` +over port 830 using the IOS-XR NETCONF device dialect. Turn it on first +even if you plan to configure the rest by hand — you'll want it for the +poller and any programmatic per-router queries. + +**Fragment:** [`router-blueprints/iosxr/00-netconf.cfg`](../router-blueprints/iosxr/00-netconf.cfg) + +**Credentials to align with `.env`:** +- `IOSXR_NETCONF_USER` / `IOSXR_NETCONF_PASS` — the account the automation + logs in as. Whatever you pick, create it on the router with matching + credentials and enough privilege to `edit-config`. +- `IOSXR_NETCONF_ADMIN_USER` / `IOSXR_NETCONF_ADMIN_PASS` — separate + admin-tier override for routers whose config draws from a privileged + account. + +**Verify from the stack host:** +```bash +ssh -p 830 @ -s netconf +# Expect an capability exchange, not a login shell. +``` + +--- + +## Path 1: BMP session (mandatory) → see router-bmp-config.md + +The BMP collector is what the whole stack is built around. Every router +you want visibility into opens a TCP session to it and streams its +Adj-RIB-In. + +**Full reference:** [router-bmp-config.md](router-bmp-config.md) — read +it before configuring. Covers: + +- Which address the router targets (`ROUTER_FACING_IP` from `.env`, **not + `HOST_IP`** on WSL deployments — the WSL VM's NAT address is + unreachable from real routers; see + [PORTABILITY-FINDINGS.md](PORTABILITY-FINDINGS.md) finding 4). +- Which port (`ROUTER_FACING_PORT`, defaults to 1790 — the IANA BMP port; + existing lab routers configured for 5000 need `--router-port 5000` + until reconfigured). +- The BMP `bmp server 1` block, flat formal form. +- Activation via `neighbor-group BMP-MONITORED`. +- **RR-scope-only activation** for load reduction — the single biggest + ingest-load lever in an RR topology. + +**Fragment (matches the block in router-bmp-config.md):** +[`router-blueprints/iosxr/01-bmp-basic.cfg`](../router-blueprints/iosxr/01-bmp-basic.cfg) +— substitutions and the RR-scope note are inline in the fragment header. + +**Deployment-type note:** on a `remote` collector deployment, routers +targeting *that* remote node use its own `ROUTER_FACING_IP`, not the +central-store's — the split-ingest topology (see +[DEPLOYMENT-TYPES.md](DEPLOYMENT-TYPES.md)) has each remote terminating +BMP locally and forwarding parsed data over Kafka to the central store. + +--- + +## Path 2: BGP-LS export + +Adds IGP topology visibility. The router distributes its local IS-IS +database into BGP as the link-state address family, and the RRs propagate +it. The collector's BMP session picks it up and the stack lands it in +`ls_nodes` / `ls_links` / `ls_prefixes` tables, which feed the +OBMP-LinkState folder and the LS Topology Map under OBMP-Maps. + +**Fragment:** [`router-blueprints/iosxr/02-bgp-ls.cfg`](../router-blueprints/iosxr/02-bgp-ls.cfg) + +**Three parts, applied in order:** + +1. **IS-IS `distribute link-state`** — tell the IGP to hand its LSDB to + BGP. +2. **BGP `address-family link-state link-state`** — enable the AF + globally. +3. **Per-neighbor LS activation** — activate LS toward the two RRs (on a + client router) or between RRs (on a reflector). Only peers with the + LS AF activated will exchange topology. + +**Substitutions:** +- `` — the IS-IS instance tag on this router. +- ``, ``, `` — as documented in + [router-blueprints/README.md](../router-blueprints/README.md). + +**Verify:** + +On the router: +``` +show isis database detail +show bgp link-state link-state summary +``` + +On the stack: +```bash +docker exec -i obmp-psql psql -U openbmp -d openbmp \ + -c "SELECT protocol, count(*) FROM ls_nodes GROUP BY protocol;" +``` +Grafana → *OBMP-LinkState* → *LS Topology* should render an actual graph. + +If you run OSPF instead of IS-IS, replace the `router isis ` +block with `router ospf ` + `distribute link-state`; the BGP +side is identical. + +--- + +## Path 3: gNMI streaming telemetry + +Feeds the Telemetry-3001 dashboards: interface counters, interface state, +and anything else you subscribe to. This is **dial-in** gNMI — the +stack's `obmp-telegraf` container opens a gRPC connection to each router +on port 57400 and asks it to stream OpenConfig paths on an interval. + +**Fragment:** [`router-blueprints/iosxr/03-gnmi.cfg`](../router-blueprints/iosxr/03-gnmi.cfg) + +**Router-side setup is small:** +- Enable the gRPC server on `57400`. Use `no-tls` only on a trusted + management network; provision a server cert otherwise. +- Have a user Telegraf can authenticate as — a read-only account is + fine. Values live in `.env` as `GNMI_USERNAME` and `GNMI_PASSWORD`; + create the matching user on the router. + +**Subscription paths are configured on the stack side**, not the router +— see [telegraf/telegraf.conf](../telegraf/telegraf.conf) for the exact +paths. The two currently active subscriptions are: + +| Path | Interval | What it feeds | +|---------------------------------------------------------------|----------|-----------------------------------| +| `openconfig-interfaces:/interfaces/interface/state/counters` | 10s | Interface Utilization, Errors | +| `openconfig-interfaces:/interfaces/interface/state` | 30s | Interface Utilization (oper state)| + +To add more sensors, edit `telegraf.conf` and rebuild the telegraf +container — no router-side change needed as long as the OpenConfig path +is model-supported on your platform. + +**Reachability note:** not every IOS-XR platform / release has gRPC +dial-in enabled on every VRF or every interface by default. If a router +authenticates fine over NETCONF but the Telegraf log shows a connection +refused on 57400, verify `show grpc status` locally and that management +ACLs don't drop 57400. + +**Verify:** + +On the router: +``` +show grpc status +show running-config grpc +``` + +On the stack: +```bash +docker logs obmp-telegraf 2>&1 | grep -i "connected" +``` +Grafana → *OBMP-Telemetry* → *Interface Utilization* should show per-if +lines within a couple minutes. + +--- + +## Route-reflector-only overlay + +If the router is an iBGP route reflector, also apply the RR overlay +after the base fragments. + +**Fragment:** [`router-blueprints/iosxr/role-route-reflector.cfg`](../router-blueprints/iosxr/role-route-reflector.cfg) + +Adds an `RR-CLIENT` neighbor-group with `route-reflector-client` under +both `ipv4-unicast` and `link-state link-state`, plus a `bgp cluster-id`. +Every client peer just needs `use neighbor-group RR-CLIENT`. + +The RR overlay is also where the RR-scope-only BMP activation belongs +in practice — the `RR-CLIENT` group already has `bmp-activate server 1` +in the fragment, so every client session added to the RR is +auto-monitored, while the client-router side has BMP off. See the +[router-bmp-config.md](router-bmp-config.md) discussion of activation +scope for why this matters. + +--- + +## Multi-router bring-up checklist + +For a fresh AS with two RRs and N clients, apply in this order: + +1. **All routers**: `00-netconf.cfg` (enables everything else). +2. **RRs**: `01-bmp-basic.cfg` + `role-route-reflector.cfg` (which + handles both RR-client wiring and BMP activation on reflected sessions). +3. **Clients**: `01-bmp-basic.cfg` server block only — do NOT + `bmp-activate` your iBGP session to the RR; the RR is already + monitoring the same table pre-policy. This is the load-reduction + pattern from `router-bmp-config.md`. +4. **Routers you want in topology**: `02-bgp-ls.cfg` (usually all). +5. **Routers you want streaming telemetry**: `03-gnmi.cfg`. +6. **Verify** each layer on the stack side before adding the next — don't + configure all four on all routers in one shot; you lose the ability + to correlate a failure to a specific ingest path. + +--- + +## Extending to another vendor + +The four ingest paths are all standards (RFC 7854 for BMP, RFC 7752 for +BGP-LS, gNMI 0.10.0+ for telemetry, RFC 6241 for NETCONF). The fragments +under `router-blueprints/iosxr/` are IOS-XR syntax; the *behavior* the +stack expects is vendor-neutral: + +- **BMP**: TCP session from router to `ROUTER_FACING_IP:ROUTER_FACING_PORT`, + Adj-RIB-In scope (pre-policy inbound), no monitoring type restrictions. +- **BGP-LS**: standard NLRI encoding, exported over any iBGP session. +- **gNMI**: OpenConfig models on the paths listed above; JSON_IETF + encoding. +- **NETCONF**: `edit-config` over SSH port 830 with vendor-native YANG + models — a different vendor obviously uses different modules and + scripts. + +If you deploy against Junos, EOS, or SR OS, treat the IOS-XR fragments +as a specification of *what* to configure and translate to your vendor's +syntax. A sibling `router-blueprints//` tree can be added the +same way once someone has a working end-to-end deployment to base it on. diff --git a/router-blueprints/README.md b/router-blueprints/README.md new file mode 100644 index 0000000..9c7b6d7 --- /dev/null +++ b/router-blueprints/README.md @@ -0,0 +1,60 @@ +# Router Blueprints + +Vendor-native configuration fragments that describe what a router must +present for the OpenBMP Docker stack to ingest data from it. Copy, edit +the `` values for your topology, paste. + +For the walkthrough (what each ingest path does, in what order to apply, +how to verify), see [docs/router-config-guide.md](../docs/router-config-guide.md). + +## Layout + +``` +router-blueprints/ +├── README.md <- this file +└── iosxr/ + ├── 00-netconf.cfg <- prerequisite: enable NETCONF/SSH + ├── 01-bmp-basic.cfg <- BMP session to the collector + ├── 02-bgp-ls.cfg <- BGP-LS export for topology + ├── 03-gnmi.cfg <- gNMI streaming telemetry + └── role-route-reflector.cfg <- add-on for RR-role routers +``` + +Number-prefixed fragments are applied in order for a fresh router +bring-up. `role-*.cfg` fragments are additive overlays for routers that +fill a specific role. + +## Substitutions + +Every fragment uses `` placeholders. Substitute the +following before pasting: + +| Placeholder | What it is | +|------------------------|------------------------------------------------------------------| +| `` | `ROUTER_FACING_IP` in the stack's `.env` — the address routers target to reach the collector. NOT `HOST_IP` on WSL (see [docs/PORTABILITY-FINDINGS.md](../docs/PORTABILITY-FINDINGS.md) finding 4). | +| `` | `ROUTER_FACING_PORT` in `.env` — collector port routers connect to (defaults to 1790, the IANA BMP port). | +| `` | The router's own BGP AS number. | +| `` | This router's `Loopback0` address (also its BGP router-id). | +| `` | The two route-reflector loopbacks in this router's AS. | +| `` | The router's IS-IS instance tag. | +| `` | Interface whose source IP the collector should see. | +| `` | `GNMI_USERNAME` in `.env` — the user Telegraf authenticates as. | +| `` | `GNMI_PASSWORD` in `.env`. | +| `` | `IOSXR_NETCONF_USER` in `.env` — user the automation logs in as. | + +## Vendor scope + +**IOS-XR only.** The four ingest paths themselves (BMP, BGP-LS, gNMI, +NETCONF) are standards, so the *behavior* the stack expects is +vendor-neutral — see the "Extending to another vendor" section in the +guide. Only the syntax below is IOS-XR-specific; a sibling +`router-blueprints//` tree can be added the same way once someone +has an end-to-end deployment to base it on. + +## Credentials + +Credentials come from your stack's `.env`. There is no shipped default — +whatever you set for `IOSXR_NETCONF_USER`, `IOSXR_NETCONF_PASS`, +`GNMI_USERNAME`, and `GNMI_PASSWORD` is what the fragments' user creation +blocks must match. Standardize on one account per role (read-only for +gNMI, config-capable for NETCONF) rather than reusing shell logins. diff --git a/router-blueprints/iosxr/00-netconf.cfg b/router-blueprints/iosxr/00-netconf.cfg new file mode 100644 index 0000000..f5103ef --- /dev/null +++ b/router-blueprints/iosxr/00-netconf.cfg @@ -0,0 +1,38 @@ +! ============================================================================ +! 00-netconf.cfg -- IOS-XR NETCONF/SSH enablement (prerequisite) +! ============================================================================ +! The stack's automation (rib-poller, RR diff pipeline, any +! ncclient-based configurator) connects to routers on TCP/830 using the +! IOS-XR NETCONF device dialect. If NETCONF is not enabled, none of that +! works and the BMP ingest path is the only thing that can succeed. +! +! Apply once per router before any of the other fragments. Substitute +! and its password with values that match your stack's +! .env (IOSXR_NETCONF_USER / IOSXR_NETCONF_PASS). +! ============================================================================ + +! --- SSH server (NETCONF-over-SSH transport) -------------------------------- +ssh server v2 +ssh server netconf vrf default +! + +! --- NETCONF-YANG agent ----------------------------------------------------- +netconf-yang agent + ssh +! + +! --- Local user for NETCONF (skip if you use AAA/TACACS+) ------------------- +username + group root-lr + group cisco-support + secret +! + +! --- Verify ----------------------------------------------------------------- +! show netconf-yang statistics +! show ssh +! show run formal ssh +! +! From the stack host, quick sanity check: +! ssh -p 830 @ -s netconf +! (should return an capability exchange, not a shell prompt) diff --git a/router-blueprints/iosxr/01-bmp-basic.cfg b/router-blueprints/iosxr/01-bmp-basic.cfg new file mode 100644 index 0000000..d36e2a8 --- /dev/null +++ b/router-blueprints/iosxr/01-bmp-basic.cfg @@ -0,0 +1,65 @@ +! ============================================================================ +! 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 , +! , , and 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 port + description OpenBMP-Collector + update-source + 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 + neighbor-group BMP-MONITORED + bmp-activate server 1 + ! +! + +! Then reference the group per-neighbor: +! router bgp +! neighbor +! 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 diff --git a/router-blueprints/iosxr/02-bgp-ls.cfg b/router-blueprints/iosxr/02-bgp-ls.cfg new file mode 100644 index 0000000..f564b02 --- /dev/null +++ b/router-blueprints/iosxr/02-bgp-ls.cfg @@ -0,0 +1,51 @@ +! ============================================================================ +! 02-bgp-ls.cfg -- BGP-LS export of the IGP topology to the collector +! ============================================================================ +! Feeds the OBMP-LinkState dashboards (ls_nodes, ls_links, ls_prefixes, +! LS Topology map). Enable on every router that runs IS-IS in the domain +! you want visualized; typically only the RRs need to actually SEND the +! link-state AF to the collector, but any router can distribute its local +! IGP database into BGP-LS. +! +! Three-part configuration: +! Part A: tell IS-IS to distribute the LSDB into BGP-LS. +! Part B: enable the link-state address-family in BGP globally. +! Part C: activate the link-state AF toward the collector's RR peers. +! +! Apply after 01-bmp-basic.cfg. +! ============================================================================ + +! --- Part A: IS-IS distribute link-state ------------------------------------ +router isis + distribute link-state +! + +! --- Part B: BGP address-family link-state link-state (global) -------------- +router bgp + address-family link-state link-state + ! +! + +! --- Part C: activate LS AF per-neighbor (toward the RRs) ------------------- +! On a client router, activate LS toward the two RRs. On an RR, activate +! toward its peer RR (and toward the collector's own BGP peer if present). +router bgp + neighbor + address-family link-state link-state + ! + ! + neighbor + address-family link-state link-state + ! + ! +! + +! --- Verify ----------------------------------------------------------------- +! show isis database detail +! show bgp link-state link-state summary +! show bgp link-state link-state +! +! On the stack side: +! docker exec -i obmp-psql psql -U openbmp -d openbmp \ +! -c "SELECT protocol, count(*) FROM ls_nodes GROUP BY protocol;" +! Grafana -> OBMP-LinkState -> LS Topology / LS Nodes diff --git a/router-blueprints/iosxr/03-gnmi.cfg b/router-blueprints/iosxr/03-gnmi.cfg new file mode 100644 index 0000000..595ab5e --- /dev/null +++ b/router-blueprints/iosxr/03-gnmi.cfg @@ -0,0 +1,46 @@ +! ============================================================================ +! 03-gnmi.cfg -- gNMI dial-in for the Telegraf telemetry sink +! ============================================================================ +! Enables the Telemetry-3001 dashboards (interface counters + state, and +! anything else Telegraf's cisco_telemetry_gnmi input is set to subscribe +! to). This is dial-IN telemetry: Telegraf initiates the gRPC connection +! and asks the router to stream openconfig paths on an interval. +! +! IOS-XR note: `no-tls` is only appropriate on a trusted management +! network. For any deployment reachable from an untrusted path, provision +! a server certificate and drop `no-tls` -- Telegraf's gNMI input supports +! TLS with cert verification. +! ============================================================================ + +! --- gRPC server for gNMI dial-in ------------------------------------------ +grpc + port 57400 + no-tls +! + +! --- User for Telegraf to authenticate as ---------------------------------- +! Whatever user you pick, populate GNMI_USERNAME / GNMI_PASSWORD in the +! stack's .env to match. A read-only account is sufficient. +! +! username +! group root-lr +! secret +! ! + +! --- Paths Telegraf subscribes to ------------------------------------------ +! These are configured in telegraf/telegraf.conf, NOT on the router -- +! openconfig paths are model-native, not sensor-groups. Reference only: +! +! openconfig-interfaces:/interfaces/interface/state/counters (10s) +! openconfig-interfaces:/interfaces/interface/state (30s) +! +! If you want additional sensors (LSDB size, CPU/mem), add the subscription +! block in telegraf/telegraf.conf and rebuild the telegraf container. + +! --- Verify ----------------------------------------------------------------- +! show grpc status +! show running-config grpc +! +! On the stack side: +! docker logs obmp-telegraf 2>&1 | grep -i "connected" +! Grafana -> OBMP-Telemetry -> Interface Utilization diff --git a/router-blueprints/iosxr/role-route-reflector.cfg b/router-blueprints/iosxr/role-route-reflector.cfg new file mode 100644 index 0000000..5798161 --- /dev/null +++ b/router-blueprints/iosxr/role-route-reflector.cfg @@ -0,0 +1,57 @@ +! ============================================================================ +! 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 + ! + ! 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 + ! + ! RR-CLIENT neighbor-group: applied to every iBGP client peer. + neighbor-group RR-CLIENT + remote-as + update-source Loopback0 + bmp-activate server 1 + address-family ipv4 unicast + route-reflector-client + next-hop-self + ! + address-family link-state link-state + route-reflector-client + ! + ! +! + +! Per-client wiring (repeat per client, replacing ): +! +! router bgp +! neighbor +! use neighbor-group RR-CLIENT +! ! +! ! + +! --- Verify ----------------------------------------------------------------- +! show bgp neighbors | include Route-Reflector +! show bgp summary ! all clients Established +! show bgp neighbors advertised-routes | count +! +! On the stack side (once the routers are BMP-reporting and reflecting): +! Grafana -> OBMP-Learning -> RR Loc-RIB Diff (should populate)