AI, Ontology and Networking
Today, we have a very powerful AI. It can read an RFC, write a config, and explain a routing table. What it cannot do — not reliably yet — is{" "} understand your network. A language model that has never seen your topology will happily invent an fake interface name, attach a metric to the wrong side of a link, and describe the result with total confidence.
So the interesting question is not "can AI configure a router?" It is:{" "} what does an AI need to be given, so that modifying a router configuration becomes a safe, validatable act?
The isis-flexalgo-ai playset in{" "}
zebra-rs{" "}
is an attempt at an answer. It is a small, fully virtual IS-IS network — a
handful of nodes, a few deliberately asymmetric links — plus an agent that is
asked, in plain language, to make traffic behave differently. Not by editing
configuration files directly, but by reasoning over a model of the network and
then emitting intent.
The loop has three parts: understand the network,{" "} decide the routing with intent,{" "} validate it happened.
Visualization & Ontology
Before an agent can change a network, it first has to understand the network it is acting on. That means obtaining the individual properties of the nodes and links a router holds, along with the topology information describing how each node connects to the others through those links.
We deliberately did not take the traditional route of reconstructing this from router configurations, nor of generating it from the raw output of routing protocols (the IS-IS or OSPF LSDB, for example). Instead, we exposed a set of higher-level MCP APIs:
| Tool | Description |
|---|---|
{tool} |
{desc} |
With this information, we can get a graph information. Here is a visulization of this phase.
isis-flexalgo-ai topology as the agent sees it — 11 nodes across US / EU / AP, IS-IS metric on every link. Drag a node to reposition it.
We can see how each node is connected, but we are missing physical location and region information. The last layer which fill in the gap is ontology. Here is a{" "} ontology.json{" "} which we feed to the understanding the network.
{ONTOLOGY_JSON}Combining the live node and link state read from the routers with the physical location and region carried in the ontology, we get a visualization grounded in the real world rather than an abstract graph — shown below.
Visualization is the same model rendered for humans. The topology drawing is not documentation produced alongside the network — it is the ontology, drawn. When the agent says, "I will avoid the red link," the operator can look at exactly the same graph and understand that the agent intends to avoid the Tokyo–San Jose link.
The link seen by the agent and the link seen by the operator refer to the same underlying entity, while the ontology provides both of them with access to a richer layer of contextual information.
Sovereign Routing with Intent
The scenario is sovereign routing: some traffic must stay inside a defined boundary, even when the shortest path leaves it.
Classic IS-IS gives one answer per destination — the same SPF result, the same metric, for every service. If the cheapest path crosses a link you would rather avoid, the options are blunt: raise the metric and distort routing for everyone, or build a parallel overlay and maintain it forever.
IS-IS Flexible Algorithm (RFC 9350) removes that constraint. The domain agrees on a set of numbered algorithms, each with its own{" "} Flex-Algorithm Definition (FAD): which metric to optimize (IGP cost, TE metric, or minimum unidirectional delay), which links to exclude by affinity colour, and which links to require.
We can have different policy routing dicision in SPF=128.
Now, let's try something a little more challenging. Suppose we want to configure the network so that it does not use any links crossing the Pacific Ocean.
Traditionally, we would be required to do the following:
- Identify, one by one, which links cross the Pacific with ontology information.
- Assign an affinity value to each of those links on the relevant routers.
- Configure SPF=128 to compute a routing table that avoids those links.
If we were not familiar with how to configure the target routers, we would also need to learn the required configuration syntax on the fly. On top of that, we would need to verify that the resulting configuration is correct.
Today, all of these steps can be carried out by giving Claude Desktop the following prompt.
{`Constrained traffic may not cross trans-Pacific links. Design and deploy an IS-IS Flex-Algorithm on every router of this lab that enforces it, then prove it worked. Configuration example can be found here: https://zebra.rs/docs.html#ch-07-11-isis-flexalgo`}
The agent's job is not to translate English into CLI. It is to resolve that prompt against the model — find which colour encodes the trans-Pacific links, confirm that a compliant path actually exists, notice which nodes must participate for the constraint to hold end to end — and only then emit a FAD. The output is small: an algorithm number, a metric type, an exclude-affinity rule, and the set of nodes that must participate. The reasoning behind it is the expensive part, and it is reasoning the model can only do because the network was handed to it as knowledge rather than as text.
Two failure modes disappear here. The agent cannot reference a link that does not exist, because it is selecting from the graph. And it cannot silently strand a destination, because "is every node reachable under this FAD?" is a question that can be asked of the model before anything is committed.
Validation Loop
The router configuration may also fail. In that case, AI investigate the cause and repeat the process until the correct configuration is successfully applied.
Even agent successfully configures routers and then declares success is worse than no agent at all. The final piece of the playset is the part that refuses to take the model's word for it.
After the configuration is applied, the AI runs the following loop against the live system:
-
{VALIDATION_STEPS.map(([q, a]) => (
- {q} {a} ))}
Each check produces a verdict the operator can read without trusting the agent's narration. Where the observed state and the intended state diverge, the difference is reported as a difference — not smoothed over in prose.
And because the whole environment is virtual, the loop can run before anything touches production. The agent proposes, the playset builds the topology, applies the intent, measures the result, and reports. If the FAD partitions the network, that is discovered in a container, not in an outage.
This is the shape of the argument. AI does not become useful in networking by getting better at generating configuration. It becomes useful when the network is expressed as something it can reason over, when the operator's intent maps onto a mechanism precise enough to carry it — Flex-Algo, here — and when every claim it makes is answerable by the network itself.