Console Servers and Out-of-Band Management Design

An out-of-band network is a purpose-built management infrastructure whose only job is to provide access to production devices when production is broken. It is judged by how it behaves during an outage, which means the design must assume that every shared component - the in-band path, the DNS resolver, the authentication service - is unavailable at the moment it is needed.

The components and their failure paths

• Console/terminal servers connect to the serial console ports of routers, switches, firewalls and appliances, giving asynchronous access independent of the device's network stack.
• Management switches aggregate console servers and management interfaces into the OOB network.
• Management routers provide the northbound path out of the site, ideally over two physically and geographically diverse circuits.
• Management interfaces of servers and appliances (IPMI, iLO, iDRAC, CIMC) sit on the same segment as the console servers, so that console and out-of-band IP access reach the same devices.

Management devices do not need the feature set of production infrastructure. They need to be stable, simple and secure - a management switch that requires an SDN controller to forward frames is a liability.

Design rules

1. One console server per site, sized to cover every managed device in scope. Under-sizing guarantees that someone eventually patches a console cable "temporarily" into another switch, which is how unmanaged paths are born.
2. Redundant network connections. Each console server connects to both management switches, and the management routers connect to two separate northbound circuits.
3. Dual power feeds. Console servers, management switches and routers each take power from both A and B feeds. A single-PSU console server negates the entire architecture during a PDU failure.
4. No shared risk between paths. Cabling and circuits interconnecting management devices must not run through common conduit or terminate on the same line card.
5. Static addressing throughout. Every management interface on routers, switches, console servers and managed devices gets a static IP. DHCP on the OOB network means that when the DHCP server is down, the network you built for outages is unusable.
6. Separate management from production at Layer 3. Prefer a dedicated VRF and dedicated addressing, and filter management protocols so that they cannot traverse the production core.

! Core access rules for the OOB segment
- Permit management protocols only from NOC/ops subnets
- Deny east-west traffic between managed devices on the OOB segment
- Permit syslog/SNMP collection outbound to monitoring
- Deny everything else inbound, log and alert

Access paths, in order of preference

Document the escalation path explicitly: primary access over the production network, secondary access over the out-of-band network, tertiary access via console. Each should work without the previous one, and each should be tested on a schedule. A console path that has never been used since commissioning is an unverified assumption.

Hardening that is easy to skip

• Disable unused ports on management switches and place them in an unused VLAN.
• Disable outbound SSH from console servers; a console server that can initiate sessions is a pivot point.
• Centralise authentication (TACACS+ or RADIUS) but keep a local fallback account with a break-glass credential stored offline.
• Log all console access with session recording where the platform supports it, and alert on console logins outside change windows.
• Keep firmware current on console servers - they are frequently the oldest unpatched devices in a network.

Related reading: 5G and LTE branch failover for the cellular backup path, APC UPS network management card SNMP monitoring for the power layer, and HPE iLO 5 Redfish API for automating the server-management half of the same network.

原文链接：https://www.cisco.com/c/en/us/solutions/collateral/service-provider/out-of-band-best-practices-wp.html