Cisco IOS / IOS XE Commands Cheat Sheet for Network Admins

Key takeaways

• Modern Catalyst switches run IOS XE, so classic IOS muscle memory carries over with a handful of new modes and programmability hooks.
• Knowing your CLI mode and leaning on the question mark and Tab does more for speed than memorizing flags.
• show commands are where troubleshooting actually happens; configuration is the smaller, riskier part of the job.
• A change that works but was never written with copy running-config startup-config is one reload away from gone.
• reload in, configure replace, and archive give you a safety net before risky remote edits.
• At scale, the by-hand show-and-save cycle should move into Catalyst Center or a managed model rather than living in the CLI.

Know your mode before you touch the keyboard

The Cisco command line is layered, and the single biggest source of confusion for newer admins is not knowing which layer they are standing in. You land in user EXEC mode, type enable to reach privileged EXEC, run configure terminal to drop into global configuration, then step further into interface, line, or VLAN sub-modes from there. The prompt is your map. A trailing > means user EXEC, a # means privileged, and a descriptive tag like (config-if)# tells you that the next command applies to a single interface and nowhere else. Read the prompt before every change and you avoid the classic mistake of typing a global command while scoped to one port.

Most of the gear you actually touch today runs IOS XE rather than the classic IOS that older cheat sheets were written for. The Catalyst 9000 family that anchors most refreshes is IOS XE end to end, which is why the syntax in this reference is current rather than nostalgic. If you are standardizing on those platforms across a campus, our Catalyst switching overview lays out where each model fits, and the Cisco Catalyst 9300 data sheet is the authoritative spec source when a question turns into an argument about port counts or stacking.

Two keys carry more weight than any list of commands. The question mark, typed after a partial command, shows you exactly what is valid in context, and Tab completes a keyword you have started. Together they turn the device into a live reference, so you stop guessing flags and let the box tell you what it expects. New admins who build that habit early stop reaching for printed sheets within a week.

Look before you touch: the show commands

Troubleshooting is mostly reading. The fastest health snapshot on any switch is show ip interface brief, one line per interface with status and address, and show interfaces status, which adds speed, duplex, and the VLAN per port so you can confirm a switchport is doing what you assume it is. When you need the full picture, show running-config gives you the active configuration, but pipe it rather than scrolling: show running-config | section interface or show running-config | include vlan pulls just the part you care about out of a file that can run thousands of lines.

For the layer-2 view, a few commands answer almost every question. show vlan brief lists VLANs and their member ports, show mac address-table tells you which MAC lives behind which port, and show cdp neighbors detail (or show lldp neighbors detail for mixed-vendor environments) maps what is physically wired to each interface. Wrap any of these in terminal length 0 first when you want the whole output without paging through it screen by screen.

These are the commands you run before you change anything, and the same ones you run again afterward to prove the change did what you intended. That before-and-after ritual is the difference between a clean edit and a guess. Treat the show output as your evidence, not your hope, and keep a scratch file of the relevant snapshots so a rollback decision later is based on what the box actually looked like.

• show ip interface brief: one-line interface status and addressing
• show interfaces status: speed, duplex, and access VLAN per port
• show vlan brief and show mac address-table: the layer-2 map
• show cdp neighbors detail: physical topology and neighbor IOS versions
• show logging: what the box has been quietly complaining about

Making changes without breaking things

Configuration follows a predictable pattern once you internalize it. Enter global config with configure terminal, scope down to the object you are changing such as interface GigabitEthernet1/0/1 or vlan 20, make the edit, then back out. A standard access port is switchport mode access followed by switchport access vlan 20. A trunk is switchport mode trunk paired with switchport trunk allowed vlan to constrain exactly which VLANs cross the link, because an unconstrained trunk is how broadcast domains quietly bleed into each other.

The discipline that prevents outages is narrow verification. Run show running-config interface for that specific port before and after the edit so you see precisely what you altered, nothing more and nothing less. On IOS XE you also have configure replace and the archive feature, which let you snapshot a known-good config and roll the entire device back to it in one command if an edit goes sideways. That is a meaningful upgrade over the old copy-paste-and-pray recovery on classic IOS.

When the change is part of a real cutover rather than a quick fix, the CLI is only one tool in a larger plan. We run production migrations through a staged sequence with tested rollback at each step under our deployment and cutover practice, and we pressure-test the design itself first through network design so the commands you type on cutover night are executing a plan, not improvising one. A cheat sheet speeds up the typing; it does not replace a change window with a rollback path.

Saving, recovery, and the commands that save your weekend

The command that ends every session is the one people forget under pressure: copy running-config startup-config, or the shorthand write memory, from privileged EXEC. The running configuration is what is active right now; the startup configuration is what loads on reboot. A change that works but was never saved survives exactly until the next reload, and then it is gone, which is a brutal way to learn the lesson at 2 a.m.

A handful of commands are pure insurance before a risky remote edit. reload in 10 schedules a reload ten minutes out that you cancel with reload cancel once you confirm your session survived; if the edit locks you out, the box reboots to the last saved config on its own and you keep your job. show version tells you the IOS XE train and uptime, which matters because end-of-support software is a compliance and security liability under Cisco's published end-of-life policy. And show inventory pulls the serials you need for warranty and support registration.

Those serials feed directly into support coverage, and a switch running an unsupported image is one you cannot get a TAC case opened on when it fails. Keeping inventory accurate and contracts current through Cisco Smart Net Total Care is the unglamorous half of lifecycle work that the CLI feeds. If renewals have drifted out of sync with what is actually racked, a Smartnet renewal quote is the fastest way to reconcile the two before an outage forces the issue.

Hardening from the CLI: where compliance gets real

For federal, DoD, healthcare, and SLED environments, the command line is also where security controls actually land. The same CLI you use to bring up a port is where you disable unused services, force SSH and turn off Telnet, set login banners, scope access with AAA, and apply the configuration baselines that auditors will check line by line. Commands like transport input ssh on your VTY lines, no ip http server where it is not required, and service password-encryption are small edits with outsized audit weight.

Those edits are not arbitrary preferences. They map to DISA's Security Technical Implementation Guides, which prescribe device-level settings for DoD networks, and to control families in NIST SP 800-53 that govern federal systems more broadly. Reading a STIG and translating each finding into the exact IOS XE command is its own skill, and getting it wrong shows up as a finding during assessment rather than a friendly warning.

This is where a cheat sheet stops being enough and a methodology takes over. Our security engineering and defense teams turn those frameworks into a repeatable, evidence-producing hardening baseline so the same controls land identically on every device instead of drifting box by box. For agencies buying through established vehicles, aligning that work with the right contract path keeps procurement and compliance moving together rather than colliding at the finish line.

When the CLI stops scaling

Every command in this reference is fine to run by hand on a closet switch or two. The trouble starts when by-hand becomes the operating model for hundreds of devices. Running show-and-save on every box during a maintenance window, or chasing a config drift across a campus one terminal session at a time, does not scale, and it is exactly the repetitive work that swallows a network team's week and introduces inconsistency between devices that should be identical.

IOS XE was built with that problem in mind. Model-driven programmability, NETCONF and RESTCONF interfaces, and template-driven provisioning let you push a known-good configuration to many devices at once and verify compliance continuously rather than device by device. Cisco Catalyst Center is the platform that operationalizes this, turning the commands you would otherwise type into templates, automated assurance, and drift detection across the fleet.

When even that is more than an in-house team should carry, the routine cycle belongs in a managed model. Our managed operations practice owns the recurring show-and-save, the change windows, and the lifecycle bookkeeping so your engineers are not living in the CLI for maintenance that should be automated. If your team is spending more time on routine config work than on the projects that move the network forward, a conversation about your environment is usually the cheapest way to find out what can be handed off.

How the syntax connects to the standards underneath

None of these commands exist in a vacuum, and understanding why they look the way they do makes them easier to remember. The protocols you configure here, spanning tree, VLAN tagging with 802.1Q, link aggregation with LACP, trace back to IEEE standards rather than to Cisco invention. That is why the underlying logic transfers across vendors even when the exact keywords differ, and why an admin who understands the standard adapts faster than one who only memorized the syntax.

The same is true on the wireless side. As campuses move to Wi-Fi 7 and the Catalyst 9100 and 9176 access points, the controller CLI and the wired switch CLI increasingly share IOS XE conventions, so the show-and-save habits you build on switching carry directly into wireless operations. Spectrum rules from the FCC and certification programs from the Wi-Fi Alliance shape what those access points can do, but the command discipline is identical to the wired world.

Treat this reference as a foundation rather than a finish line. The commands that matter most are the ones you run to confirm reality before and after a change, the one you run to save your work, and the one you keep in your back pocket to recover when an edit goes wrong. Everything past that is platform-specific detail that the question mark will surface faster than any printed sheet, and that a tested change plan will protect better than any amount of typing speed.

Cisco products involved

• Cisco IOS XE
• Cisco Catalyst 9300 Series
• Cisco Catalyst 9200 Series
• Cisco Catalyst 9000 switching
• Cisco Catalyst Center
• Cisco Catalyst 9176 Access Points
• Cisco Smart Net Total Care

Bottom line: Keep the show commands close, save every change, and reserve hand-typed CLI for work that genuinely needs it. If routine maintenance is eating your week, our managed operations team can take the show-and-save cycle off your plate.