Add IP Infusion OcNOS device (best-effort)

[roc-ops]

Add IP Infusion OcNOS (best-effort) and a general ansible validation action

Closes #3676.

This PR contributes two things that stand on their own but ship together because the first needs the second:

1. IP Infusion OcNOS as a new containerlab device, with configuration templates across the standard module set and state validators for the routing control plane.
2. A new, device-agnostic ansible validation action for netlab validate, so a device whose CLI cannot be driven non-interactively can still have its state read and asserted.

---

The ansible validation action

Why

netlab validate reads device state either by running a show/exec command over the node connection, or from an external source (suzieq). Both assume the platform can return command output to a non-interactive caller. Some network OSes only expose their operational data through a vendor Ansible module — their interactive CLI rejects non-interactive command execution — so neither existing path can reach them, and today such a device cannot be validated at all.

The ansible action closes that gap. It is a validation data source, a peer of netsim/cli/validate/suzieq.py — not a connection method. netsim/cli/connect.py is unchanged (byte-identical to dev); interactive netlab connect is untouched. As suggested on #3676, it is implemented as a first-class, reusable action rather than a one-off device plugin, so any platform in the same situation can adopt it.

How it works

• A device declares the module it validates through:

  netlab_validate:
    ansible_module: ipinfusion.ocnos.ocnos_command

• A test can invoke it directly in a validate entry:

  validate:
    adj:
      device: ocnos
      ansible: show ip ospf neighbor
      valid: "'Full' in stdout"

  or a device validation plugin can supply the command from an ansible_<test>() function and assert on the result in valid_<test>().
• netsim/cli/validate/ansible.py runs the module ad-hoc against the node using the netlab-generated inventory, and returns parsed JSON when the command emits it (... | json), otherwise the raw CLI text in stdout for a text assertion to match.

The action is registered everywhere a validation action is expected — the topology schema (attributes.yml), the augment/validation checks (augment/validate.py), the test and plugin dispatchers — so ansible: is accepted and executed like any built-in action, and documented in docs/topology/validate.md.

---

The IP Infusion OcNOS device

A native containerlab device driven by the ipinfusion.ocnos Ansible collection. Because OcNOS's cmlsh has no non-interactive exec mode, it uses the new ansible action for state validation (this is the concrete first consumer described above).

Module coverage

Configuration templates are provided across the standard module set:

• Addressing / base: IPv4, IPv6 (incl. link-local), device MTU, BFD
• IGP: OSPFv2 and OSPFv3 (priority, timers, cleartext/MD5 auth, default origination), IS-IS (circuit type, redistribution), RIPv2
• BGP: IPv4/IPv6 address families, local-AS, multihop, timers, authentication, standard communities, route policy
• Routing policy: static routes (incl. per-VRF), prefix lists, AS-path lists, route maps
• L2 / fabric: VLANs (L3-switch model, SVIs, native-routed trunks), LAG (LACP + static), STP (STP/RSTP/MSTP, per-port), VXLAN, EVPN (VXLAN/MPLS transport, IRB, LAG multihoming)
• Services / other: VRF (OSPFv2/BGP/IS-IS), first-hop redundancy (VRRP v2/v3), DHCP relay and client, MPLS LDP + L3VPN, Segment Routing (IS-IS, IPv4), SRv6, GRE

Module-level exceptions and platform quirks (e.g. OSPF NSSA type-7 ranges, GRE tunnel line-protocol on the 7.0 image, and DHCP relay not yet covered end-to-end on the test host) are recorded in docs/caveats.md and the per-module support tables rather than silently claimed.

State validation

Validators are provided for the modules whose assertions read state directly off the OcNOS device — OSPFv2, OSPFv3, BGP and IS-IS — following the same ansible_<test>() / valid_<test>() signatures as the FRR/EOS validators. Other modules are exercised by netlab's standard cross-device checks (reachability and neighbor state verified from the peer nodes in each integration topology), which need no device-specific validator.

---

Verification

Verified on real OcNOS containerlab topologies (vrnetlab/ipinfusion_ocnos:7.0.0-262), with an FRR node on each side of the device under test. The device-side checks below are the ones that exercise the OcNOS validators through the ansible action:

Module	Device-side checks (ansible action)	Topology total
OSPFv2	3/3 — two neighbors Full + OSPF route to a peer loopback	5/5 pass
OSPFv3	3/3 — two neighbors Full + OSPFv3 route to a peer loopback	5/5 pass
BGP	3/3 — two EBGP sessions Established + received advertised prefix	5/5 pass
IS-IS	5/5 — two adjacencies Up + L1 level checks + IS-IS route to a loopback	7/7 pass

The direct ansible: action (no plugin) was additionally confirmed end-to-end against the device.

Both the configuration the templates render and the show commands the validators parse were checked against the vendor's OcNOS-SP 7.0 CLI documentation — command forms, and the output columns the validators key on (show ip/ipv6 ospf neighbor, show ip bgp summary, show clns neighbors, show ip/ipv6 route).

---

Files

ansible validation action (core, device-agnostic)

• netsim/cli/validate/ansible.py — new validation source (peer of suzieq.py)
• netsim/cli/validate/tests.py, utils.py, plugin.py — dispatch + action registration
• netsim/augment/validate.py, netsim/defaults/attributes.yml — accept ansible: as a first-class validation action
• docs/topology/validate.md, docs/release/26.07.md — documentation

OcNOS device

• netsim/devices/ocnos.yml — device settings, feature matrix, netlab_validate.ansible_module opt-in
• netsim/ansible/templates/**/ocnos.j2, netsim/extra/**/ocnos.j2 — configuration templates
• netsim/validate/{ospf,bgp,isis}/ocnos.py + netsim/validate/ocnos.py — state validators
• netsim/ansible/tasks/{deploy-config,fetch-config,readiness-check}/ocnos.yml — device tasks
• docs/platforms.md, docs/caveats.md, docs/install/ocnos.md — device documentation
• tests/integration/platform/ocnos/ — integration topology and notes

---

Support level

OcNOS is contributed at best-effort support. I don't expect it to be part of the regular upstream integration runs; the supported-module matrix and its documented exceptions live in docs/platforms.md and docs/caveats.md, and I'm happy to maintain the device and address issues against it.

[ipspace]

Thanks a million for the PR!

Not sure what timezone you're in, so just a short comment (more later today or tomorrow): we're pretty strict about having one functionality/change per PR, as it makes things easier to track down when you're trying to figure out why something was changed.

Considering that, please submit the validation-using-ansible changes as a separate PR. Doesn't have to be anything more complex than creating a new branch, picking the relevant files from this branch into that one, and submitting that one as a PR.

Thank you, Ivan

[roc-ops]

Thanks Ivan — done. The ansible validation action is now its own PR: #3684 (closes #3676). I've retitled this one to just the IP Infusion OcNOS device. Since the OcNOS validators use that action, this branch is stacked on the action branch for now, and I'll rebase it down to dev — dropping the action files from this diff — as soon as #3684 merges. Appreciate the review, and looking forward to the rest of your comments.