Octet

How do you design management access to network devices, including when the production network is down?

Show the answer

Say this first

Keep management separate from user traffic, and add an out-of-band path that does not depend on the production network. In band: a management VLAN or VRF reachable only from admin jump hosts, with SSH, SNMPv3 and AAA. Out of band: the dedicated management ports on a separate switch, plus console servers reachable over their own circuit or an LTE link, so you can fix the network when the network is the problem.

Go deeper

In-band management

  • A dedicated management VLAN or VRF, with access restricted to jump hosts and monitoring servers.
  • SSH only, AAA with TACACS+ or RADIUS and a local fallback account, SNMPv3, syslog and NTP.
  • Restrict who can reach the device itself:
Cisco IOS
ip access-list standard MGMT-HOSTS
 permit 10.250.0.0 0.0.0.255
!
line vty 0 15
 access-class MGMT-HOSTS in vrf-also
 transport input ssh

vrf-also makes the access class apply to SSH arriving in a VRF, such as the management VRF.

Out-of-band management

  • Management ports: GigabitEthernet0/0 in the Mgmt-vrf VRF on Catalyst 9000, mgmt0 in VRF management on NX-OS, Management1 on Arista EOS. Cable them to a separate management switch.
  • Console servers connected to every console port, reachable over a separate circuit or LTE. This is what saves you when a bad change cuts off in-band access.
  • Secure it as carefully as production: it is a direct path to every device.

Why it matters

When a change breaks routing, in-band access goes with it. Out-of-band access turns a site visit or a long outage into a quick rollback.

Traps

  • Saying the management VLAN is out-of-band. It still rides the production network.
  • Leaving console servers with default credentials. They are the keys to every device.
How did you do?