New gobgp service: GoBGP peers eBGP-multihop with the AS57355 lab route server (Bromirski) for the full real IPv4 + IPv6 Internet table and BMP-exports it to the OpenBMP collector, landing in ip_rib as a monitored peer. Config follows the route server's published peering spec: local AS 65001, no password, keepalive 3600 / hold-time 7200, IPv4 feed on the v4 session and IPv6 feed on the v6 session. gobgp/mrt-refresh.sh is a cron-safe fallback that injects RouteViews MRT RIB dumps when the live session is down. The live BGP session is not started here — bringing gobgp up establishes the external session and loads ~1M routes. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
4.1 KiB
GoBGP global Internet table feed (roadmap E1)
This service runs GoBGP to pull the full real
Internet routing table (IPv4 ~1M + IPv6 ~200k routes) from Łukasz Bromirski's
lab route server (AS57355) and BMP-export every received route to the
OpenBMP collector. The table lands in PostgreSQL ip_rib as a monitored peer.
- Image:
jauderho/gobgp:v4.5.0— community-maintained, multi-arch, tracks upstream GoBGP releases (rebuilt within an hour of each release). Chosen because the officialosrg/gobgpimage is published less consistently. - Local AS: 65001 (private). Router-id:
10.40.40.250. - The session is receive-only — we announce nothing to the route server.
Files
| File | Purpose |
|---|---|
gobgpd.conf |
GoBGP daemon config (global, neighbors, BMP export). TOML. |
mrt-refresh.sh |
MRT full-table fallback loader (cron-driven). |
mrt/ |
Created at runtime; cached RouteViews RIB dumps. |
Bring it up
The gobgp service is defined in the repo docker-compose.yml, on the same
default compose network as collector, and depends_on it.
docker compose config # validate compose is well-formed
docker compose up -d gobgp # start (collector must be running)
docker logs -f obmp-gobgp
The live BGP cutover is performed by a human — bringing the container up is all that is needed; GoBGP initiates the eBGP-multihop sessions automatically.
Confirm the session and route count
# session state — expect both neighbors in "Establ"
docker exec obmp-gobgp gobgp neighbor
# received route counts — expect ~1M IPv4, ~200k IPv6
docker exec obmp-gobgp gobgp global rib summary -a ipv4
docker exec obmp-gobgp gobgp global rib summary -a ipv6
How the data appears in OpenBMP
GoBGP opens an outbound BMP session to obmp-collector:5000 with
route-monitoring-policy = "pre-policy" (Adj-RIB-In, pre import-policy —
consistent with the rest of the OpenBMP fleet).
In OpenBMP / PostgreSQL the source is identified by the BMP router, which
GoBGP reports using its router-id (10.40.40.250) and local-as (65001):
routerstable — a row withip_address/ name derived from10.40.40.250.bgp_peerstable — two peer rows for85.232.240.179and2001:1a68:2c:2::179, bothpeer_as = 57355.ip_rib— every prefix from the global table, attributed to those peers.
To find it in Grafana/SQL, filter on peer_as = 57355 or the router-id above.
MRT fallback
AS57355 is a single volunteer-run host with no SLA — it can and does go
away. mrt-refresh.sh keeps the global table in ip_rib warm when the live
feed is down:
- If any AS57355 session is
Established, the script does nothing — the live feed is authoritative and must not be overwritten with a stale dump. - Otherwise it downloads the latest full RIB dump from RouteViews
(
https://archive.routeviews.org/route-views/bgpdata/YYYY.MM/RIBS/rib.YYYYMMDD.HHMM.bz2, published every 2 hours UTC) and runsgobgp mrt inject global <file>, which installs every prefix into the running daemon. BMP export to the collector then happens automatically.
The script is idempotent (re-uses an already-downloaded dump), guarded by a
flock against overlapping runs, and prunes to the 4 most recent dumps.
Schedule it (host crontab, 2-hour cadence)
0 */2 * * * docker exec obmp-gobgp /config/mrt-refresh.sh >> /var/log/gobgp-mrt.log 2>&1
Run it once manually to verify:
docker exec obmp-gobgp /config/mrt-refresh.sh
Caveats
- No SLA. AS57355 is a volunteer lab route server; treat the live feed as best-effort and rely on the MRT fallback for continuity.
- eBGP-multihop TTL is set to 64 — the route server is many hops away.
- A full table is ~1M+ prefixes; expect a noticeable load spike in the collector and PostgreSQL when the session first establishes or an MRT dump is injected.