Essential Cisco IOS Commands for Network Configuration and Troubleshooting

Cisco IOS is controlled through a hierarchical command-line interface. The same command may work only in a particular mode, require elevated privileges, affect the live configuration immediately, need to be saved before it survives a restart, or behave differently across IOS and IOS XE platforms.

A useful Cisco command reference therefore needs to explain more than command syntax. It should also show which mode the command belongs in, whether it changes configuration, whether it is disruptive, how to verify the result and how to save or reverse the change.

This guide is written for technically competent administrators. It prioritises secure modern practices and clearly marks legacy or insecure methods where they appear. Commands and descriptions have been verified against current Cisco IOS and IOS XE documentation. Last checked: 30 July 2026.

Before you start: editorial warning

Placeholder convention

Angle-bracket values in this guide are placeholders that must be replaced with the correct value for your environment. They must never be pasted literally into a device. No real credentials, public IP addresses or customer information appear anywhere in this guide.

The quick answer

Understanding Cisco IOS command modes

Every Cisco IOS command must be entered in the correct mode. Entering a command in the wrong mode either produces an error or does nothing. The mode is visible from the prompt.

exit moves back one level in the hierarchy. end or Ctrl+Z generally returns to Privileged EXEC mode from any configuration sub-mode. These shortcuts may vary by platform — do not overstate their behaviour.

Tab auto-completes partial commands where the input is unambiguous. ? displays available commands or options at the current mode. Up and down arrow keys cycle through command history, or use show history to review it.

Essential inspection commands

Always inspect before changing. These commands are read-only, though their output may contain sensitive information that should be treated carefully.

Basic device configuration

Begin any configuration session by confirming which device you are on, reviewing the current configuration and confirming your rollback options.

Hostname

configure terminal
hostname <HOSTNAME>

Choose a unique, descriptive hostname for each device. The hostname appears in every prompt and is required before RSA keys for SSH can be generated.

Enable secret

enable secret <STRONG-UNIQUE-SECRET>

Use enable secret rather than enable password. The enable secret command stores a hashed version of the password; enable password stores a weakly obfuscated or plaintext value and should not be used where enable secret is available. The exact hashing algorithm depends on the IOS and IOS XE version.

Timestamps and time

service timestamps log datetime msec
clock timezone GMT 0
ntp server <NTP-SERVER>

Accurate timestamps make logs meaningful. A Cisco device without NTP may have a clock that has drifted significantly from real time, making incident investigation and correlation with other log sources unreliable. Verify NTP synchronisation with show ntp associations.

Access banners

banner login #Authorised access only. Activity may be monitored.#

The character immediately after banner login is the delimiter. Any character not appearing in the banner text can be used. Banners serve a legal and operational function by making clear that access is controlled — but the specific wording should be approved by the organisation where legal considerations apply. Do not assume a particular banner text provides guaranteed legal protection in all circumstances.

Interface and IP configuration

Interface names differ between devices and software releases. Always verify the exact name with show ip interface brief or show interfaces status before attempting to configure an interface.

interface <INTERFACE>
 description <PURPOSE>
 ip address <IP-ADDRESS> <SUBNET-MASK>
 no shutdown

no shutdown enables an interface that is administratively down. shutdown disables it. These are potentially disruptive on active production interfaces — verify the interface is not carrying active traffic before shutting it down. Changing a management interface can disconnect the administrator, so confirm out-of-band or console access first.

Layer 2 switch ports do not accept an IP address directly. Switch management commonly uses a Switched Virtual Interface (SVI):

interface vlan <VLAN-ID>
 ip address <IP-ADDRESS> <SUBNET-MASK>
 no shutdown

An SVI will not come up unless the corresponding VLAN exists and at least one active Layer 2 port is assigned to it. The SVI also requires a valid default gateway on the device if management traffic needs to cross subnets. Verify with show ip interface brief after configuration.

VLAN and switch-port configuration

VLANs segment Layer 2 traffic. Creating a VLAN does not provide inter-VLAN routing — that requires a router or a Layer 3 switch with routed interfaces or SVIs.

Creating a VLAN

configure terminal
vlan <VLAN-ID>
 name <VLAN-NAME>

Use meaningful VLAN names such as Staff-LAN, Voice, Management or CCTV. Create the VLAN before assigning ports to it. Avoid using VLAN 1 for sensitive management traffic where your security policy requires separation.

Assigning an access port

interface <INTERFACE>
 switchport mode access
 switchport access vlan <VLAN-ID>

An access port carries one untagged VLAN. Voice VLAN configurations may require additional commands. Do not move a port between VLANs without understanding what device is connected and what traffic will be affected.

Verify with show vlan brief and show interfaces status. The port should appear under the correct VLAN in the VLAN table and show the correct VLAN number in the interfaces status output.

Trunk ports

Trunk ports carry tagged traffic from multiple VLANs, typically between switches or between a switch and a router. Trunk configuration syntax and encapsulation options vary by platform.

interface <INTERFACE>
 switchport mode trunk
 switchport trunk native vlan <VLAN-ID>
 switchport trunk allowed vlan <VLAN-LIST>

Spanning Tree

Spanning Tree Protocol prevents Layer 2 loops by blocking redundant paths. It is enabled by default on Cisco switches for all VLANs. An incorrect STP configuration can cause network loops that flood and saturate the network.

Use these read-only commands first to understand the current topology before considering any STP changes:

show spanning-tree
show spanning-tree vlan <VLAN-ID>
show spanning-tree interface <INTERFACE> detail

On many IOS and IOS XE switches, Rapid PVST+ (spanning-tree mode rapid-pvst) is available and provides faster convergence than classic PVST+. However, the correct STP mode depends on the existing design, all connected switches and the platform. Do not change STP mode without understanding the current topology and confirming support across the entire switching domain.

PortFast should be configured only on access ports connected to a single end device, never on ports connected to other switches. BPDU Guard automatically error-disables a PortFast port that receives a BPDU, protecting against accidentally connected switches. Plan root bridge placement deliberately rather than allowing it to be determined by default bridge priority.

Routing and connectivity

Inspect the routing table before considering any changes. The source of each route is identified by a code in the routing table output.

show ip route
show ip route connected
show ip route static

ping and traceroute test connectivity. On many platforms, a source interface can be specified for more accurate path testing:

ping <DESTINATION>
traceroute <DESTINATION>

A static route adds a specific path for traffic to a network. Static routes can cause traffic black-holing if the next-hop becomes unreachable and administrative distance is lower than a dynamic route.

ip route <NETWORK> <SUBNET-MASK> <NEXT-HOP>

This article does not cover complete OSPF, EIGRP or BGP configuration. Dynamic routing protocol configuration requires dedicated coverage appropriate to the specific protocol, design and platform.

DHCP

On many IOS and IOS XE routers, a basic DHCP server can be configured locally. Before configuring a DHCP pool, confirm that no existing DHCP service is already operating on the same segment to avoid address conflicts.

ip dhcp excluded-address <IP-ADDRESS>
ip dhcp pool <POOL-NAME>
 network <NETWORK> <SUBNET-MASK>
 default-router <IP-ADDRESS>
 dns-server <IP-ADDRESS>
 domain-name <DOMAIN>
 lease <DAYS>

Always exclude the gateway address and any other statically assigned addresses from the pool using ip dhcp excluded-address before defining the pool. On switched networks where the DHCP server is on a different segment, ip helper-address on the interface facing clients forwards DHCP broadcast requests to the server:

interface <INTERFACE>
 ip helper-address <IP-ADDRESS>

Verify with show ip dhcp binding to see current leases and show ip dhcp conflict to check for detected address conflicts. A rogue DHCP server on the network can redirect or intercept client traffic. DHCP snooping on switches provides protection against rogue servers.

NAT

Network Address Translation allows devices with private addresses to access the internet through one or more public addresses. Inspect the current NAT state before making any changes, and understand the existing firewall or edge-router design before modifying translation rules.

show ip nat translations
show ip nat statistics

NAT requires interfaces to be designated as inside or outside. Port Address Translation (PAT or NAT overload) uses a single public address for many private addresses. Detailed NAT configuration examples appear in the Administrator Technical Note below.

Access control lists

ACLs filter traffic based on source or destination addresses, protocol and port. They are applied to an interface in a specified direction. Standard ACLs match only on source address; extended ACLs match on source, destination, protocol and port.

Every ACL has an implicit deny-all rule at the end. Traffic not explicitly permitted is silently discarded. Rule order matters: the first matching entry is applied and the rest are not evaluated. Wildcard masks are the bitwise inverse of subnet masks: for a /24 network, the wildcard is 0.0.0.255.

The following example uses only addresses from the RFC 5737 documentation range, which is reserved for documentation and must not appear in a live configuration:

ip access-list extended <ACL-NAME>
 permit tcp 192.0.2.0 0.0.0.255 any eq 443
 deny   ip any any log

To apply an ACL to an interface:

interface <INTERFACE>
 ip access-group <ACL-NAME> in

Verify with show access-lists (to see hit counters) and show ip interface <INTERFACE> (to confirm the ACL is applied and in which direction).

Secure SSH access

All interactive administrative access should use SSH version 2. Telnet transmits everything in plaintext, including credentials, and should not be used for administration. Where transport input commands are configured, prefer transport input ssh.

A typical SSH configuration sequence on IOS and IOS XE. Verify support for each element against the exact device and software release:

hostname <HOSTNAME>
ip domain name <DOMAIN>
crypto key generate rsa modulus 2048
ip ssh version 2
username <USERNAME> privilege 15 secret <STRONG-UNIQUE-SECRET>
line vty 0 4
 login local
 transport input ssh
 exec-timeout 10 0

A hostname and domain name must be configured before RSA keys can be generated. RSA key size requirements evolve with cryptographic guidance — verify current Cisco recommendations for the specific platform and software release. Cisco guidance has historically recommended 2048 bits as a minimum for RSA for SSH; newer guidance may prefer larger keys or different algorithms on IOS XE.

Verify with show ip ssh, show users and show running-config | section line vty.

Local users and AAA

Local user accounts should use the secret-based syntax, which stores a hashed representation rather than an obfuscated plaintext value. Available hashing algorithms and exact syntax vary by IOS and IOS XE version:

username <USERNAME> privilege <LEVEL> secret <STRONG-UNIQUE-SECRET>

Privilege 15 is full administrative access. Privilege 1 is limited. Named accounts improve accountability and auditability. Shared administrator accounts remove the ability to attribute actions to individuals and should be avoided where possible.

Inspect and manage local accounts:

show running-config | include username
show users
no username <USERNAME>

AAA (Authentication, Authorisation and Accounting) centralises access control. aaa new-model enables the AAA framework on the device. Authentication determines who can log in. Authorisation determines what they can do. Accounting records what they did.

RADIUS and TACACS+ allow administrators to authenticate against a central directory rather than local accounts on each device. TACACS+ is commonly preferred for network device administration because it separates authentication from authorisation and provides per-command accounting. Centralised AAA improves scalability, consistency and audit quality.

Port security

Switch port security limits the MAC addresses allowed on an access port. It can protect against unknown devices connecting to the network but has significant operational limitations in modern environments.

interface <INTERFACE>
 switchport mode access
 switchport port-security
 switchport port-security maximum <NUMBER>
 switchport port-security mac-address sticky
 switchport port-security violation restrict

Violation modes determine what happens when an unauthorised MAC is seen: protect silently drops unauthorised frames; restrict drops them and increments a counter; shutdown error-disables the port and requires manual recovery. Sticky MAC learning records MAC addresses seen on the port into the running configuration.

Inspect with show port-security and show port-security interface <INTERFACE>.

Logging, time and monitoring

Accurate logging depends on accurate time. Configure NTP before relying on any log output for incident investigation.

logging host <SYSLOG-SERVER>
logging trap informational
service timestamps log datetime msec

Logs held only in the device’s memory buffer are lost when the device restarts. Central logging to a syslog server preserves events, allows correlation across devices and improves investigation. terminal monitor sends a copy of syslog output to the current interactive session — useful for real-time observation but should not be left enabled unnecessarily as it can expose information to the current session.

Debug commands can generate very high volumes of output and may affect device performance. Use debug commands only for targeted diagnostics, during a maintenance window where possible, and disable them promptly with no debug <COMMAND> or undebug all.

SNMP and monitoring

SNMPv3 is strongly preferred over SNMPv1 and SNMPv2c. SNMPv1 and SNMPv2c use community strings transmitted in plaintext, providing no encryption and weak authentication. Community strings from a network scan can expose the string and potentially allow unauthenticated read or read-write access depending on configuration.

If legacy SNMPv1 or SNMPv2c community strings must be used in an existing environment, treat them as sensitive credentials, restrict SNMP access by source address using an ACL, use read-only community strings unless write access is required and plan migration to SNMPv3.

SNMPv3 provides authentication and encryption. Exact SNMPv3 configuration syntax varies by platform. Configuration details appear in the Administrator Technical Note.

Saving and backing up configuration

Understanding the difference between running configuration and startup configuration is essential:

Save the running configuration to startup after verifying a change:

copy running-config startup-config

Verify with show startup-config after saving. A safe configuration change workflow:

1. 1Record the current configuration with show running-config.
2. 2Make the approved change.
3. 3Verify the result using the relevant show commands.
4. 4Monitor for unexpected impact.
5. 5Save the configuration only after verification.
6. 6Store a secure external backup.
7. 7Document the change.

SCP or a protected network configuration-management platform is preferred for secure configuration export where supported. TFTP and FTP transfer configuration without encryption and should be used only where formally accepted and in isolated environments:

Configuration files may contain usernames, password hashes, shared secrets, SNMP credentials, VPN configuration, IP addressing and ACLs. Treat configuration backups as sensitive documents and store and transmit them with appropriate protection.

Commands to treat with extreme caution

Troubleshooting workflows

Troubleshooting should move from physical state, to interface state, to addressing, to VLANs, to routing, to policy.

Scenario 1: a device cannot reach another subnet

1. 1Check interface state: show ip interface brief — confirm the relevant interface is up/up.
2. 2Check IP address and mask: confirm the address and subnet mask are correct for the intended subnet.
3. 3Check default gateway: confirm the device has a valid default gateway or route.
4. 4Check VLAN assignment: show vlan brief — confirm the port is in the correct VLAN.
5. 5Check trunk VLAN list: show interfaces trunk — confirm the VLAN is allowed across the trunk.
6. 6Check the routing table: show ip route — confirm a route to the destination subnet exists.
7. 7Check ACLs: show access-lists — confirm no ACL is blocking the traffic.
8. 8Check NAT where relevant: show ip nat translations.
9. 9Test with ping and traceroute from the device.
10. 10Verify the return route exists at the far end.

Scenario 2: a switch port is down

1. 1Check physical connection: cable, SFP, port LED and connected device.
2. 2Check administrative state: show interfaces status — notconnect or err-disabled.
3. 3Check errors: show interfaces <INTERFACE> — look for input errors, CRC, flaps.
4. 4Check speed and duplex: mismatches cause errors and flapping.
5. 5Check err-disabled state: if the port is err-disabled, identify the cause from show logging before re-enabling.
6. 6Check port security: show port-security interface <INTERFACE>.
7. 7Check Spanning Tree: show spanning-tree interface <INTERFACE> detail.
8. 8Check PoE where relevant: power budget may prevent the port from coming up.

Scenario 3: a VLAN is not passing across a trunk

1. 1Confirm the VLAN exists on both switches: show vlan brief.
2. 2Confirm the port is trunking: show interfaces trunk.
3. 3Confirm the VLAN is in the allowed list: check VLANs allowed and active in spanning tree column.
4. 4Check the native VLAN: confirm it matches at both ends of the trunk.
5. 5Check STP state: the VLAN may be blocked by Spanning Tree.
6. 6Verify configuration at both ends of the trunk.

Scenario 4: SSH access fails

1. 1Check IP reachability: can you ping the management address from the connecting host?
2. 2Confirm hostname and domain name are set: required for RSA key generation.
3. 3Confirm RSA keys exist: show ip ssh should show SSH enabled.
4. 4Confirm SSH version 2: show ip ssh.
5. 5Confirm a local user exists or AAA is configured: show running-config | include username.
6. 6Check VTY configuration: show running-config | section line vty — transport input must permit ssh.
7. 7Check for an ACL restricting VTY access that may be blocking the source address.
8. 8Verify routing: the device must be able to route back to the connecting host.
9. 9Where AAA authentication is in use, check NTP synchronisation if time-based tokens are involved.

Scenario 5: configuration disappeared after restart

1. 1Compare show running-config with show startup-config — if they differ significantly, the configuration was not saved before the restart.
2. 2Check show version for last restart reason — power failure, crash or a deliberate reload.
3. 3Restore from a configuration backup where one exists.
4. 4If no backup exists and the configuration is lost, reconstruct from documentation and change records.

Scenario 6: unexpected configuration changes appear

1. 1Check administrator accounts: show running-config | include username.
2. 2Check current sessions: show users.
3. 3Review device logs: show logging.
4. 4Check AAA accounting where configured.
5. 5Check central monitoring and SIEM for login events.
6. 6Check whether automation or scripted configuration management may have applied the change.
7. 7Review recent change records.
8. 8Assess whether account compromise may be involved.

Practical business implications

Configuration changes can cause downtime. One incorrect VLAN, route, ACL or trunk command can affect many users simultaneously. Test changes during an approved maintenance window and retain rollback commands.

Unsaved configuration creates hidden risk. A device may appear to be running correctly until the next restart reveals that changes made during an incident response were never saved.

Shared accounts reduce accountability. Named accounts and centralised AAA allow changes to be attributed to specific administrators and reviewed after the fact.

Logging needs accurate time. A timestamp is useful only when the device clock is correct and synchronised to a reliable time source.

Configuration backups are sensitive. Network configuration files must be protected like other privileged information. They may contain credentials, ACLs, shared secrets and infrastructure details that could assist an attacker.

Legacy protocols create avoidable risk. Telnet, insecure SNMP communities and unencrypted configuration transfers should be removed where practical. This is rarely a major project — it is usually a configuration change during a maintenance window.

Documentation matters. The command alone does not explain why the configuration exists. An interface description, a VLAN name and a change record collectively make a network understandable to the next administrator.

The IT Club view

Cisco IOS is powerful partly because small commands can make substantial changes. That makes a command cheat sheet useful, but also potentially dangerous. An administrator who arrives at a device with a list of commands and no plan is more likely to cause an incident than resolve one.

The right questions before running any command are not only “What command do I type?” but also: Which mode am I in? What device and software version is this? What will the command change? How will I verify it? Could it disconnect me? What is the rollback? Has the configuration been backed up? Should this change be saved immediately?

IT Club recommends: inspect before changing, record before and after state, use secure management, preserve console access, avoid shared credentials, centralise logs, back up configuration securely, test restoration, review legacy protocols and maintain a change record.

A good Cisco command reference helps you work faster. A good operational process stops speed becoming downtime.

Related business questions

Administrator technical note

The operational heartbeat

Network configuration drifts as administrators change, VLANs are added, ports are repurposed, temporary ACLs remain in place, old accounts survive staff departures, firmware becomes unsupported, logging stops forwarding, NTP loses its source, configuration backups fail silently, SNMP communities remain from previous deployments, trunks accumulate unnecessary VLANs, unused ports stay active, local passwords are shared and undocumented static routes accumulate.

A recurring review should check: current running configuration, saved startup configuration, secure external backup, restore testing, administrator accounts, AAA, SSH configuration, Telnet disabled, SNMP version, central logging, NTP synchronisation, ACL review, VLAN list, trunk configurations, unused ports, Spanning Tree topology, DHCP protections, firmware version and support status, configuration drift, change records and next review date.

Related reading: Are You Sure Your Windows Backup Settings Are Protecting Your Files? →