Certified Ansible collection
lantronix.oob 1.2.0 is certified and published on Red Hat Automation Hub, with 22 modules covering Percepxion fleet work and direct SLC 9000 management.

By role
Your automation can't build the network if it needs the network to run. The SLC 9000 gives playbooks a management path on day zero, and the certified lantronix.oob collection, two REST APIs and two MCP servers keep OOB in your existing toolchain.
Capabilities
lantronix.oob 1.2.0 is certified and published on Red Hat Automation Hub, with 22 modules covering Percepxion fleet work and direct SLC 9000 management.
The SLC 9000 has a REST API (version 2.0) for configuration and operations. Percepxion has its own REST API, including a fully queryable event log.
The Percepxion MCP server has 38 tools for fleet-scale work. The SLC MCP server has 33 tools for a single unit. Point any MCP-compatible client at either one.
SLC 9000 firmware exposes no shell. Containers run sandboxed at 256 MB of memory and one CPU core, so an agent can sit next to the gear without touching port performance.
Over the console server. A new rack has no routed production network on day zero, but the SLC 9000 is already on its own uplinks and registered to Percepxion over an outbound-only MQTT connection. Every console in the rack is reachable before anything behind it has an IP, which means automation can build the network instead of riding on top of it.
Smart Groups do the first pass. A new console server calls home, Percepxion matches it to a group, and that group’s firmware and configuration land without anyone touching it. Your playbooks pick up from a known baseline.
An Ansible collection, two REST APIs and two MCP servers. That’s the whole list, and each piece talks to an API rather than a terminal.
Plain SSH still works for scripts that need it. Console port N answers on TCP 3000+N.
Hand them to the appliance and the platform. For Cisco IOS and IOS-XE devices defined as managed devices, the SLC 9000 runs config pulls and pushes, health checks and interface actions on a schedule, on the console server itself. Console access stays vendor-neutral for the rest of the rack.
Percepxion covers the fleet side. It schedules jobs across every console server, manages firmware, applies config templates, and backs up and restores appliance configuration. Your pipeline calls those jobs. It doesn’t reimplement them.
For anything that has to live next to the gear, the SLC 9000 runs containers in a sandbox capped at 256 MB of memory and one CPU core. There’s no shell on the firmware, so a container is the supported place for a collector or an agent, and it can’t starve the console ports.
The end state is simple. Out-of-band stops being a parallel manual system and becomes one more target in the same repo, reviewed and versioned like everything else you ship.
Questions
From Red Hat Automation Hub. lantronix.oob 1.2.0 is certified there and contains 22 modules.
Use Percepxion's (38 tools) for anything across the fleet. Use the SLC MCP server (33 tools) when you're working one console server, like lab testing or building a config.
Query the Percepxion event log through the REST API on a schedule and route it through your own integration layer. The API is the integration point.
No. The SLC 9000 registers to Percepxion device-side first over an outbound-only MQTT connection.
The Product Selector opens with this page's filters applied. Add models to My List, then export it or email it for a quote.
Find an SLC 9000 for your pipeline