A firmware update on a branch firewall goes wrong. The firewall stops passing traffic, and that takes down the VPN the support team would normally use to log in and roll the update back. They know what needs undoing but have no way to reach the device.
From there, the options are limited. Someone drives to the site, or someone at the branch gets talked through plugging in a console cable over the phone. The site stays down until the fix is made, and the cost keeps building: staff who can’t work, systems offline and an engineer’s day spent travelling.
Out-of-band management means the team doesn’t have to make that trip.
What is out-of-band management?
Out-of-band (OOB) management is a separate, independent route into network devices such as routers, switches, firewalls and servers. It usually connects to each device’s console port, which is the port an engineer would plug a laptop into when standing at the rack.
Most day-to-day management is in-band. Engineers reach devices over the production network using SSH, a web interface or a management platform. That works well until the network itself is the problem. If a misconfigured switch, a failed WAN link or a crashed firewall takes the network down, in-band access goes with it.
OOB access doesn’t depend on the production network, so it’s still there when in-band access isn’t. Engineers can check what a device is doing, change its configuration, restart it or roll back an update from wherever they are.
How does out-of-band management work?
The main part of an OOB setup is a console server. It sits in the rack alongside the equipment it manages, with a cable from each of its ports to the console port on a router, switch, firewall or server. Many newer devices have USB console ports, which modern console servers also support.
The console server then needs its own connection out. That’s usually a dedicated Ethernet line kept separate from the production network, a cellular connection or both. If the main network fails, the console server can still be reached, and so can every device plugged into it.
An engineer connects securely to the console server and opens a session to the device they need. They get the same access they’d have with a laptop on site.
Why it matters to your customers
Fewer site visits. Many faults that would otherwise mean sending someone to site can be fixed remotely, such as a bad configuration change or a failed firmware update.
Faster recovery. The fix can start as soon as the fault is spotted rather than when an engineer arrives. At a remote site, that can bring an outage down from hours to minutes.
A fallback for planned work. OOB isn’t only for emergencies. Engineers can make changes to live equipment knowing they can still get in if something goes wrong.
Tighter control over access. Keeping management access off the production network limits who can reach management interfaces, and access through the console server can be authenticated and logged.
Many customers will remember an outage they couldn’t fix remotely, which makes OOB an easy subject to bring up.
Where out-of-band management is used
Data centres
Racks of switches, servers and storage need to stay reachable even when the data centre network has a problem. With OOB, engineers can do that without waiting for remote-hands support.
Branch offices and retail estates
Some organisations have dozens or hundreds of sites with little or no IT staff at any of them. One failed router can take a store’s payments offline or cut off a branch, and sending an engineer to every incident gets expensive quickly.
Remote and unmanned sites
Telecoms cabinets, utility substations and similar locations are often a long way from the nearest engineer, with nobody on site to help. Cellular OOB is particularly useful at these sites because fixed-line options may be limited.
Campuses
Universities, hospitals and large corporate sites have network equipment spread across many buildings and comms rooms. OOB saves engineers from going from building to building to fix faults.
Critical infrastructure
In energy, transport and healthcare networks, downtime affects more than productivity. These sectors often also need a clear record of who accessed which device and when.
Modern OOB with the Lantronix SLC 9000 and Percepxion
Console servers have been part of network design for decades. Current platforms such as the Lantronix SLC 9000 add features that make OOB much easier to deploy and run across many sites.
The SLC 9000 supports up to 48 managed ports, with RJ45, USB and Ethernet options. It also has dual Gigabit Ethernet with failover and two SFP+ ports. For cellular failover, it pairs with an external 5G modem. That gives the console server its own cellular route, so it doesn’t rely on the site’s broadband or a shared 5G router.
The SLC 9000 also supports zero-touch provisioning. When a new unit is powered up, it calls home over the network or cellular, pulls its configuration and updates its firmware to match policy. It also identifies the equipment connected to its ports. For a multi-site rollout, that means the units can be installed without an engineer visiting each site to configure them.
Percepxion is Lantronix’s management platform, available as a SaaS platform or on-premises. It brings a fleet of console servers into one dashboard, where teams can back up configurations, spot configuration drift, track firmware compliance and review audit logs. MSPs can see all their customers’ devices from one place.
For teams that automate their network operations, every SLC 9000 operation is available through a REST API. Lantronix also provides a certified Ansible collection and integrations with Terraform, NetBox and ServiceNow, so OOB works with the tools engineers already use.
If you’re specifying OOB for a customer, we can help you choose the right SLC 9000 model and port count, decide whether cellular failover is needed and plan how Percepxion fits in. We can also support pricing, availability and delivery for rollouts across multiple sites.
FAQs
What does out of band mean?
In networking, “out of band” means using a separate channel from the main data traffic. In management terms, it’s a route to devices that doesn’t rely on the production network.
What’s the difference between in-band and out-of-band management?
In-band management reaches devices over the production network, so it only works while that network is working. Out-of-band management uses a separate path, usually a console server with its own Ethernet or cellular connection, so it stays available during outages.
Do I need OOB if I have SD-WAN?
SD-WAN routes traffic across a site’s WAN links and can fail over between them, but it’s still part of the production network. If the SD-WAN appliance fails, is misconfigured or loses all its links, remote access to it can go too. OOB gives you a separate way in to fix it, so the two do different jobs.
What is a console server?
A console server connects to the console ports of network equipment and makes them reachable remotely. It’s the main building block of an out-of-band management setup, and you may also see it called a console manager or terminal server.
Talk to us about out-of-band management
If you have a customer with remote sites, a growing branch estate or a recent outage they couldn’t fix remotely, speak to us about Lantronix. We can help you specify the right OOB setup and support pricing, availability and delivery.
