Skip to main content

bio-rd / RIPE RIS

Plugin: netflow-plugin Module: bioris

Overview

Enrich network flows with BGP routing context received from bio-rd / RIPE RIS over gRPC. bio-rd is a Go-based BGP/BMP daemon that you run yourself. You point it at one or more BGP / BMP sources -- your own routers, a RIPE RIS Route Collector you peer with, or any other reachable BGP source -- and it exposes the resulting RIB through a gRPC interface (RoutingInformationService). Netdata is a client of that interface, not of RIPE NCC directly.

Pick this when you want a third-party / external BGP view (e.g. RIPE RIS's view of the public DFZ) without exposing a BMP listener on your agent or running BMP across your network. If your routers can speak BMP straight to Netdata, the bmp integration is simpler -- BioRIS makes sense when bio-rd is already part of your routing toolbox or when you want to peer with an external party (RIPE RIS, looking-glass) and re-export to Netdata.

BioRIS populates the same flow-record fields as BMP -- both feed a single shared in-memory routing trie. See the BMP integration card for the side-by-side comparison and combined-deployment notes.

The plugin connects as a gRPC client to one or more user-provided bio-rd ris endpoints (grpc_addr) and runs three RPCs against each one:

  1. GetRouters -- discover which routers/VRFs the bio-rd instance is exposing.
  2. DumpRIB -- pull a baseline RIB for each (router, AFI/SAFI) tuple. This is the expensive call -- full IPv4+IPv6 feeds run to millions of prefixes.
  3. ObserveRIB -- subscribe to incremental updates so the trie tracks live changes.

Per refresh cycle (default 30 minutes), the plugin re-runs GetRouters + DumpRIB, then keeps ObserveRIB streams open between cycles. Routers that disappear between refreshes have their routes purged.

Multiple ris_instances are additive, not failover -- routes from every configured endpoint merge into the same trie. The trie is also shared with the bmp integration, so if both are enabled their routes coexist and lookups pick the best match across both sources.

Connection is plain gRPC over HTTP/2 by default; set grpc_secure: true to use TLS with the system CA bundle. There is no client-cert / mTLS and no application auth -- restrict access at the network layer.

Fields populated (same set as BMP):

FieldSideSource
SRC_AS / DST_ASbothWhen the routing provider in the asn_providers chain matches
SRC_MASK / DST_MASKbothPrefix length of the longest-match BGP route
NEXT_HOPdest onlyBGP next-hop attribute from the destination route
DST_AS_PATHdest onlyFull AS path, CSV of ASNs
DST_COMMUNITIESdest onlyStandard BGP communities (CSV of u32)
DST_LARGE_COMMUNITIESdest onlyRFC 8092 large communities

Source-side AS path and communities are not surfaced; BGP path attributes are most meaningful for the destination of the traffic. AS names (SRC_AS_NAME, DST_AS_NAME) come from the GeoIP/ASN MMDB, not from BGP -- BioRIS gives you accurate AS numbers and path/community attributes; the names come from the ASN database integration.

Storage tier: DST_AS_PATH, DST_COMMUNITIES, and DST_LARGE_COMMUNITIES are written only into the raw journal tier. The 1-minute / 5-minute / 1-hour rollup tiers do not carry them. Queries that need AS path or community data must run against a window that the raw retention still covers.

This integration is only supported on the following platforms:

  • Linux

This integration runs as a single instance per Netdata Agent.

Default Behavior

Auto-Detection

Disabled by default. Set enrichment.routing_dynamic.bioris.enabled to true and provide at least one ris_instances entry.

Limits

Memory scales with the number of RIS instances, peers, routing tables, prefixes, AS paths, and communities. Full-table feeds can consume hundreds of MB per peer.

Performance Impact

Disabled until BioRIS is configured. Once active, Netdata maintains an in-memory routing trie for the received RIB and updates. Plan capacity from the number of peers and tables you import, and watch the agent's RSS.

Setup

Prerequisites

A running bio-rd 'ris' daemon

bio-rd is a separate project. The plugin only consumes its gRPC interface; it does not bundle bio-rd. You install and operate it yourself:

# Install Go (>=1.20), then:
git clone https://github.com/bio-routing/bio-rd.git
cd bio-rd/cmd/ris
go build -o /usr/local/bin/ris .

Configure ris to peer with one or more BGP / BMP sources (your own routers, RIPE RIS Route Collectors, looking-glass servers, etc.). Refer to the bio-rd documentation for the peering setup -- this is bio-rd's configuration, not Netdata's.

Run the daemon with a gRPC port: /usr/local/bin/ris --grpc_port 50051 --config.file /etc/bio-rd.yml

Network reachability + no auth

The gRPC connection is plain HTTP/2 by default, or TLS with the system CA bundle when grpc_secure: true. There is no client-cert / mTLS and no application authentication -- restrict access at the firewall, or run bio-rd on the same host as the agent and bind it to localhost.

Configuration

Options

BioRIS options live under enrichment.routing_dynamic.bioris in netflow.yaml.

Config options
OptionDescriptionDefaultRequired
enabledMaster switch.falseno
timeoutConnect + per-RPC timeout for GetRouters and ObserveRIB setup. Default is aggressive; raise to 2-5s when reaching a remote bio-rd over the public internet.200msno
refreshCadence at which the plugin re-runs GetRouters + DumpRIB for every router. Floored to 10s.30mno
refresh_timeoutPer-DumpRIB request timeout and per-message stream timeout for the baseline RIB pull.10sno
ris_instancesList of bio-rd endpoints. Each entry: grpc_addr (host:port or full http(s):// URI), grpc_secure (TLS with system CAs when true), vrf (string VRF name to filter on), vrf_id (numeric VRF ID, alternative to vrf). Multiple instances are additive (not failover) -- routes from every instance merge into the same trie.[]yes

via File

The configuration file name for this integration is netflow.yaml.

You can edit the configuration file using the edit-config script from the Netdata config directory.

cd /etc/netdata 2>/dev/null || cd /opt/netdata/etc/netdata
sudo ./edit-config netflow.yaml
Examples
Local bio-rd

bio-rd running on the same host, plain gRPC.

enrichment:
routing_dynamic:
bioris:
enabled: true
timeout: 2s
refresh: 30m
refresh_timeout: 30s
ris_instances:
- grpc_addr: "127.0.0.1:50051"
grpc_secure: false

Remote bio-rd over TLS

Across a network, system CA bundle. No client cert / mTLS.

Config
enrichment:
routing_dynamic:
bioris:
enabled: true
timeout: 5s
ris_instances:
- grpc_addr: "ris.example.internal:50051"
grpc_secure: true
vrf: "global"

Prefer BGP over the exporter's AS view

With the default provider chain, an exporter-supplied AS number wins over BGP. If your bio-rd feed is more accurate than what the exporter is stamping into flow records, reorder the chains so routing is consulted first.

Config
enrichment:
asn_providers: [routing, flow, geoip]
net_providers: [routing, flow]
routing_dynamic:
bioris:
enabled: true
ris_instances:
- grpc_addr: "127.0.0.1:50051"

Combined with BMP into a single trie

Run BMP from internal routers and BioRIS for an external (RIPE RIS) view. Both populate the same shared trie -- lookups pick the best-matching route across both sources at query time.

Config
enrichment:
routing_dynamic:
bmp:
enabled: true
listen: "0.0.0.0:10179"
bioris:
enabled: true
ris_instances:
- grpc_addr: "127.0.0.1:50051"

Default 200ms timeout too aggressive

timeout covers the gRPC connect plus the GetRouters and ObserveRIB setup RPCs. Over the public internet to a remote bio-rd, 200ms is often not enough. If you see "deadline exceeded" errors in the journal, raise to 2-5s. refresh_timeout is separate and bounds the long-running DumpRIB and per- message stream reads (default 10s).

Initial dump takes minutes for full feeds

A full IPv4+IPv6 RIB from a route collector is millions of prefixes. The first DumpRIB after enabling (or after a plugin restart) takes time -- BGP attribution is incomplete until it finishes. Subsequent ObserveRIB streams are incremental.

Plugin restart wipes the trie

The trie is in-memory only -- restarting the netflow plugin loses every learned BGP route. Convergence over BioRIS depends on the upstream feed; a full DumpRIB from a RIPE RIS Route Collector can take minutes. Schedule restarts off-peak if BGP attribution matters for your workflow.

Memory growth without bound

The trie has no time-based eviction. Routes are removed only when the upstream BGP source withdraws them, when a router disappears from GetRouters between refreshes, or on plugin shutdown. A full feed is several hundred MB of RSS per peer, permanently.

AS path / communities missing on older queries

DST_AS_PATH, DST_COMMUNITIES, and DST_LARGE_COMMUNITIES only exist in the raw journal tier. The 1m / 5m / 1h rollup tiers do not carry them. Queries that span beyond the raw retention horizon will not return BGP path data.

AS path inconsistent with the exporter's view

Different vantage points see different BGP paths. If your flow exporter and the BGP source bio-rd is peering with are different boxes with different routing tables, expect divergence. This is normal in BGP, not a bug.

Validate BioRIS enrichment after enabling

BioRIS-derived enrichment depends on the bio-rd version, upstream BGP source, route visibility, and refresh cadence. Validate against your bio-rd setup before relying on this for capacity or security decisions.


Do you have any feedback for this page? If so, you can open a new issue on our netdata/learn repository.