Letting an AI assistant query live BGP routing data with MCP

If you have ever debugged a routing issue, you know the drill. Something looks wrong, and you open five tabs: a looking glass, an RPKI validator, a WHOIS lookup, an IRR query, and whatever internal dashboard you trust. Then you copy AS numbers and prefixes between them until the picture makes sense.

I want to talk about a different workflow: pointing an AI assistant like Claude or ChatGPT at live routing data and asking it questions in plain language. This became practical because of two things coming together. The routing side got a self-hosted platform that exposes its data over the Model Context Protocol (MCP), and MCP itself has turned into the common way to give an assistant real, structured access to a system instead of a text box.

Here is what that setup looks like and why it is more than a party trick.

Quick refresher: what MCP actually is

Model Context Protocol is an open standard for connecting an AI assistant to external tools and data sources. Instead of pasting a wall of text into a chat, you run an MCP server that exposes a set of capabilities, and the assistant calls them like functions. The model decides what to fetch, the server returns structured results, and the model reasons over them.

The important part for our purposes: the assistant is not guessing from training data. It is querying a live system you control and getting current answers back.

The routing data problem

BGP data is scattered by nature. To answer a single question like "is this announcement legitimate," you actually need several datasets at once:

Who originates this prefix right now, from live BGP or BMP feeds
Whether that origin is RPKI valid
Who holds the address space, from IRR, WHOIS and RIR data
Whether this prefix has ever been originated from this AS before, from routing history

Each of those normally lives in a separate tool. Stitching them together by hand is slow, and it is slowest during an incident when you least want to be tab-hopping.

This is the gap Netomics is built to close. It is a self-hosted routing intelligence platform from FastNetMon that ingests live BGP Monitoring Protocol (BMP) feeds and joins them with RPKI validation, IRR, WHOIS, RIR, geofeed and ASPA data into one queryable model. The detail that makes it interesting for this post is that it ships with native MCP support, so an assistant can query that unified model directly. It was announced this month in the Netomics launch post.

What the workflow looks like

Once the MCP server is connected to your assistant, you stop thinking in tool syntax and start thinking in questions. The kind of thing you would type:

Who is currently originating 203.0.113.0/24, and is the announcement RPKI valid?

Has AS64500 ever originated this prefix before, or is this the first time?

Show me any prefixes in our address space that are being originated by an AS we do not recognize.

The assistant translates each of those into calls against the routing platform, gets structured data back, and answers with the actual current state of routing plus the context around it. Because the model can chain calls, you can go from "something looks off" to "here is the anomalous prefix, its history, and its validation status" in one conversation instead of five tabs.

A few things make this genuinely useful rather than a demo:

It is grounded. The answers come from live data, not the model's memory. If a prefix changed origin two minutes ago, that is what you see.
It is self-hosted. The platform runs inside your own infrastructure, so there are no external rate limits and no routing data leaving your network. That matters a lot when you are wiring an AI assistant into operational data.
It is scriptable beyond chat. The same platform exposes REST APIs and Prometheus metrics, so the ad hoc "ask the assistant" workflow and your automated alerting draw from the same source of truth.

Why "self-hosted" is the part that matters

Plenty of public routing lookup services exist, and they are great for one-off checks. The problem with wiring an assistant into a public service is that you inherit its rate limits, its uptime, and the question of what leaves your network. For anything you want to run continuously or against sensitive routing posture, that is a dealbreaker.

Running the intelligence layer yourself flips all of that. FastNetMon founder Pavel Odintsov described the reasoning behind the design like this: "Internet routing has become critical operational infrastructure, yet many organisations still depend on multiple external services to understand what is happening in their own networks. We built Netomics to give operators complete ownership of their routing intelligence while making it easier to troubleshoot incidents, automate workflows and improve routing security."

For a platform team, "complete ownership" is exactly the property you need before you let an automated agent read from something during an incident.

Where this goes

The interesting direction is not chat convenience. It is automated triage. Once an assistant can query live routing state with context attached, you can build workflows where an anomaly detected in your metrics kicks off an investigation that a model runs first: pull the prefix, check the origin, compare to history, check RPKI, and summarize what it found for the on-call engineer. The human still makes the call, but they start from a briefed position instead of a blank terminal.

That is the shift worth paying attention to. Not "AI replaces the network engineer," but "the boring correlation work happens before the engineer even looks," using data the engineer's own organization owns end to end.

If you work with BGP and you have been curious about MCP, this is a concrete, useful place to try it. Real routing data, real questions, no data leaving your network.

Tags: #networking #bgp #ai #mcp #devops

DEV Community