Cisco / IOS · Tutorial · July 2026

Cisco IOS
First Contact

Your first hour on a Cisco switch or router. No prior IOS experience assumed — we start at the console cable, learn the three command modes, run only safe commands until you're confident, then set a hostname, a password, and SSH access from scratch.

Cisco IOS CLI Console SSH Catalyst CCNA Beginner

Every Cisco switch and router ships with the same command-line operating system: IOS (or IOS-XE on newer gear — same CLI for everything in this tutorial). There is no Winbox, no web wizard you should rely on. The CLI is the device. Learn it once and you can configure a $200 Catalyst or a $20,000 core router with the same muscle memory.

This tutorial is for someone who has never typed a command on a Cisco box — a CCNA student, a MikroTik admin crossing over, or a technician who just inherited a rack of switches. We start at the console cable, spend real time on the three command modes (the thing that confuses everyone at first), run only read-only show commands until you trust yourself, and finish by setting a hostname, a password, and working SSH access. By the end you'll be able to safely poke around any Cisco device you're handed.

Prerequisites

A Cisco switch or router (real hardware, or a lab in Packet Tracer / GNS3 / CML)
A console cable (blue rollover, or USB-to-console) and a terminal emulator — PuTTY, screen, or minicom
CCNA-level concepts help — you know what an IP address, VLAN, and interface are — but no CLI experience is required
No fear of a blank Switch> prompt. That's what section 01 is for.

Getting In — The Console

A brand-new Cisco device has no IP address and no SSH. The only way in is the console port — a physical cable and a terminal emulator. This never fails, so it's always your fallback.

SSH and Telnet need an IP address and configuration that a factory-fresh device doesn't have yet. The console port is the out-of-band way in: a direct serial connection that works before anything is configured, and still works when you've locked yourself out over the network. Every serious Cisco tech keeps a console cable in their bag.

Connect the Cable

Plug the rollover/USB-console cable into the port labelled CONSOLE on the device and into your laptop. On modern gear it's a USB-C or mini-USB console port; on older kit it's the light-blue RJ-45 rollover cable into a USB-serial adapter. Your laptop sees it as a serial (COM) port.

Your laptop — open the console (macOS / Linux)

# Find the serial device that appeared when you plugged in
user@laptop:~$ ls /dev/tty.* /dev/ttyUSB*   # macOS: tty.usbserial-XXXX · Linux: ttyUSB0

# Open it at 9600 baud — the Cisco console default
user@laptop:~$ screen /dev/tty.usbserial-A5069RR4 9600
# (Linux example:  screen /dev/ttyUSB0 9600  — or use minicom)

# Press Enter a couple of times. You should see a prompt appear:
Switch> ▌
# To quit screen later:  Ctrl+A then \  (confirm with y)

On Windows, use PuTTY: choose Serial, set the COM port (check Device Manager), and set the speed to 9600. The console line settings are always the same on Cisco gear:

Setting	Value
Speed (baud)	9600
Data bits	8
Parity	None
Stop bits	1
Flow control	None

⚠ Gotcha — Blank Screen After Connecting

A black, unresponsive console is almost always one of three things: (1) wrong baud rate — it must be 9600 (a few devices ship at 115200; try that if 9600 is silent); (2) flow control set to something other than None, which freezes input; or (3) the wrong COM/tty device. Press Enter a few times — if the device is mid-boot you'll see boot messages, and the prompt appears once it finishes. It's not broken; it's waiting.

The Three Modes

This is the one concept that trips up every beginner. IOS has distinct modes, and what you're allowed to type depends entirely on which one you're in. Read the prompt — it tells you where you are.

The prompt's punctuation is not decoration. The character after the hostname tells you your mode and therefore your power level. Learn to read it before you type anything.

IOS — prompt anatomy, from least to most powerful

Switch>
 │     └─ ">"  User EXEC mode — look-only. A handful of harmless commands.
 └─────── hostname (default "Switch" on a switch, "Router" on a router)

Switch#
       └─ "#"  Privileged EXEC — full read access: show, copy, reload, debug.

Switch(config)#
             └─ "(config)#"  Global Config — this is where you CHANGE things.

Switch(config-if)#
                 └─ a sub-mode — you're now configuring one interface.

Moving Between Modes

You climb up with enable and configure terminal, and come back down with exit, end, or Ctrl+Z.

IOS — walking up and down the modes

# Start in User EXEC (the ">"). Climb to Privileged EXEC:
Switch> enable
Switch# ← the "#" means you now have full privileges

# Enter Global Config to change the device:
Switch# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Switch(config)#

# Drop into a sub-mode (here: one interface):
Switch(config)# interface GigabitEthernet0/1
Switch(config-if)#

# "exit" steps DOWN one level:
Switch(config-if)# exit
Switch(config)#

# "end" (or Ctrl+Z) jumps ALL the way back to Privileged EXEC:
Switch(config)# end
Switch#

# "disable" drops from Privileged back to plain User EXEC:
Switch# disable
Switch>

⚠ Gotcha — "Invalid input" Usually Means Wrong Mode

If IOS rejects a command with % Invalid input detected at '^' marker, nine times out of ten you're in the wrong mode — you tried a show command inside (config)#, or a config command from Switch>. Check the prompt. To run a show command without leaving config mode, prefix it with do (see the pro tip in section 04). If instead you see % Incomplete command, the syntax is right but you're missing an argument — press ? to see what's expected.

Your Best Friends: ? and Tab

You do not memorise IOS commands. You discover them. The "?" key lists what's available at any point, Tab completes what you've started, and IOS accepts any unambiguous abbreviation.

? — Context-Sensitive Help

Type ? anywhere — on its own, after a word, or jammed against a half-typed word — and IOS tells you what's valid at that exact spot.

IOS — ? at different points

# "?" on its own — every command available in this mode
Switch# ?
  configure    Enter configuration mode
  copy         Copy from one file to another
  ping         Send echo messages
  reload       Halt and perform a cold restart
  show         Show running system information
  ...

# A word + " ?" — what can follow this command
Switch# show ?
  interfaces   Interface status and configuration
  ip           IP information
  running-config  Current operating configuration
  version      System hardware and software status
  vlan         VLAN information
  ...

# "?" jammed onto a partial word — how does this command finish?
Switch# show ver?
version

Tab — Complete It · Abbreviation — Skip It

Press Tab to expand a partial keyword to its full form. Even better: you don't have to. IOS runs any abbreviation that's unambiguous — sh ip int br is the same as show ip interface brief. Experienced operators live on abbreviations.

IOS — Tab completion and abbreviation

# Tab expands a partial keyword
Switch# conf[Tab]
Switch# configure

# These four lines are IDENTICAL to IOS — abbreviation just works:
Switch# show ip interface brief
Switch# sh ip int brief
Switch# sh ip int br
Switch# sho ip in b

# The only rule: the abbreviation must be unambiguous. "sh c" fails
# because "clock", "cdp" and others all start with c:
Switch# sh c
% Ambiguous command:  "sh c"

💡 Pro Tip — ↑ Recalls, and the CLI Never Judges You

Press ↑ to cycle back through commands you've already typed — edit and re-run instead of retyping. Combine the three tools as a workflow: type a couple of letters, press ? to see your options, Tab to complete, ↑ to repeat. You never need to type a full command from memory, and reading ? first means you understand a command before you run it.

Safe Show Commands Safe to Run

Start every session here. Every "show" command is read-only — it displays state and changes nothing. Run these freely on any live device to understand what you're looking at before you touch a thing.

Before changing anything, build a picture of the device. These commands are the ones you'll type hundreds of times a week. All of them are safe on production gear.

IOS — the essential read-only show commands

# Model, IOS version, uptime, serial number — always start here
Switch# show version
Cisco IOS Software, C2960X Software, Version 15.2(7)E3
System uptime is 27 weeks, 4 days, 4 hours, 11 minutes
Model number      : WS-C2960X-24TS-L
System serial number : FOC2145X0AB

# The single most useful command: every interface, its IP, and its status
Switch# show ip interface brief
Interface        IP-Address    OK?  Method  Status   Protocol
Vlan1            192.168.1.10  YES  manual  up       up
GigabitEthernet0/1  unassigned  YES  unset   up       up
GigabitEthernet0/2  unassigned  YES  unset   down     down

# Physical port view: speed, duplex, and which VLAN each access port is in
Switch# show interfaces status
Port    Name    Status       Vlan   Duplex  Speed Type
Gi0/1           connected    10     a-full  a-1000 10/100/1000BaseTX
Gi0/2           notconnect   1      auto    auto   10/100/1000BaseTX

# VLANs and which ports belong to each (switch only)
Switch# show vlan brief

# The MAC address table — which device is learned on which port
Switch# show mac address-table

# The routing table (routers, and switches doing L3)
Switch# show ip route

# Directly-connected Cisco neighbours — great for mapping a rack
Switch# show cdp neighbors

# The full running configuration — everything the device is doing right now
Switch# show running-config

Filtering Long Output

show running-config can be hundreds of lines. Pipe it through include, section, or begin to cut it down — the equivalent of grep.

IOS — the output pipe (| include / section / begin)

# Only lines containing "ip address"
Switch# show running-config | include ip address

# The whole config block for one interface
Switch# show running-config | section interface GigabitEthernet0/1

# Start the output from the first line that matches, then show the rest
Switch# show running-config | begin line vty

# Also works on any show command — e.g. only "up" interfaces
Switch# show ip interface brief | include up

💡 Pro Tip — Run a show Command Without Leaving Config Mode

Deep inside (config-if)# and need to check something? You don't have to end and come back. Prefix any privileged command with do: do show ip interface brief runs it right there and drops you back exactly where you were. This one keyword saves an enormous amount of mode-hopping.

Your First Real Config Modifies Config

Now we change things. A hostname, a login banner, and passwords — the minimum every device should have before it goes into a rack. All of this happens in Global Config.

IOS — hostname, DNS-lookup fix, and a banner

Switch# configure terminal
Switch(config)# hostname ACCESS-SW1
ACCESS-SW1(config)# ← the prompt updates instantly

# Stop IOS from trying to DNS-resolve your typos (a 30-second hang otherwise)
ACCESS-SW1(config)# no ip domain-lookup

# A legal banner shown at login (the ^ characters delimit the text)
ACCESS-SW1(config)# banner motd ^Authorised access only. NOCTIS-managed device.^

⚠ Gotcha — enable password vs enable secret

There are two commands to protect Privileged EXEC mode. enable password stores the password in clear text (or trivially reversible). enable secret stores a proper hash. Always use enable secret, and never bother with enable password — if both are set, secret wins and password is just a liability sitting in your config.

IOS — passwords: enable secret, console, and VTY lines

# Protect Privileged EXEC with a hashed secret
ACCESS-SW1(config)# enable secret S0meStr0ng!Pass

# Password on the console line (physical access)
ACCESS-SW1(config)# line console 0
ACCESS-SW1(config-line)# password C0ns0le!Pass
ACCESS-SW1(config-line)# login
ACCESS-SW1(config-line)# exec-timeout 10 0   # auto-logout after 10 min idle
ACCESS-SW1(config-line)# exit

# Password on the VTY lines (remote Telnet/SSH sessions — 0 through 4 = 5 lines)
ACCESS-SW1(config)# line vty 0 4
ACCESS-SW1(config-line)# password Vty!Pass
ACCESS-SW1(config-line)# login
ACCESS-SW1(config-line)# exit

# Encrypt the clear-text passwords sitting in the config (weak, but no reason not to)
ACCESS-SW1(config)# service password-encryption

Enabling SSH — The Modern Way

Telnet sends your password across the wire in clear text. Never use it. Here's the full recipe to reach the device securely over the network — five ingredients, in order.

SSH needs four things before it works: a hostname (done), a domain name, RSA crypto keys, and a local user account. Then you point the VTY lines at SSH-only and log in with that account.

IOS — enable SSH from scratch

ACCESS-SW1(config)# # 1. A domain name is required to generate keys
ACCESS-SW1(config)# ip domain-name noctis.lan

# 2. Generate the RSA key pair. 2048 bits is the sane minimum.
ACCESS-SW1(config)# crypto key generate rsa modulus 2048
The name for the keys will be: ACCESS-SW1.noctis.lan
% Generating 2048 bit RSA keys, keys will be non-exportable...[OK]

# 3. A local username with a hashed secret (privilege 15 = full access on login)
ACCESS-SW1(config)# username admin privilege 15 secret Adm1n!Str0ng

# 4. Force SSH v2 and reject the older, weaker v1
ACCESS-SW1(config)# ip ssh version 2

# 5. Point the VTY lines at SSH only, and authenticate against local users
ACCESS-SW1(config)# line vty 0 4
ACCESS-SW1(config-line)# transport input ssh   # SSH only — Telnet now refused
ACCESS-SW1(config-line)# login local          # use the "admin" account above
ACCESS-SW1(config-line)# end

You also need a management IP so the device is reachable. On a switch, that's an IP on a VLAN interface plus a default gateway:

IOS — a management IP on a switch (SVI)

ACCESS-SW1(config)# interface vlan 1
ACCESS-SW1(config-if)# ip address 192.168.1.10 255.255.255.0
ACCESS-SW1(config-if)# no shutdown
ACCESS-SW1(config-if)# exit
ACCESS-SW1(config)# ip default-gateway 192.168.1.1
ACCESS-SW1(config)# end

Your laptop — test the SSH login

user@laptop:~$ ssh admin@192.168.1.10
Password: 
# nothing echoes as you type — that's normal
ACCESS-SW1# ← you're in over SSH, straight to Privileged EXEC (privilege 15)

⚠ Gotcha — SSH Still Refuses the Connection

Three usual suspects: (1) keys weren't generated — show ip ssh should report SSH enabled and version 2.0; (2) you set login local but never created a username, so there's no account to log in with — you'll be locked out over the network (console in and fix it); (3) no IP reachability — confirm the SVI is up/up and you can ping the device first. This is exactly why you keep the console cable handy.

Saving: running-config vs startup-config

The single most expensive beginner mistake on Cisco gear. Your changes are live the instant you type them — but they are not saved. A power cut and it's all gone. Understand these two files.

IOS keeps two configurations. Everything you just typed went into running-config — the live config in RAM, active immediately. The device boots from startup-config in NVRAM. If you don't copy one to the other, a reboot reverts every change you made.

IOS — save your work (do this constantly)

# The full command — copy running-config into startup-config
ACCESS-SW1# copy running-config startup-config
Destination filename [startup-config]? ← just press Enter
Building configuration...
[OK]

# The old-school shortcut everyone actually types — same thing:
ACCESS-SW1# write memory
# or even shorter:  wr

# Confirm what's saved vs what's live (this diff should be empty after a save)
ACCESS-SW1# show startup-config
ACCESS-SW1# show running-config

⚠ Gotcha — "It Worked Yesterday, Now It's Gone"

You configured a switch, tested it, everything worked — then weeks later a power blip rebooted it and half your config vanished. That's an unsaved running-config. Build the habit: after every change that works, type wr. Conversely, this behaviour is a safety net — if you break something badly and haven't saved, a reload (without saving) reverts you to the last good startup-config. Just never reload a device you can't physically reach without being sure of what's in startup.

Cheatsheets

The commands and keystrokes you'll reach for daily. Memorise the top rows; the rest you'll absorb by using them.

Everyday Commands

Command	What it does
enable	User EXEC → Privileged EXEC (the "#" prompt).
configure terminal	Privileged EXEC → Global Config. Abbreviate: `conf t`.
end	Jump from any config sub-mode straight back to Privileged EXEC.
show ip interface brief	Every interface, its IP, and up/down status. The workhorse.
show running-config	The full live config. Pipe with `\| include` or `\| section`.
show version	Model, IOS version, uptime, serial number.
show vlan brief	VLANs and their member ports (switch).
copy run start	Save running-config to startup-config. Or `wr`.
do <show ...>	Run a Privileged command from inside config mode.
reload	Reboot the device. Prompts to save first.

Keyboard Shortcuts

Key	What it does
`?`	Context help — list valid commands or options at the cursor.
`Tab`	Complete the current keyword.
`↑` / `↓`	Cycle through command history.
`Ctrl`+`Z`	Same as `end` — exit config mode to Privileged EXEC.
`Ctrl`+`C`	Abort the current command / break out of a running one.
`Ctrl`+`Shift`+`6`	Break out of a stuck ping/traceroute/DNS lookup.
`Ctrl`+`A` / `Ctrl`+`E`	Jump to start / end of the line.
`Space` / `Enter`	At a `--More--` prompt: next page / next line.

A Full Workflow — Start to Finish

Everything above, in the order you'd actually do it: console into a factory-fresh switch and leave it named, secured, reachable over SSH, and saved.

IOS — box out of the shrink-wrap to production-ready

# Console in, skip the setup wizard if prompted (answer "no"), then:
Switch> enable
Switch# configure terminal

# Identity + quality-of-life
Switch(config)# hostname ACCESS-SW1
ACCESS-SW1(config)# no ip domain-lookup
ACCESS-SW1(config)# banner motd ^Authorised access only.^

# Passwords
ACCESS-SW1(config)# enable secret S0meStr0ng!Pass
ACCESS-SW1(config)# service password-encryption
ACCESS-SW1(config)# line console 0
ACCESS-SW1(config-line)# password C0ns0le!Pass
ACCESS-SW1(config-line)# login
ACCESS-SW1(config-line)# exec-timeout 10 0
ACCESS-SW1(config-line)# exit

# Management IP + gateway
ACCESS-SW1(config)# interface vlan 1
ACCESS-SW1(config-if)# ip address 192.168.1.10 255.255.255.0
ACCESS-SW1(config-if)# no shutdown
ACCESS-SW1(config-if)# exit
ACCESS-SW1(config)# ip default-gateway 192.168.1.1

# SSH
ACCESS-SW1(config)# ip domain-name noctis.lan
ACCESS-SW1(config)# crypto key generate rsa modulus 2048
ACCESS-SW1(config)# username admin privilege 15 secret Adm1n!Str0ng
ACCESS-SW1(config)# ip ssh version 2
ACCESS-SW1(config)# line vty 0 4
ACCESS-SW1(config-line)# transport input ssh
ACCESS-SW1(config-line)# login local
ACCESS-SW1(config-line)# end

# Verify, then SAVE — the step everyone forgets
ACCESS-SW1# show ip interface brief
ACCESS-SW1# write memory
Building configuration...
[OK]

Takeaways

Read the prompt before you type. > is look-only, # is full access, (config)# changes the box. Almost every "Invalid input" error a beginner hits is really a wrong-mode error.
The console cable is your parachute. It works before any config exists and after you've locked yourself out over the network. Keep one in your bag; every remote-management recipe assumes you can fall back to it.
? and Tab mean you never memorise commands. Discover them at the prompt. And abbreviate freely — sh ip int br is real, fast, and exactly equal to the full command.
Start every session with show. Read-only commands change nothing. Build a picture of the device before you touch it, and use | include / | section to cut long output down.
Use enable secret, never enable password; use SSH, never Telnet. The insecure options exist only for backward compatibility. There is no reason to choose them on anything you deploy.
Changes are live but not saved. running-config is RAM; startup-config is what boots. After anything that works, type wr. The one time you skip it is the time a power cut erases an afternoon of work.
The same CLI runs everything. A $200 access switch and a core router speak the same IOS. The muscle memory you build in this first hour scales to every Cisco box you'll ever touch.

Rolling out Cisco switches for an office, hotel, or SMB in Crete?

NOCTIS designs, configures, and documents Cisco networks — from a single access switch to a multi-VLAN site. We hand over clean, commented configs your team can actually read, not a black box only one person understands.

Book a Discovery Call →