On AI Agents Speaking BGP
I guess your LinkedIn feed is as full of AI nonsense as mine is, so I usually just skip all that posturing. However, every now and then, I stumble upon an idea that makes sense… until you start to dig deeper into it.
There was this post about AI agents speaking BGP with an associated GitHub repo, so I could go take a look at what it’s all about.
The proof-of-concept (so the post author) has two components:
- A natural-language interface to BGP information (makes sense)
- A vibe-coded (so claims the author) BGP daemon with a socket interface returning information on BGP neighbors, received and sent routes.
That second part made me facepalm. We have several high-quality open-source BGP implementations1, and at least FRRouting (I haven’t tested the others) can produce the required information in easy-to-consume (for machines) JSON format, in case you think that’s easier to work with than text printouts2. Adding a REST API in front of that3 or a translation layer4 is a piece of cake. Want to have a science project? Skip the intermediate layers and write your own output module that processes the information directly from the BGP table.
Anyway, wouldn’t it be better to use a well-maintained, field-tested, pretty scalable implementation and pair it with something that adds value (natural language interface) instead of trying to prove you can reinvent a rough approximation of a wheel? Why do people feel they have to do that?
-
Plenty of IXPs are using one of them, and the Internet must be up and running, or you wouldn’t be reading this. ↩︎
-
Some people disagree because of the inevitable bloat caused by text-to-JSON expansion. ↩︎
-
Because everything needs to have a REST API to be useful ;) ↩︎
-
In case you think the LLM you’re using can work better with data formatted some other way. ↩︎
GoBGP has a good gRPC API. For a project where I needed a BGP daemon to send some routes it was a perfect match. I wrote a REST API around that to have an high level interface.
I really don't see the point of writing (well "vibe-code") a new daemon for BGP which is not a trivial protocol in my opinion.
> with a socket interface returning information on BGP neighbors, received and sent routes.
We have BMP for that.
Last I heard, Nokia SR-OS has an awesome BMP implementation ....
The way I read the BMP RFC, it's like SPAN port, but for BGP (not to mention the arcane encoding that only an IETF old-timer could appreciate 😜)
That definitely has its use cases, but in this case, I'd be looking for something that can produce responses to ad-hoc queries like "which routes from AS X do I have in the BGP table" or "who is advertising 8.8.8.0/24", preferably returned in something easy to parse like JSON.
> I'd be looking for something that can produce responses to ad-hoc queries
In the case of BMP, it is not the router that answers these queries. It is the "BMP Collector" that should be doing the answering to those queries.
With BMP the design is this:
A router sends all incoming routes to a BMP Collector.
The BMP Collector is some piece of software, running on a Unix box somewhere.
It receives all the routes, all the stats, and all the peer up/down events from one or more routers.
The BMP Collector stores all that information (in RAM, or on disk).
Then you can ask the BMP Collector (who now has all the BGP data of all the peers, all the routers, all the routes) about all the events and details you want. The BMP Collector will burn the cpu-cycles to do the queries, run the summaries, calculate averages, find specific routes and events, etc.
The whole goal of BMP is that you don't have to burn expensive resources on the router. On a router you only spend bandwidth to send the data to the Collector. The expensive stuff is done of a cheap Unix box.
Science projects get more clicks.