Showing 0 products
Frequently Asked Questions
Why is out-of-band access still needed?
Because in-band tools fail exactly when they are most needed - and the failures that matter are the ones where the network or the operating system is the problem.
Remote desktop, SSH and management agents all require a working operating system and a working network path. They are excellent for routine administration and useless for a server that will not boot, a host that has lost its network configuration, or a switch that has just been locked out by a change.
Out-of-band access takes a different path entirely: a serial console, or a KVM connection that shows the screen from power-on. It reaches firmware settings, boot menus, single-user mode and the console messages that explain why something failed.
The test of an out-of-band design is whether it shares any dependency with the thing it is meant to recover. A console server on the same network as the switches it manages fails with them, and the arrangement provides nothing.
Separate network, separate power, and ideally a cellular fallback.
KVM or console server - which is needed?
Console server for network and infrastructure equipment, KVM for servers - and most sites need both.
Switches, routers, firewalls, load balancers and storage controllers all provide a serial console, and that is where their boot messages, recovery modes and password recovery procedures live. A console server aggregates those ports and makes them reachable.
Servers have graphical firmware, boot menus and operating system installers that need a screen. A KVM - or the server's own embedded management controller - is what reaches those.
In practice most modern servers include a management controller that provides remote console and virtual media over the network, which covers the KVM requirement without additional hardware. That has reduced KVM deployment substantially in server estates.
What it has not replaced is the serial console for network equipment, which is why console servers remain standard in any rack containing switches and routers.
Do embedded server management controllers remove the need for KVM?
For servers, largely yes - which is why KVM switches are now more common in specialist and industrial settings than in general data centres.
Modern servers include a management controller with its own processor, network port and power, providing remote console from power-on, virtual media, power control and hardware monitoring. That covers everything a KVM did, over the network, with no additional hardware.
Where a KVM still earns its place: equipment without such a controller, including industrial computers, appliances and older systems; environments where the controller's network access is deliberately restricted; control room and broadcast applications where operators switch between machines at a desk; and secure environments where a physically separate switching path is required.
The management controllers themselves need their own network, and that network needs to be genuinely separate from the production network - otherwise the out-of-band property is lost, which is a common design oversight.
How should out-of-band access be secured?
As tightly as anything on the estate, because it bypasses every other control - separate network, strong authentication, central directory, and full logging.
A console server or IP KVM gives direct access to the firmware and boot environment of everything it connects to. Whoever reaches it can recover passwords, alter configurations and boot from media of their choosing.
So it should sit on a management network that is not reachable from the general user network, never be exposed to the internet, use multi-factor authentication, and authenticate against the central directory so access follows employment.
Authorisation should be per port where the platform supports it, so an administrator responsible for one system cannot reach others.
Session logging is important both for audit and for diagnosis - a recorded console session captures what was typed and what the device replied, which is frequently the only record of what happened during an incident.
And change the default credentials, which on this class of equipment is a recurring finding.
What access path should be available when the network is down?
A path that shares nothing with the production network - a separate management network at minimum, and a cellular or dial-in route for a full site failure.
A management network on separate switches, separate cabling and separate power covers most scenarios: a production switch failure, a routing problem, a firewall misconfiguration. The console server remains reachable and the fault can be fixed remotely.
What that does not cover is the site losing its wide-area connection entirely, which is precisely the situation where remote access matters most.
A cellular modem in the console server, or a separate cellular router on the management network, restores access independently of the site's circuits. Many console servers include this as an option.
Dial-in over an analogue line is the traditional answer and still works where a line exists.
Whichever is chosen, test it periodically. An untested fallback path is discovered to be broken at the worst possible moment, and this is equipment that is used rarely by design.
Does out-of-band equipment need its own power protection?
Yes - it is the least useful thing in the rack if it is off during the incident it exists for.
Console servers and KVM equipment draw very little power, so protecting them is cheap. Putting them on the same protected supply as the equipment they manage is the minimum.
Better is a separate small uninterruptible supply for the management equipment, so that it outlives the main load. During an extended power event, the ability to see console messages while equipment shuts down in an orderly fashion is genuinely valuable.
Dual power supplies on the console server, fed from different circuits, are worth having on anything managing a critical estate.
The same logic applies to the management network switches and any cellular router - the whole path has to survive, and it is only as good as its weakest element.
This is one of the cheapest resilience improvements available, and among the most commonly overlooked when a rack is being built to a budget.
How many devices should one console server handle?
Enough for the rack or the row with spare ports - and it is usually better to have several smaller units than one large one.
Console servers come with 8, 16, 32 or 48 ports. Counting the devices in a rack - switches, routers, firewalls, storage controllers, appliances - usually gives a number well above what people expect.
Leave spare ports. Devices are added, and a console server with no free ports means the next device has no console path, which is exactly the one that will need it.
Distributing across several units rather than concentrating in one has two advantages: shorter cable runs, since serial cables to another rack become unwieldy, and a smaller failure domain if a console server fails.
Against that, more units means more devices to manage and secure.
A reasonable pattern is one console server per rack or per pair of racks for dense infrastructure, and one per row where the device count is lower.