Your routers. Your routing history. Standard files.

The archive public collectors cannot give you

Public archives show what a few hundred routers saw. They cannot show what your routers saw, what your inbound policy dropped, or what your network looked like last Tuesday at 03:00. Building that privately normally means assembling parsers, writers, rotators and a database before the first useful file exists.

bgpviews makes that pipeline one program with one configuration file and one output directory. The archive stays where you run it, written and read locally, with no database server and no second daemon to operate.

From BMP stream to readable archive

A router points BMP at the binary. Each client has one listening port and a source-IP allowlist. This boundary matters because BMP has no authentication of its own.

Four views remain distinct

• Adj-RIB-In pre-policy
• Adj-RIB-In post-policy
• Loc-RIB
• Filtered Loc-RIB

Pre-policy and post-policy exports are separate collectors, making policy visible as data rather than something inferred later. A record whose view is not configured is counted and left in the journal. It is never written into a different collector.

One directory existing tools already read

The output directory resembles a RouteViews collector. The Parquet catalog is a projection of the segment sidecars and can be rebuilt from them. Tombstones ensure that a deleted file is not later reported as lost.

archive/                              # one output directory
├── <client>-<view>/bgpdata/YYYY.MM/ # RouteViews layout, one collector per view
│   ├── UPDATES/updates.…HHMM.gz      # MRT, plus a sidecar JSON per file
│   └── RIBS/rib.…HHMM.gz             # derived snapshots, derivation version
├── coverage/<collector>/<stream>     # ranges: what covers what, and why not
├── sessions/<client>/<epoch>/        # every accepted BMP frame, replayable
├── catalog/                          # rebuildable Parquet projection
│   ├── segments   ├── sessions       #   peer_state, gaps, peers beside them
└── tombstones/                       # a deleted file never looks lost

One TOML file as the control plane

Behaviour lives in one TOML file. SIGHUP re-reads it. In this design the file is the whole control plane and there is no HTTP surface; the CLI is limited to running, inspection, verification and repair.

# bgpviews.toml
# One file is the entire control plane.
# The overview does not yet define TOML key names.
#
# For each client, configure:
#   * one listening port
#   * a source-IP allowlist
#
# Views come from BMP per-peer headers,
# never from this configuration file.
# Reload with SIGHUP. The file is the control plane.

bgpviews check
bgpviews run
bgpviews status

Coverage is a partition of time, and it is auditable

The archive does not report a status per interval and leave you to guess what the gaps mean. It keeps one ordered list of ranges per collector, and every instant of that collector's life falls in exactly one range. A reader can therefore tell “nothing happened” apart from “nothing was recorded”, which is the question an archive is actually asked.

Ranges are contiguous and append-only. A closed range is never edited, never split and never removed, so a coverage file that disagrees with the MRT files beside it is a verify failure rather than a silent inconsistency.

A file that is absent, expired on purpose, or failed verification is three different things, and the archive says which: missing, a tombstone, and corrupt.

Five commands, four for a healthy system

Inspect the projection with DuckDB

The catalog contains segments, sessions, peer_state, gaps and peers. Because it is Parquet in a plain directory, DuckDB can read it without a bgpviews service.

-- The overview names catalog entities, not file paths or columns.
-- This path is schematic; inspect the segment rows directly.
SELECT *
FROM read_parquet('archive/catalog/segments.parquet')
LIMIT 20;