Cisco IOS-XE Hardening: Complete Run Book for Management Plane, Control Plane, and Service Lockdown

Overview

Hardening a Cisco IOS-XE device is one of the most impactful steps a network engineer can take to reduce the attack surface and satisfy compliance frameworks such as CIS Benchmarks Level 1/2, DISA STIGs, and NIST SP 800-53. A factory-default IOS-XE installation ships with insecure legacy services enabled, weak password handling defaults, no management-plane restrictions, and no control plane rate limiting. Every device entering production must be hardened before it carries traffic.

This run book walks through the complete IOS-XE hardening lifecycle: base identity and password security, login brute-force protection, console and VTY lockdown, SSH version 2 enforcement, unnecessary service removal, per-interface data plane protections, SNMPv3 with authPriv, Control Plane Policing (CoPP), and structured centralized logging. All examples are validated on IOS-XE 17.x running on ISR 4000 and ASR 1000 series platforms.

Reference Topology

All examples throughout this article use the following consistent reference values:

• Hostname: sw-infrarunbook-01
• Management IP: 10.10.10.1/24 on GigabitEthernet0/0
• Management subnet: 10.10.10.0/24
• NTP server: 10.10.10.254
• Syslog server: 10.10.20.10
• SNMP manager: 10.10.20.15
• TACACS+ server: 10.10.20.20
• Domain name: solvethenetwork.com
• Admin account: infrarunbook-admin

Step 1 — Hostname, Domain Name, and Base Identity

Set a meaningful hostname and a fully qualified domain name. The domain name is required for RSA key pair generation, which SSH depends on. Disable IP domain lookup to prevent the router from treating mistyped commands as DNS hostnames and hanging on name resolution during interactive sessions.

sw-infrarunbook-01# configure terminal
sw-infrarunbook-01(config)# hostname sw-infrarunbook-01
sw-infrarunbook-01(config)# ip domain name solvethenetwork.com
sw-infrarunbook-01(config)# no ip domain-lookup

Step 2 — Password Security and Privilege Levels

Weak or improperly stored passwords are the most common hardening failure found in network audits. IOS-XE supports multiple password encoding algorithms: Type 5 (MD5), Type 7 (reversible XOR — never use for privileged credentials), Type 8 (PBKDF2/SHA-256), and Type 9 (scrypt). Always use

enable secret

rather than

enable password

, and prefer Type 9 where the IOS-XE version supports it (16.9+).

! Use scrypt (Type 9) for the enable secret
sw-infrarunbook-01(config)# enable algorithm-type scrypt secret Str0ng#EnablePass!

! Remove the legacy enable password if present
sw-infrarunbook-01(config)# no enable password

! Apply Type 7 obfuscation to all remaining plaintext passwords
sw-infrarunbook-01(config)# service password-encryption

! Enforce a minimum password length of 14 characters
sw-infrarunbook-01(config)# security passwords min-length 14

! Create the local admin account using scrypt
sw-infrarunbook-01(config)# username infrarunbook-admin privilege 15 algorithm-type scrypt secret Str0ng#UserPass!

service password-encryption

applies Type 7 encoding to all plaintext passwords stored in the running configuration (line passwords, CHAP secrets, etc.). While Type 7 is reversible with publicly available tools, it prevents casual shoulder-surfing and accidental log exposure. For privileged credentials, always use Type 8 or Type 9 regardless of this setting.

Step 3 — Login Banners

A correctly worded banner establishes legal notice that unauthorized access is prohibited. Many jurisdictions require this notice to exist before a user authenticates for a prosecution to proceed. Configure both a MOTD banner (displayed before login) and an EXEC banner (displayed after successful authentication).

sw-infrarunbook-01(config)# banner motd ^
*******************************************************************************
*  WARNING: This system is the exclusive property of SolveTheNetwork.com.    *
*  Unauthorized access is strictly prohibited and will be prosecuted.        *
*  All activity on this system is logged and monitored.                      *
*******************************************************************************
^
sw-infrarunbook-01(config)# banner exec ^
Authorized personnel only. Your session activity is being recorded.
^

Do not include the device hostname, IOS version, IP addresses, or platform model in banners. This information gives attackers a head start in fingerprinting and targeting the device.

Step 4 — Console, VTY, and AUX Line Hardening

Every access path to the device — console, VTY, and AUX — must be explicitly locked down. The most critical VTY controls are restricting transport to SSH only, applying an inbound ACL limiting access to the management subnet, and enforcing idle session timeouts.

! Define the management access ACL
sw-infrarunbook-01(config)# ip access-list standard ACL-MGMT-ACCESS
sw-infrarunbook-01(config-std-nacl)# permit 10.10.10.0 0.0.0.255
sw-infrarunbook-01(config-std-nacl)# deny   any log
sw-infrarunbook-01(config-std-nacl)# exit

! Harden the console line
sw-infrarunbook-01(config)# line console 0
sw-infrarunbook-01(config-line)# login local
sw-infrarunbook-01(config-line)# exec-timeout 5 0
sw-infrarunbook-01(config-line)# logging synchronous
sw-infrarunbook-01(config-line)# exit

! Harden all VTY lines
sw-infrarunbook-01(config)# line vty 0 15
sw-infrarunbook-01(config-line)# login local
sw-infrarunbook-01(config-line)# transport input ssh
sw-infrarunbook-01(config-line)# access-class ACL-MGMT-ACCESS in
sw-infrarunbook-01(config-line)# exec-timeout 10 0
sw-infrarunbook-01(config-line)# logging synchronous
sw-infrarunbook-01(config-line)# exit

! Disable the AUX port completely
sw-infrarunbook-01(config)# line aux 0
sw-infrarunbook-01(config-line)# transport input none
sw-infrarunbook-01(config-line)# no exec
sw-infrarunbook-01(config-line)# exit

Setting

transport input ssh

on VTY lines rejects all Telnet connections at the line level — a second layer of protection beyond any ACL. The

exec-timeout 10 0

directive (10 minutes, 0 seconds) closes idle SSH sessions automatically, freeing VTY slots and reducing risk from unattended terminals.

Step 5 — SSH Version 2 Enforcement

SSH version 1 has well-documented cryptographic weaknesses including man-in-the-middle susceptibility and weak key exchange. It must never be used in production. Generate a minimum 4096-bit RSA key pair, enforce SSH version 2 exclusively, and tighten the authentication window and retry limits.

! Generate RSA key pair — 4096 bits minimum for production
sw-infrarunbook-01(config)# crypto key generate rsa modulus 4096 label SSH-KEY

! Enforce SSH version 2 only
sw-infrarunbook-01(config)# ip ssh version 2

! Reduce authentication window and retry attempts
sw-infrarunbook-01(config)# ip ssh time-out 60
sw-infrarunbook-01(config)# ip ssh authentication-retries 3

! Bind outbound SSH to the management interface
sw-infrarunbook-01(config)# ip ssh source-interface GigabitEthernet0/0

! Log SSH connection events
sw-infrarunbook-01(config)# ip ssh logging events

The

ip ssh source-interface

command ensures SSH sessions initiated by the router (for example, SCP file copies or outbound management connections) always originate from the management interface IP, making firewall rules and ACLs predictable.

Step 6 — Login Brute-Force Protection

The

login block-for

feature provides built-in protection against automated brute-force login attacks by temporarily silencing all login attempts after a configurable failure threshold is reached. A

quiet-mode access-class

exempts the management subnet so authorized engineers can still reach the device during an active attack.

! Block all logins for 120 seconds after 5 failures within 30 seconds
sw-infrarunbook-01(config)# login block-for 120 attempts 5 within 30

! Exempt the management subnet from quiet-mode blocking
sw-infrarunbook-01(config)# login quiet-mode access-class ACL-MGMT-ACCESS

! Log authentication successes and failures
sw-infrarunbook-01(config)# login on-failure log
sw-infrarunbook-01(config)# login on-success log

Step 7 — Disable Unnecessary Services

IOS-XE enables several legacy services by default that have no place on modern production infrastructure. Each enabled service represents an additional attack surface. The following commands disable the most significant offenders.

! Disable legacy TCP and UDP small servers (echo, chargen, daytime, discard)
sw-infrarunbook-01(config)# no service tcp-small-servers
sw-infrarunbook-01(config)# no service udp-small-servers

! Disable the IOS HTTP and HTTPS server if not required for management
sw-infrarunbook-01(config)# no ip http server
sw-infrarunbook-01(config)# no ip http secure-server

! Disable BOOTP server (legacy boot protocol)
sw-infrarunbook-01(config)# no ip bootp server

! Disable IP source routing (exploited in IP options-based attacks)
sw-infrarunbook-01(config)# no ip source-route

! Disable the Finger service (user enumeration)
sw-infrarunbook-01(config)# no service finger

! Disable PAD commands (legacy X.25 packet assembler/disassembler)
sw-infrarunbook-01(config)# no service pad

! Disable CDP on external-facing interfaces (leaks platform info)
sw-infrarunbook-01(config)# interface GigabitEthernet0/1
sw-infrarunbook-01(config-if)# no cdp enable
sw-infrarunbook-01(config-if)# exit

! Disable LLDP globally if not required
sw-infrarunbook-01(config)# no lldp run

CDP and LLDP leak the device model, IOS version, IP addresses, and VLAN information to adjacent devices. Disable them on all external-facing and untrusted interfaces. They can be left enabled on internal trunk links where neighbor discovery is operationally required.

Step 8 — Data Plane Interface Hardening

Per-interface settings reduce exposure to common reconnaissance, spoofing, and amplification attacks. Apply these to all external and untrusted interfaces.

sw-infrarunbook-01(config)# interface GigabitEthernet0/1

! Disable proxy ARP — prevents the router from answering ARP on behalf of other hosts
sw-infrarunbook-01(config-if)# no ip proxy-arp

! Disable ICMP redirects — used in MITM redirect attacks
sw-infrarunbook-01(config-if)# no ip redirects

! Disable ICMP unreachables — reduces port-scan reconnaissance
sw-infrarunbook-01(config-if)# no ip unreachables

! Disable directed broadcasts — prevents Smurf amplification
sw-infrarunbook-01(config-if)# no ip directed-broadcast

! Enable Unicast RPF in strict mode on edge/upstream interfaces
sw-infrarunbook-01(config-if)# ip verify unicast source reachable-via rx

sw-infrarunbook-01(config-if)# exit

Unicast Reverse Path Forwarding (uRPF) in strict mode drops any packet whose source IP address is not reachable via the interface the packet arrived on. This is highly effective at preventing IP source address spoofing on edge links. Do not apply strict mode to interfaces on asymmetric routing paths — use loose mode (

reachable-via any

) in those cases after verifying routing symmetry.

Step 9 — SNMPv3 with authPriv

SNMPv1 and SNMPv2c transmit community strings in cleartext and provide no per-message authentication. They must not be used in production. SNMPv3 with the

authPriv

security level provides HMAC-SHA authentication and AES encryption for every PDU. Remove all legacy community strings before deploying SNMPv3.

! Remove all legacy SNMPv1/v2c community strings
sw-infrarunbook-01(config)# no snmp-server community public
sw-infrarunbook-01(config)# no snmp-server community private
sw-infrarunbook-01(config)# no snmp-server community RO
sw-infrarunbook-01(config)# no snmp-server community RW

! Restrict SNMP to the management host only
sw-infrarunbook-01(config)# ip access-list standard ACL-SNMP-ACCESS
sw-infrarunbook-01(config-std-nacl)# permit host 10.10.20.15
sw-infrarunbook-01(config-std-nacl)# deny any log
sw-infrarunbook-01(config-std-nacl)# exit

! Create a restricted MIB view
sw-infrarunbook-01(config)# snmp-server view INFRA-VIEW iso included

! Create an SNMPv3 group with authPriv and ACL restriction
sw-infrarunbook-01(config)# snmp-server group INFRA-GROUP v3 priv read INFRA-VIEW access ACL-SNMP-ACCESS

! Create the SNMPv3 user with SHA-256 auth and AES-128 privacy
sw-infrarunbook-01(config)# snmp-server user infrarunbook-admin INFRA-GROUP v3 auth sha Auth#Pass2024! priv aes 128 Priv#Pass2024!

! Set system contact and location
sw-infrarunbook-01(config)# snmp-server contact noc@solvethenetwork.com
sw-infrarunbook-01(config)# snmp-server location DC1-Rack-A3-U12

! Send traps to the SNMP manager using SNMPv3 authPriv
sw-infrarunbook-01(config)# snmp-server host 10.10.20.15 version 3 priv infrarunbook-admin
sw-infrarunbook-01(config)# snmp-server enable traps

The SNMPv3 user configuration is stored as a hash, not in plaintext. When you issue

show snmp user

, you will see the auth and privacy protocols but not the actual passphrases — this is by design.

Step 10 — Control Plane Policing (CoPP)

The router CPU processes all traffic destined for the device itself: routing protocol updates, SSH sessions, SNMP polls, ICMP pings, and more. Without CoPP, a single packet flood targeting the management plane can overwhelm the route processor and cause the device to drop routing adjacencies or become unreachable for management. CoPP uses the Modular QoS CLI (MQC) framework to classify and rate-limit control plane traffic by type.

The policy below uses a tiered approach. Critical routing protocols receive the highest rate allowance. Management traffic receives a moderate budget. ICMP and everything else are aggressively rate-limited. Tune these values in a lab or staging environment before applying to production, then monitor the drop counters after deployment.

! --- ACLs for traffic classification ---

ip access-list extended ACL-CoPP-BGP
 permit tcp any any eq 179
 permit tcp any eq 179 any

ip access-list extended ACL-CoPP-OSPF
 permit ospf any any

ip access-list extended ACL-CoPP-EIGRP
 permit eigrp any any

ip access-list extended ACL-CoPP-SSH
 permit tcp 10.10.10.0 0.0.0.255 any eq 22

ip access-list extended ACL-CoPP-SNMP
 permit udp host 10.10.20.15 any eq 161

ip access-list extended ACL-CoPP-ICMP
 permit icmp 10.10.10.0 0.0.0.255 any

! --- Class-maps ---

class-map match-any CM-CoPP-BGP
 match access-group name ACL-CoPP-BGP

class-map match-any CM-CoPP-ROUTING
 match access-group name ACL-CoPP-OSPF
 match access-group name ACL-CoPP-EIGRP

class-map match-any CM-CoPP-MGMT
 match access-group name ACL-CoPP-SSH
 match access-group name ACL-CoPP-SNMP

class-map match-any CM-CoPP-ICMP
 match access-group name ACL-CoPP-ICMP

! --- Policy-map ---

policy-map PM-CoPP
 class CM-CoPP-BGP
  police rate 1000 pps
   conform-action transmit
   exceed-action drop
 class CM-CoPP-ROUTING
  police rate 500 pps
   conform-action transmit
   exceed-action drop
 class CM-CoPP-MGMT
  police rate 100 pps
   conform-action transmit
   exceed-action drop
 class CM-CoPP-ICMP
  police rate 50 pps
   conform-action transmit
   exceed-action drop
 class class-default
  police rate 10 pps
   conform-action transmit
   exceed-action drop

! --- Apply to control-plane ---

control-plane
 service-policy input PM-CoPP

Warning: Always test CoPP in a lab first. If the routing protocol rates are set too low for your adjacency count, you will drop Hello packets and lose peering sessions. Use

show policy-map control-plane

to review drop counters before and after applying the policy.

Step 11 — Syslog and Logging Hardening

Centralized logging is essential for incident detection, forensic investigation, and compliance audits. Configure the router to send all significant events to a remote syslog server, include high-resolution timestamps and sequence numbers, and archive all configuration changes.

! Add millisecond timestamps with timezone to all log and debug messages
sw-infrarunbook-01(config)# service timestamps log datetime msec localtime show-timezone
sw-infrarunbook-01(config)# service timestamps debug datetime msec localtime show-timezone

! Add sequence numbers to correlate log messages
sw-infrarunbook-01(config)# service sequence-numbers

! Size the local log buffer at 1 MB and keep informational events
sw-infrarunbook-01(config)# logging buffered 1048576 informational

! Limit console and monitor logging to reduce noise
sw-infrarunbook-01(config)# logging console warnings
sw-infrarunbook-01(config)# logging monitor informational

! Send informational and above to the remote syslog server
sw-infrarunbook-01(config)# logging host 10.10.20.10
sw-infrarunbook-01(config)# logging trap informational
sw-infrarunbook-01(config)# logging source-interface GigabitEthernet0/0
sw-infrarunbook-01(config)# logging on

! Archive all configuration changes to syslog (hidekeys masks passwords)
sw-infrarunbook-01(config)# archive
sw-infrarunbook-01(config-archive)# log config
sw-infrarunbook-01(config-archive-log-cfg)# logging enable
sw-infrarunbook-01(config-archive-log-cfg)# notify syslog contenttype plaintext
sw-infrarunbook-01(config-archive-log-cfg)# hidekeys
sw-infrarunbook-01(config-archive-log-cfg)# exit
sw-infrarunbook-01(config-archive)# exit

The

hidekeys

directive under

archive log config

suppresses passwords and cryptographic keys from the configuration change log and syslog stream. Without this option, a password change event would write the new password in cleartext to your syslog server.

Step 12 — TCP Keepalives and MSS Adjustment

Enabling TCP keepalives ensures that hung management sessions (caused by NAT timeout, firewall session expiry, or network interruption) are detected and cleaned up, freeing VTY resources.

sw-infrarunbook-01(config)# service tcp-keepalives-in
sw-infrarunbook-01(config)# service tcp-keepalives-out

! Adjust TCP MSS to prevent black-holes on tunneled or PPPoE paths
sw-infrarunbook-01(config)# ip tcp adjust-mss 1452

Step 13 — Verification Commands

After completing the hardening steps, use the following commands to confirm the configuration is operating correctly before saving and disconnecting.

! SSH configuration and negotiated algorithms
sw-infrarunbook-01# show ip ssh

! Active SSH sessions
sw-infrarunbook-01# show ssh

! RSA key details
sw-infrarunbook-01# show crypto key mypubkey rsa

! Login block status and failure history
sw-infrarunbook-01# show login
sw-infrarunbook-01# show login failures

! CoPP policy counters — check for unexpected drops
sw-infrarunbook-01# show policy-map control-plane

! SNMPv3 user and group configuration
sw-infrarunbook-01# show snmp user
sw-infrarunbook-01# show snmp group

! Logging configuration summary
sw-infrarunbook-01# show logging

! Verify service commands in running config
sw-infrarunbook-01# show running-config | include ^service

! Verify VTY and console line settings
sw-infrarunbook-01# show running-config | section line vty
sw-infrarunbook-01# show running-config | section line con

! Sample output: show ip ssh
SSH Enabled - version 2.0
Authentication methods: publickey,keyboard-interactive,password
Encryption Algorithms: aes128-ctr,aes192-ctr,aes256-ctr
MAC Algorithms: hmac-sha2-256,hmac-sha2-512
KEX Algorithms: diffie-hellman-group-exchange-sha256
Authentication timeout: 60 secs; Authentication retries: 3
Minimum expected Diffie Hellman key size: 2048 bits

Step 14 — Save Configuration

sw-infrarunbook-01# write memory
Building configuration...
[OK]

Always verify SSH connectivity from a second terminal window before closing the active console session. If SSH fails after hardening, use the console to diagnose — most commonly the RSA key was not generated before enabling SSH version 2, or the VTY ACL is blocking the management workstation.

Production Hardening Checklist

• Hostname and

  ip domain name

  configured

• enable secret

  uses algorithm-type scrypt (Type 9)
• No

  enable password

  present in configuration
• All local user accounts use Type 8 or Type 9 password hashing

• service password-encryption

  enabled

• security passwords min-length 14

  enforced
• Banner MOTD and EXEC banners contain legal warning language
• Console line:

  login local

  ,

  exec-timeout 5 0

• VTY lines:

  login local

  ,

  transport input ssh

  , inbound

  access-class

  applied
• AUX line:

  transport input none

  ,

  no exec

• RSA key pair generated at 4096 bits

• ip ssh version 2

  enforced

• ip ssh time-out 60

  and

  ip ssh authentication-retries 3

  configured

• login block-for

  configured with quiet-mode exemption for management subnet
• TCP/UDP small servers disabled
• IP HTTP and HTTPS server disabled (unless required)

• no ip source-route

  configured globally
• CDP disabled on all external and untrusted interfaces
• Proxy ARP, ICMP redirects, ICMP unreachables disabled on external interfaces
• Directed broadcasts disabled on all interfaces
• uRPF enabled on edge interfaces (strict mode where routing is symmetric)
• All SNMPv1/v2c community strings removed
• SNMPv3

  authPriv

  configured with ACL-restricted access
• CoPP policy applied to

  control-plane

  with drop counters reviewed
• Syslog configured with millisecond timestamps, sequence numbers, and remote host

• archive log config

  enabled with

  hidekeys

• TCP keepalives enabled in both directions
• Configuration saved with

  write memory

Frequently Asked Questions

Q: What is the difference between enable password and enable secret on IOS-XE?

A:

enable password

stores the privileged EXEC password in plaintext or with reversible Type 7 encoding.

enable secret

stores it using a one-way cryptographic hash — MD5 (Type 5) by default, or scrypt (Type 9) when you specify

algorithm-type scrypt

. If both commands exist simultaneously,

enable secret

always takes precedence. You should never have an active

enable password

on a production device. Remove it with

no enable password

after confirming

enable secret

is working.

Q: Why use Type 9 (scrypt) instead of Type 5 (MD5) for IOS-XE passwords?

A: Type 5 uses a single round of MD5, which is fast to compute and trivial to brute-force with modern GPUs. Type 9 (scrypt) is a memory-hard key derivation function intentionally designed to be expensive to brute-force — an attacker with a GPU farm that cracks a Type 5 hash in seconds may take years to crack an equivalent Type 9 hash. Type 8 (PBKDF2/SHA-256) is a reasonable middle ground for platforms that do not yet support scrypt. Both Type 8 and Type 9 are available on IOS-XE 16.9 and later.

Q: Does service password-encryption actually provide security?

A: Only minimally.

service password-encryption

applies Type 7 encoding to plaintext passwords in the configuration. Type 7 is a simple XOR cipher with a published algorithm — anyone can decode a Type 7 password in seconds using a publicly available tool. Its value is limited to preventing casual exposure in printed configs, screenshots, and syslog streams. It does not protect against a determined attacker with a copy of the configuration file. Always use

enable secret

with Type 9 and

username

accounts with Type 9 for any credential that actually matters.

Q: Can I apply CoPP to a live production router safely?

A: Yes, but carefully. Before applying the policy, run

show policy-map control-plane

in a test window to verify there are no existing policies. Start with conservative (high) rate values and monitor drop counters with

show policy-map control-plane

for 24–48 hours before tightening them. The most common mistake is setting BGP or OSPF rates too low for the number of peers and prefixes on the device, which causes Hello packets to be dropped and adjacencies to flap. If in doubt, set routing protocol rates to 2000–5000 pps initially and tune downward based on observed traffic.

Q: Why should I disable ip source-route?

A: IP strict and loose source routing are options in the IP header that allow the sender to specify the path a packet must take through the network. These options were designed for network testing in the 1980s and are exploited in modern attacks to bypass firewalls, probe internal topology, and conduct man-in-the-middle attacks. No legitimate production application uses IP source routing today. Disabling it with

no ip source-route

drops all packets carrying these options at the first hop.

Q: What is the difference between uRPF strict mode and loose mode?

A: In strict mode, the router drops a packet if the source IP address is not reachable via the exact interface the packet arrived on. This is the most effective setting for anti-spoofing but requires symmetric routing. In loose mode, the router only requires that the source IP address appears somewhere in the routing table — it does not check which interface. Loose mode is appropriate for multi-homed environments with asymmetric routing. Apply strict mode on single-homed edge interfaces where you control routing, and loose mode on multi-homed or dual-upstream interfaces. Never apply uRPF to interfaces with a default route only (all traffic would pass the loose check regardless).

Q: How do I verify that Telnet is completely blocked on VTY lines?

A: First, confirm the VTY configuration with

show running-config | section line vty

. You should see

transport input ssh

on all VTY lines (0–15). Then attempt a Telnet connection from a workstation on the management subnet: the connection should be refused immediately. If you see

transport input telnet ssh

on any line, Telnet is still permitted on that line. The command

transport input none

blocks all access including SSH — use

transport input ssh

, not

none

, on lines you want SSH access on.

Q: Should I disable ICMP unreachables on all interfaces?

A: On external and untrusted interfaces, yes — disabling ICMP unreachables reduces the effectiveness of port-scanning tools that rely on ICMP port-unreachable responses to identify closed ports. On internal interfaces, consider the operational tradeoff: ICMP unreachables are used by PMTUD (Path MTU Discovery) and by network troubleshooting tools. Disabling them on internal links can cause subtle TCP connectivity issues on paths with MTU mismatches. A common compromise is to rate-limit unreachables rather than disabling them entirely, using CoPP.

Q: Why does show snmp user not display the SNMPv3 password?

A: IOS-XE stores SNMPv3 authentication and privacy passwords as localized keys derived using the engine ID and the HMAC algorithm, not as plaintext. After the initial password is set and the localized key is generated, the original passphrase is discarded and cannot be recovered from the device. This is a security feature — if an attacker obtains a copy of your running configuration, they cannot extract the SNMP passphrase. The

show snmp user

output will show the auth and privacy protocols in use (e.g., SHA, AES-128) but not the keys themselves.

Q: What happens to my active SSH sessions when I apply the VTY ACL?

A: Already-established SSH sessions are typically not dropped when you apply or modify a VTY

access-class

. The ACL is evaluated on new connection attempts. However, to be safe, always apply VTY ACL changes while connected via the console port, not via an active SSH session. After applying the ACL, open a new SSH session from a host in the permitted subnet to confirm access before disconnecting the console.

Q: How do I harden IOS-XE if the HTTP server must remain enabled for WebUI or REST API access?

A: If the HTTP server cannot be disabled, harden it by enforcing HTTPS only, binding it to the management interface, and restricting access with an ACL. Use

no ip http server

(disables plain HTTP), keep

ip http secure-server

enabled, set

ip http secure-port 8443

to use a non-standard port, configure

ip http access-class ACL-MGMT-ACCESS

to restrict source addresses, and set

ip http authentication local

to require local user credentials. Additionally, configure TLS 1.2 minimum with

ip http tls-version TLSv1.2

on platforms that support this command.

Q: Is it safe to disable CDP globally on a campus switch?

A: Disabling CDP globally with

no cdp run

will break Cisco IP Phone VLAN negotiation (phones use CDP to learn the voice VLAN), Cisco Discovery in network management platforms, and EnergyWise. On campus access switches with IP phones, it is safer to disable CDP only on uplinks and external-facing ports using

no cdp enable

at the interface level, leaving it enabled on access ports toward phones and servers. On WAN routers and data center core switches without phones, global disabling is generally safe.