Netris — Agents & FFO Integration

How the Netris physical fabric becomes part of the Federal Frontier Ontology and the autonomous SRE agent tool surface — the fabric ontology, the Scout ingestion pattern, the Netris MCP server and its tools, and the detect-diagnose-remediate-verify loop.

Status. The Netris MCP server is deployed as v0.2.3 for the agent’s writer instance and v0.2.2 for a separate read-only instance, and both require a Keycloak token. v0.2.3 lists 39 tools: the 36 tools of v0.2.0, of which 31 are verified through MCP against Netris 4.6, plus three site ACL policy tools that are tested on a throwaway site and not counted in the 31. The read-only instance offers 15 read tools. netris_create_site (tested only on a throwaway site) and netris_delete_ip_pool are not counted in the 31, and the switch, port and BGP tools are untested because no switches are attached. v0.2.1 added a read-only mode. All results are control-plane only: no switches are attached, so no traffic has crossed the fabric yet. The FFO fabric ontology is defined and TypeQL 3.x-validated. The Scout ingestion route and the autonomous operations loop remain reference designs.

For Federal Frontier’s autonomous SRE agents to reason about the physical fabric, that fabric must exist in the platform’s living digital twin — the Federal Frontier Ontology (FFO) — and be actionable through the agent tool surface. This page describes how.

The FFO fabric ontology

The FFO network: ontology models the physical fabric as first-class entities and relationships. It is the structural half of the digital twin (slowly-changing topology and configuration), kept deliberately separate from live operational state and metrics.

Entities

Entity	Represents
`netris_controller`	The fabric controller / system of record
`fabric_switch`	A spine, leaf, or ToR switch (role, vendor, model, ASN, status)
`switch_port`	A physical port (speed, state, mode, VLANs, MTU)
`bgp_session`	A BGP session (local/remote ASN & IP, state, prefix counts, uptime)
`netris_vpc`	A tenant VPC (CIDR, tenant, isolation mode)
`dpu_policy`	A DPU isolation policy (HBN enabled, enforcement mode)

Relations

switch_connects_to · switch_has_port · port_connects_node · switch_runs_bgp · bgp_peers_with · vpc_contains_node · controller_manages · dpu_enforces_policy

The ontology follows the FFO snake_case convention and is validated against TypeDB 3.x. (Note: TypeDB 3.x derives relationships via functions rather than the rule blocks used in earlier TypeDB versions; any inference over the fabric is expressed accordingly.)

The Scout ingestion pattern

The Netris Scout is a lightweight integration route that periodically reads inventory, IPAM, topology, and BGP peer configuration from the Netris Controller API and writes that structural state to FFO through the platform’s ontology service. It does not write live operational state or metrics — those follow the data-flow discipline:

Structural state → FFO (via the Scout): topology, VPCs, DPU policy, BGP peer configuration, node membership.
Live state → agent context (via the MCP server, at investigation time): current BGP session state, current port state.
Metrics & events → Prometheus/Alertmanager: utilisation, packet loss, prefix trends, flap events.

The Netris MCP server

The Netris MCP Server wraps the Netris Controller REST API and exposes it to agents. It runs on the platform Kubernetes cluster, deployed through GitOps with Argo CD (a CNCF project), and is registered in Remuda, so agents discover its tools through the registry. Remuda forwards the writer instance’s 39 tools, read and write, through a token proxy that adds a Keycloak token. TLS verification of the controller is on for both instances, with a weekly check that alerts when the certificate expires in under 21 days, and both instances use least-privilege Netris accounts instead of an admin login: a writer account that cannot create sites, and a read-only account for the separate read-only instance. A request with no token, a malformed token or a token for another server gets 401. See Keycloak tokens on Remuda forwards.

Tool	Type	Status
`netris_health`	Read	Verified
`netris_list_tenants`, `netris_list_sites`, `netris_list_vpcs`, `netris_get_vpc`, `netris_list_vnets`, `netris_list_ipam`	Read	Verified
`netris_create_tenant`, `netris_create_vpc`, `netris_create_subnet`, `netris_create_vnet`	Write	Verified
`netris_create_site`	Write	Not counted in the 31. v0.2.3 adds a default ACL policy argument; with it, create passed end to end on a throwaway site through a temporary instance with site-admin rights. The agent’s writer account cannot create sites
`netris_get_site_acl_policy`	Read	v0.2.3. Tested on a throwaway site; on the deployed writer it read the production site’s default as permit. Not counted in the 31
`netris_set_site_acl_policy`	Write	v0.2.3. Tested on a throwaway site (deny to permit to deny; an invalid value refused). Not counted in the 31
`netris_delete_site`	Write	v0.2.3. Tested on a throwaway site. The deployed writer does not create or delete sites. Not counted in the 31
`netris_delete_vnet`, `netris_delete_subnet`, `netris_delete_vpc`, `netris_delete_tenant`	Write	Verified
`netris_list_ipam_subnets`, `netris_create_ip_pool`	Read / write	Verified
`netris_delete_ip_pool`	Write	Not yet verified through MCP; no call through MCP is recorded
`netris_list_nat`, `netris_create_nat`, `netris_delete_nat`	Read / write	Verified
`netris_list_acls`, `netris_create_acl`, `netris_delete_acl`	Read / write	Verified
`netris_list_routes`, `netris_create_route`, `netris_delete_route`	Read / write	Verified
`netris_list_l4lbs`, `netris_create_l4lb`, `netris_delete_l4lb`	Read / write	Verified
`netris_rename_vpc`, `netris_rename_vnet`	Write	Verified
`netris_list_switches`, `netris_list_ports`, `netris_list_bgp`	Read	Not yet tested: these API paths return 404 on Netris 4.6, and no switch hardware is attached

Guardrails

Guardrail	Behavior
Explicit confirmation	Every write tool refuses to run unless `confirm=true` is passed.
Overlapping prefixes	The controller rejects a subnet that overlaps an existing prefix.
Tenant in use	`netris_delete_tenant` refuses the system tenant and any tenant still used by a VPC.
Non-empty VPC	Deleting a VPC that still has objects is refused, and the tool returns the dependency order (gateway → subnet → allocation → V-Net → VPC) and the blocking objects.

Reference GPU/AI farm layout

A reference GPU/AI farm layout was built live on the controller with the server’s tool code, outside the MCP protocol:

Tenant	VPC networks
GPU tenant	GPU compute (east-west), inference serving, storage, front-end ingress, out-of-band management
Second tenant	The same layout in its own isolated VPC
Platform	Kubernetes control plane and workers (Amazon EKS or RKE2), llm-d, monitoring

The layout totals 1 site, 3 tenants, 3 VPCs and 14 V-Nets, each with its own subnet and IPAM allocation. The create and delete tools were then verified through MCP end to end by the Frontier Platform Engineering Agent.

Not yet tested: RoCE / InfiniBand east-west GPU fabrics (GPU compute is modeled as a V-Net only), NVLink partitions, and the switch inventory, port and BGP tools. These need real switch hardware.

The autonomous operations loop

Reference design. This loop depends on the BGP and port tools, which are not yet tested.

The reference scenario that ties it together — a fabric fault handled end to end:

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#0c332d','primaryTextColor':'#e6edf3','primaryBorderColor':'#2dd4bf','lineColor':'#8b949e','secondaryColor':'#11203a','tertiaryColor':'#161b22','fontSize':'14px'}}}%% graph LR A["Alert fires
(BGP session down on a leaf uplink)"] --> B["Read structural context from FFO
(which leaf, which VPC, which nodes)"] B --> C["Query LIVE fabric state via MCP
(BGP session state)"] C --> D["Diagnose"] D --> E["Policy-gated remediation
(BGP session reset — Medium risk)"] E --> F["Verify recovery"] F --> G["Write outcome back to FFO"]

Detect — an alert fires (e.g., a BGP session drops to a non-established state on a leaf uplink).
Diagnose with context — the agent reads structural context from FFO (which leaf, which VPC, which nodes are affected, what happened last time), then queries live fabric state via the Netris MCP server.
Remediate under policy — for a Medium-risk action like a BGP session reset, the agent acts autonomously; higher-risk actions are gated to human approval.
Verify & record — the agent confirms recovery and writes the outcome back to FFO as institutional memory.

This combination — FFO structural context plus live MCP queries plus policy-gated action — is what enables accurate, environment-specific autonomous operations over the physical fabric. Neither the digital twin nor live queries alone is sufficient; the design depends on using each for what it is good at.