stratumctl admin ovn

OVN substrate inspection (bootstrap-admin only)

stratumctl admin ovn [flags]

Subcommands

• stratumctl admin ovn doctor: Check the OVN substrate against its invariants
• stratumctl admin ovn reachability: Trace a path through the OVN pipeline with the full substrate view
• stratumctl admin ovn topology: Show the OVN substrate as a graph (text | mermaid | json)

stratumctl admin ovn doctor

Check the OVN substrate against its invariants

stratumctl admin ovn doctor [flags]

Evaluate the network invariants that real outages were traced to, and report each as PASS / WARN / FAIL.

Read-only. Exits non-zero when any invariant is violated, so it composes:

stratumctl admin ovn doctor && echo network-healthy

WARN means an invariant could NOT be evaluated — not that it passed. That distinction is the point: on the outages behind every green light in the system was accurate about its own narrow claim and useless in aggregate, so a check that quietly passes when it did not run would reproduce the exact problem this command exists to solve.

Where an invariant came from a known bug, the report names the ticket.

Examples

stratumctl admin ovn doctor
stratumctl admin ovn doctor --output json

stratumctl admin ovn reachability

Trace a path through the OVN pipeline with the full substrate view

stratumctl admin ovn reachability [flags]

Aliases: reach

Evaluate a packet through the modeled OVN pipeline and print every hop with the substrate detail: OVN object names, ACL and routing-policy priorities, verbatim match expressions, NAT rows.

–from and –to take an address, optionally with the port that carries it:

192.0.2.11 resolve the port from the address
192.0.2.11@lsp-guest name the logical switch port directly
192.0.2.11@nic:nic-abc123 resolve the port from a NIC id
internet anything beyond the provider network

Unlike ‘stratumctl reachability’, this surface is install-scoped: it will answer about a platform port (IMDS, the DNS recursor, a subnet probe, any tenant’s load-balancer data plane) and across projects.

–trace corroborates the verdict against the dataplane by running ofproto/trace on the chassis hosting the ingress port, and reports whether the two agree. It does NOT override the verdict: a configuration model and a flow table disagreeing is information, not an error to resolve by preferring one source. The disagreement is the finding — “the configuration says this path is open, and the dataplane on chassis n-msst0002 drops it” is a sentence nothing else here can produce.

A trace is only meaningful on the chassis hosting the port, and there is no control-plane path to run a command on a chassis this process is not. When another node owns the port the analysis says which one, and refuses rather than reading the wrong flow table.

One pipeline model backs this and the tenant endpoint, so the two cannot disagree about a path — only about how much of it they show.

Examples

stratumctl admin ovn reachability --from 192.0.2.11@nic:nic-abc --to internet --port 443
stratumctl admin ovn reachability --from 192.0.2.11 --to 192.0.2.20 --protocol icmp --trace

Flags

Flag	Type	Default	Description
--from	string		Source: <address>[@<lsp>|@nic:<id>] or ‘internet’ (required)
--port	int	0	Destination port (required for tcp/udp)
--protocol	string	tcp	Protocol: tcp, udp or icmp
--to	string		Destination: <address>[@<lsp>|@nic:<id>] or ‘internet’ (required)
--trace	bool	false	Corroborate against the dataplane with ofproto/trace on the chassis hosting the port

stratumctl admin ovn topology

Show the OVN substrate as a graph (text | mermaid | json)

stratumctl admin ovn topology [flags]

Read the OVN substrate’s logical topology from the controlplane and render it. –output controls the format:

text indented tree per VPC (default)
mermaid a graph TD block — paste into any Mermaid renderer
json raw graph (nodes + edges) for tooling

The implicit-SNAT-via-IGW row appears as a distinct node per IGW-enabled VPC — the substrate-level proof of the AWS-vs-Stratum delta documented in docs/operator/09-reference/aws-semantic-deltas.md.

Slice 2: –include-southbound queries the SB DB and adds chassis nodes + NIC→chassis edges. –include-ovs shells out to ‘ovs-vsctl show’ + ‘ovs-ofctl dump-flows br-int’ locally and attaches the result to the local chassis node. At v1 there’s one chassis; multi-chassis fan-out is.

Examples

stratumctl admin ovn topology
stratumctl admin ovn topology --vpc vpc-9k2m4x7q --include-southbound
stratumctl admin ovn topology --output json

Flags

Flag	Type	Default	Description
--chassis	string		Restrict the SB DB pass to ports + chassis matching the given OVN chassis name
--include-ovs	bool	false	Include local OVS bridge + br-int flow summary on the local chassis node
--include-southbound	bool	false	Include OVN SB DB chassis correlation + NIC→chassis edges
--vpc	string		Restrict the graph to a single VPC’s subgraph