When the Platform Engineering Agent Touches the Underlay
With an OVN overlay, most tenant traffic needs no fabric change. The Platform Engineering Agent acts on the fabric only where traffic leaves the overlay.
Most tenant traffic never needs the physical fabric to change. With Neutron ML2/OVN, ordinary tenant networks use a Geneve overlay: the source hypervisor tunnels each VM packet across the physical network, and the destination hypervisor unwraps it (OVN architecture: tunnel encapsulations). The leaf and spine switches only forward IP traffic between hypervisors, which BGP already handles. So VM-to-VM traffic across racks needs no per-network change on the fabric.
The Frontier Platform Engineering Agent acts on the fabric only where traffic leaves the overlay or lands on a physical port. This page lists those touchpoints and their status today.
Overlay vs. underlay touchpoints
VRFs and segments · external access
ACLs · static routes · LB VIPs
physical ports · GPU fabric"] TP --> FABRIC
Touchpoints and status
Netris status labels come from live control-plane tests: the agent creates, reads back and deletes the right objects on the Netris controller. No switches are attached to that controller, so traffic through a Netris-managed fabric has not been tested yet. SONiC results, from two virtual leaves with ICMP and ARP traffic only, are noted where they apply.
| Touchpoint | What the agent does on the fabric | Status |
|---|---|---|
| Per-tenant VRF isolation | A project, or optionally a router, becomes its own fabric VRF | Netris: tested (control plane). SONiC: tested on two virtual leaves (per project) |
| Provider / VLAN or fabric EVPN segments | The segment must exist on the right leaves and extend across racks | Netris: tested (control plane): networks and subnets become fabric segments with their gateways. SONiC: tested on two virtual leaves, with traffic and isolation checks |
| External access (NAT, floating IPs) | External networks become public address pools; router gateways become source NAT; floating IPs become 1:1 destination NAT. Applies when the fabric owns L3 | Tested (control plane) |
| ACLs from security groups | IPv4 security-group rules become fabric ACLs inside the tenant’s VRF | Tested (control plane): ACLs are created but not enforced today, because the site’s default ACL policy is permit |
| Static routes | Neutron router extra routes become fabric static routes. This is the only case where the agent creates static routes, never for rack-to-rack underlay | Tested (control plane) |
| Load-balancer VIPs | Load-balancer listeners become L4 load-balancer services with a VIP | Fabric side tested (control plane) through the Netris MCP server; the OpenStack load-balancer mapping is unit-tested only |
| Bare-metal, SR-IOV, GPU and DPU switch ports | Attach and detach the server’s switch port on the segment | Netris: not yet implemented. SONiC: tested on two virtual leaves (access and tagged, from Neutron port tags) |
| GPU fabric settings | Lossless RoCE, MTU and InfiniBand partition settings across racks | Not yet implemented |
Kubernetes clusters
Kubernetes clusters built on OpenStack with Cluster API (CAPO), such as RKE2 clusters, ask OpenStack for networks, ports, floating IPs and load balancers. The agent reacts to those Neutron objects, not to Kubernetes APIs. The fabric matters for them when they use provider networks, SR-IOV for GPU traffic, or bare metal. This CAPO path has not yet been tested through the agent.
Other fabrics
The same fabric contract drives SONiC, with no controller. One OpenStack network appeared on Netris and on two virtual SONiC leaves, and 13 of 13 traffic and isolation checks passed (ICMP and ARP only, no spine or hardware). On SONiC, the agent handles VRFs, segments and switch ports; IPv6, ACLs, NAT and LAG are not built. See OpenStack to SONiC. Adapters for other switch vendors are not yet implemented.