Skip to content
Log in Sign up My account

4.3 Network Management Design

Blueprint 4.3: Network management techniques

  • 4.3.a In-band versus out-of-band management
  • 4.3.b Segmented management networks
  • 4.3.c Prioritizing network management traffic

Management traffic is how you reach a device when something is wrong. A management design therefore has to answer one question first: what happens to management access when the production network fails? Everything on this page follows from that. The protocol details are in ENCOR device access, ENARSI SNMP and ENARSI logging.

What is being managed

Traffic Direction Notes
SSH, console, HTTPS to device Admin to device Interactive, low volume
SNMP polling and traps, streaming telemetry Both Polling is periodic; telemetry can be heavy
Syslog Device to collector Bursty during failures
NetFlow and IPFIX Device to collector Volume depends on sampling
TACACS+ and RADIUS Device to server Needed for login
NTP, DNS, TFTP/SCP software images Both Image transfers are large
Controller traffic (Catalyst Center, SD-WAN Manager) Both NETCONF, REST, gRPC

4.3.a In-band versus out-of-band

In-band management reaches devices over the same network that carries user traffic, normally through a loopback address. Out-of-band (OOB) uses a separate path: a dedicated management network, a console server or a cellular link.

In-band Out-of-band
Cost Low, no extra infrastructure Higher, extra switches, links, console servers
Works during production failure No (fails with the network) Yes
Security exposure Management shares the production attack surface Smaller, can be isolated
Bandwidth contention Competes with users None
Typical use Branches, access layer Data centres, core, WAN edge, critical sites
graph TB
  ADM["Admin / NMS"] --- OOB["OOB management switch"]
  OOB ---|"Mgmt Gi0/0"| R1["Core / WAN router"]
  OOB ---|"Console server"| R1
  ADM -.->|"In-band fallback<br/>via loopback"| PROD["Production network"]
  PROD --- R1
  LTE["LTE / 5G modem"] -.-> OOB

A practical enterprise answer is hybrid. Critical sites (data centre, headquarters core, WAN hubs) get a dedicated OOB network with a console server and cellular backup, because these are the devices you must reach during an outage. Branches and the access layer use in-band management, because the cost of OOB at hundreds of small sites outweighs the benefit. OOB also protects against self-inflicted outages: a bad ACL or routing change can lock you out of in-band access, whereas a console server with a separate path lets you roll back.

A common mistake is an OOB network that quietly depends on production. If the OOB switch gets its DHCP, DNS, AAA or authentication from a server reachable only over the production network, the OOB path fails when it is needed most. Give OOB its own AAA, NTP, logging and DNS dependencies, or at least a local fallback account and reachable servers.

Exam trap

A console server is only out-of-band if its uplink is out-of-band. A console server that connects through the production network provides convenience, not resilience.

4.3.b Segmented management networks

Management systems and device management interfaces are high-value targets. Segmenting them limits who can reach them and what an attacker can do after a compromise.

Common techniques:

Technique What it does Notes
Dedicated management VLAN and subnet Separates management from user traffic Do not use VLAN 1 or the native VLAN
Management VRF (Mgmt-vrf) Isolates the device's management interface in its own routing table Catalyst switches ship with a dedicated Gi0/0 management port in Mgmt-vrf
VRF-Lite or VN for management Carries management across the campus in a separate routed segment See VRF-Lite
Firewall-controlled zone Management servers sit in a protected DMZ-style zone Only required protocols are allowed to devices
Jump host or bastion One hardened point for administrative access Records sessions, enforces MFA
Loopback as source Fixes the source address for SNMP, syslog, TACACS+ and NTP Makes ACLs and firewall rules predictable
vrf definition Mgmt-vrf
 address-family ipv4
 exit-address-family
!
interface GigabitEthernet0/0
 vrf forwarding Mgmt-vrf
 ip address 10.250.1.11 255.255.255.0
!
ip ssh source-interface GigabitEthernet0/0
logging host 10.250.9.20 vrf Mgmt-vrf
ntp server vrf Mgmt-vrf 10.250.9.30
snmp-server host 10.250.9.20 vrf Mgmt-vrf version 3 priv NMS-USER
!
ip access-list standard MGMT-ONLY
 permit 10.250.9.0 0.0.0.255
line vty 0 15
 access-class MGMT-ONLY in
 transport input ssh

Segmentation is a defence in depth stack, not a single feature:

  1. Separate path (OOB or management VRF) so user traffic cannot reach the management plane.
  2. Access control on the VTY lines and with ACLs or firewall rules to the management subnet.
  3. Authentication through TACACS+ with command authorisation and accounting, backed by a local fallback.
  4. Protocol hygiene: SSH instead of Telnet, SNMPv3 instead of v2c, HTTPS instead of HTTP.
  5. Control-plane protection such as CoPP, so a flood to the router cannot stop management (ENARSI CoPP).

In SD-Access, fabric devices are managed over the underlay (the global routing table), which stays separate from every user virtual network. The principle is the same: management is its own segment, never part of a user VN.

Exam trap

A management VRF isolates the device's own management traffic, but it does not segment user traffic. Questions that mention "multi-tenant" or "segment user groups" point to VRFs or SD-Access virtual networks, not a management VRF.

4.3.c Prioritizing network management traffic

Management traffic is small but time-critical in a failure: routing updates, SSH sessions, SNMP traps and syslog all compete with a flood of user data at the exact moment the network is struggling. Two things need protection, and they are different.

Class Marking Contents Treatment
Network control CS6 Routing protocol hellos and updates, STP BPDUs, device-originated control traffic Small guaranteed bandwidth, never dropped before user data
Operations, administration and management (OAM) CS2 SSH, SNMP, syslog, NetFlow export, telemetry Modest guaranteed bandwidth, above best effort

Routers mark their own control-plane traffic (such as OSPF and BGP) as CS6 by default. Management protocols you mark yourself, either at the source or with a classification policy near the management stations. Bulk transfers inside the management plane, such as software image downloads, should sit in bulk or scavenger, not CS2, so an image upgrade does not starve interactive SSH.

class-map match-any OAM
 match dscp cs2
 match access-group name MGMT-PROTOCOLS
policy-map WAN-CHILD
 class OAM
  bandwidth percent 3
 class NETWORK-CONTROL
  bandwidth percent 3

Other management priority concerns:

  • Telemetry volume. Streaming telemetry and high-rate NetFlow can generate more traffic than SNMP polling. Size it and choose sampling or on-change subscriptions, which matters on slow branch WAN links. Telemetry is the subject of 5.3.
  • Syslog storms. A failing device can generate thousands of messages. Rate limiting, severity filtering and a local buffer prevent a failure from filling the link.
  • Controller dependency. Controllers such as Catalyst Center need constant reachability. Place them close to the core, protect them in the data centre, and decide how devices behave when the controller is unreachable.
  • Software upgrades. Schedule bulk image transfers off-hours or use local distribution points at remote sites rather than pulling each image across the WAN.

Design exercise

Scenario. A university has a main campus data centre, eight remote campuses connected by 1 Gbps Metro Ethernet and about 150 small buildings with a single switch each over leased lines of 20 to 50 Mbps. A recent routing misconfiguration at the data centre took down the core, and engineers could not reach the devices to fix it for three hours. Auditors also flagged that the management VLAN is reachable from student networks.

Requirements.

  • Engineers must be able to reach core devices during an outage.
  • Student networks must not reach any management interface.
  • Routing protocols must remain stable when the WAN is saturated.

Constraints.

  • Budget does not allow dedicated OOB at the 150 small buildings.
  • Existing devices support VRFs and TACACS+.
Model answer
  • Hybrid management. Build dedicated OOB at the data centre and the eight campus cores: a management switch, console servers and a cellular modem for backup, with their own AAA and NTP servers so the OOB path does not depend on production. Keep the 150 small buildings on in-band management through loopbacks.
  • Segmentation. Move management into a management VRF (or an infrastructure virtual network where SD-Access is used), carried end to end in a separate routed segment. Block student networks from it at a firewall and with VTY access-class lists. Management stations sit in a protected zone behind the firewall, reached through a jump host with MFA.
  • Hardening. SSH only, SNMPv3, TACACS+ with command authorisation and a local fallback account, CoPP on the cores.
  • Priority. Mark routing control traffic as CS6 and management protocols as CS2, with small guaranteed queues on the WAN links. Software images are bulk traffic, scheduled out of hours.

Rejected alternatives.

  • OOB everywhere. The recurring cost at 150 sites outweighs the risk at small, single-switch buildings. A truck roll to a small site is acceptable.
  • A bigger, better firewalled management VLAN only. It limits who connects, but it still shares fate with production. The three-hour outage would recur.
  • Move all management into the priority queue. Voice and management compete, and a large image transfer could starve real-time traffic. Management is protected with a small guaranteed share, not strict priority.
  • Console servers attached to the production network. They look like OOB but fail with the network.

Quick check

Why does an OOB network need its own AAA and NTP reachability?

If AAA and time services are reachable only through the production network, a production outage breaks logins on the OOB path as well, so it fails exactly when it is needed.

Which DSCP is used for network control traffic and which for management protocols such as SSH and SNMP?

CS6 for network control (routing protocols). CS2 for operations, administration and management.

Which design benefit does a management VRF give, and which does it not give?

It isolates the device's management interface and services from the global routing table. It does not segment user traffic from other user traffic.

References

  • Cisco Validated Design: Campus LAN and Wireless LAN design guides (search "Cisco Validated Design campus" on cisco.com)
  • Cisco Enterprise QoS Solution Reference Network Design Guide (search on cisco.com)
  • Management VRF: search "Catalyst 9000 Mgmt-vrf configuration" on cisco.com
  • RFC 4594 at rfc-editor.org (CS2 OAM and CS6 network control)
  • Cisco Live On-Demand Library: search "out-of-band management design"