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:
- Separate path (OOB or management VRF) so user traffic cannot reach the management plane.
- Access control on the VTY lines and with ACLs or firewall rules to the management subnet.
- Authentication through TACACS+ with command authorisation and accounting, backed by a local fallback.
- Protocol hygiene: SSH instead of Telnet, SNMPv3 instead of v2c, HTTPS instead of HTTP.
- 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"
Unlock the full question banks and cram sheets
A free account opens every question bank, the timed practice exams, the printable cram sheets, all the simulations and the lab files. Without one you see a 5-question sample of each.
No card needed. Study tips by email are optional and off unless you tick the box. Your address is never sold or shared. Privacy policy ยท Terms
Signed in as . Your account
You're on the free account, so lessons after the first module, question banks, exams and cram sheets show a sample. See Track Pass and All-Access
Also from NetManager Systems: NetManager, network monitoring for multi-vendor networks. Try the NetManager, NetDiag, PCAP Analyzer and OpsDash demos: every new account gets a free 7-day read-only login to each.