Jump to chapter (12)
What you will learn, and what Cisco IOS is
What you will learn in this module. By the end of these chapters you will be able to connect to a brand-new Cisco switch or router, move confidently between its command modes, use the built-in help instead of memorising everything, give the device a name, protect it with passwords, put IP addresses on its interfaces, check your work with show commands and save the result so it survives a reboot. You will also know what happens when a device boots, where its configuration lives, and how to troubleshoot the classic first-day problem: "I cannot ping my router".
Prerequisites. You should have finished the Networking from absolute zero module, so you know what a switch, a router, an IP address and a subnet mask are, and why a PC needs a default gateway. You do not need any Cisco experience. Every command in this module is explained the first time it appears, and the three labs let you practise each one on a simulated switch and router.
Start with an analogy: IOS is the reception desk of a secure office building
Imagine a large office building. At the front there is a reception desk. A visitor can ask the receptionist simple questions ("what floor is accounts on?") but cannot change anything. An employee who shows a badge can walk further inside and look at every file. A manager with a master key can enter the control room and change how the whole building works: rename meeting rooms, change door codes, rewire the lifts. Inside the control room there are smaller rooms for specific jobs: one for the lifts, one for the doors, one for the lights.
Cisco IOS (Internetwork Operating System) works the same way. It is the operating system that runs on Cisco routers and switches, and you talk to it through a command-line interface (CLI). The CLI has levels: a visitor level where you can only look (user EXEC), an employee level where you can see everything and run tests (privileged EXEC), a control room where you change the configuration (global configuration), and small rooms for one interface or one line (sub-modes). The prompt at the end of the line tells you which room you are standing in.
Each level lets you do more. The prompt is your "you are here" sign.
Why a command line, and not a web page?
Many devices today also offer a web GUI or are managed by a controller, and you will study automation and controllers later in the CCNA. But the CLI is still the tool every network engineer uses daily, for four reasons:
- It is always there. A device with no IP address and no configuration still has a console port and a CLI. The GUI needs an IP address first.
- It is precise. A command does exactly one thing, and the running configuration is plain text you can read, copy, compare and back up.
- It scales. The same text you type can be pasted into a hundred devices or sent by an automation script.
- It is what the exam and interviews test. CCNA questions show CLI output and ask what it means.
The IOS family
"IOS" is used loosely for several related Cisco operating systems. Classic IOS ran on older ISR routers and Catalyst switches. IOS XE runs on current Catalyst 9000 switches and ISR 4000 / Catalyst 8000 routers; it is Linux-based underneath but gives you the same CLI. NX-OS (Nexus data center switches) and IOS XR (service provider routers) look similar but have their own differences. For the CCNA, everything you learn here applies to IOS and IOS XE, and the habits carry over to the others.
| OS | Where you meet it | CLI feel |
|---|---|---|
| IOS / IOS XE | Campus switches, branch routers | The CLI taught in this module |
| NX-OS | Nexus data center switches | Very similar, features enabled with feature |
| IOS XR | Service provider routers | Similar, but changes need commit |
The lab network you will build
All three labs use the same tiny office: one PC, one switch and one router on the subnet 192.168.10.0/24. The router is the default gateway at 192.168.10.1, the switch gets a management address 192.168.10.2, and the PC is 192.168.10.10.
The same three devices appear in every lab and example in this module.
Worked example. A fresh router boots and shows Router>. You type enable and see Router#. You type configure terminal and see Router(config)#. You type hostname R1 and the prompt instantly becomes R1(config)#. Four prompts, three levels, one change. That tiny sequence is the pattern for everything you will ever configure on IOS.
Common beginner mistake. Treating the CLI like a chat window and typing commands without looking at the prompt. Most "command not working" problems in the first week are simply the right command typed in the wrong mode. Always read the prompt before you type.
Exam trap. Questions often show a prompt and ask which command is possible there. > means user EXEC, # means privileged EXEC, and (config...)# means a configuration mode. Configuration commands never work at > or plain #.
The intern and the "broken" router
On her first day, an intern was asked to check a branch router's interfaces. She typed show running-config and got % Invalid input detected at '^' marker. She reported that the router was faulty. Her senior looked at the screen: the prompt was BR-R1>. She was in user EXEC, where the running configuration is not visible. One enable, one password, and the command worked.
Lesson: the prompt is the first thing to read. Most "errors" in IOS are mode errors.
"What is Cisco IOS and how do you normally interact with it?"
Strong answer: IOS is the operating system on Cisco routers and switches (IOS XE on current platforms). You manage it mainly through a hierarchical CLI, either locally over the console port or remotely over SSH. The CLI has user EXEC, privileged EXEC and configuration modes, and the prompt shows which one you are in. Mention that the active configuration is plain text in RAM (running-config) that must be saved to NVRAM (startup-config).
Key takeaways
- IOS is the operating system of Cisco routers and switches; IOS XE is its modern form with the same CLI.
- You talk to IOS through a command-line interface with levels, like rooms in a secure building.
- The prompt (
>,#,(config)#) tells you which level you are in. - The CLI works even on a device with no IP address, which is why every engineer must know it.
- All labs in this module use PC1, SW1 and R1 on 192.168.10.0/24.
Connecting to a device: console, terminal settings, boot and the setup dialog
A new switch arrives in a box. It has no IP address, so you cannot SSH to it and there is no web page to open. How do you talk to it? The same way a doctor talks to a patient who cannot answer the phone: you go and sit next to it. On network devices that bedside connection is the console port.
Out-of-band versus in-band access
Out-of-band access uses a dedicated path that does not depend on the production network: the console cable, or a separate management network. It works even when the device has no configuration or its interfaces are broken. In-band access travels over the normal network, using the device's IP address: SSH (encrypted, port 22) or Telnet (clear text, port 23). In-band is what you use every day; out-of-band is what saves you on the bad day.
The console needs no IP address. SSH and Telnet need a working IP path and configured VTY lines.
The console cable
Most Cisco devices have an RJ-45 port labelled CONSOLE (usually light blue). The classic cable is a rollover cable: flat and light blue, RJ-45 at one end and a DB-9 serial connector at the other. It is called rollover because pin 1 at one end goes to pin 8 at the other, pin 2 to pin 7, and so on. Laptops have no serial port today, so you add a USB-to-serial adapter. Many newer devices also have a USB console port (mini-B or USB-C); you connect a normal USB cable and install the driver. If both are connected, the USB console usually takes priority.
Terminal emulator settings
On the laptop you run a terminal emulator such as PuTTY, Tera Term, SecureCRT or screen on macOS and Linux. You pick the serial port the adapter created (COM3 on Windows, /dev/ttyUSB0 on Linux) and use the Cisco default settings:
| Setting | Value |
|---|---|
| Speed (baud) | 9600 |
| Data bits | 8 |
| Parity | None |
| Stop bits | 1 |
| Flow control | None |
Engineers say "9600 8N1, no flow control". If you see garbage characters, the speed is wrong. If you see nothing at all, press Enter a few times, check the COM port number, then the cable.
What happens when a Cisco device boots
Watching the console during boot tells you a lot. The sequence is:
- POST (power-on self-test) from ROM checks the CPU, memory and interfaces.
- The bootstrap program in ROM starts and reads the configuration register (normally 0x2102) to decide how to boot.
- It locates and loads IOS, normally from flash, into RAM. If no valid image is found, the device stops in ROMMON, a tiny recovery monitor.
- IOS looks for a saved configuration, the startup-config in NVRAM, and copies it into RAM as the running-config.
- If there is no startup-config, IOS offers the setup dialog.
ROM, flash, NVRAM, RAM: each boot step uses a different memory.
The setup dialog
A device with an empty NVRAM prints this near the end of the boot:
--- System Configuration Dialog ---
Would you like to enter the initial configuration dialog? [yes/no]: no
Would you like to terminate autoinstall? [yes]:
Press RETURN to get started!
Router>
The setup dialog asks questions (hostname, passwords, one interface) and builds a basic configuration for you. Engineers almost always answer no and configure by hand, because it is faster and you control every line. It is still an exam topic: know that it appears only when there is no startup-config, and that Ctrl-C aborts it. You can re-run it later from privileged EXEC with the command setup.
Worked example. You plug the rollover cable into R1's console, open PuTTY on COM4 at 9600 8N1, press Enter and see nothing. You check Device Manager: the adapter is actually on COM5. You reconnect on COM5, press Enter and get Router>. Total time wasted: two minutes. Always check the COM port first.
A preview of remote access
Once the device has an IP address, you stop using the console for daily work. Remote sessions arrive on virtual terminal lines called VTY lines (line vty 0 4 gives five simultaneous sessions, most switches have 0 15). In chapter 6 you will put a password on those lines; SSH, which replaces Telnet in real networks, is configured fully in the device-hardening module. In lab 3 you will test Telnet from PC1, because it needs only a password and shows clearly how VTY login works.
Common mistakes. Using a straight-through Ethernet cable in the console port (nothing appears); wrong baud rate (garbage characters); leaving flow control on hardware (keystrokes ignored); and forgetting that the console port is not an Ethernet port, so plugging it into a switch does nothing useful.
Exam traps. Default console settings are 9600 baud, 8 data bits, no parity, 1 stop bit, no flow control. The setup dialog runs only when NVRAM has no startup-config. Telnet is clear text on TCP 23; SSH is encrypted on TCP 22. The console is out-of-band; SSH and Telnet are in-band.
The remote site with no way in
A retail chain shipped a pre-configured router to a new store. A typo in the uplink IP address meant nobody at head office could SSH in. The store had no technician and no console cable. Two days were lost couriering a cable and talking a store manager through PuTTY at 9600 8N1. Afterwards the team added a small console server with a 4G modem at every site, giving them out-of-band access to every router console.
Lesson: in-band access fails exactly when you need it most. Plan out-of-band access before the outage, not during it.
"How do you connect to a brand-new switch that has no IP address?"
Strong answer: through the console port, using a rollover cable with a USB-to-serial adapter or the USB console port, and a terminal emulator set to 9600 baud, 8 data bits, no parity, 1 stop bit, no flow control. Mention that this is out-of-band access, that the device will offer the setup dialog if NVRAM is empty, and that after giving it an IP address and VTY passwords (ideally SSH) you manage it in-band.
Key takeaways
- The console port gives out-of-band access that works with no IP address and no configuration.
- Use a rollover cable (plus USB-serial adapter) or a USB console, at 9600 8N1, no flow control.
- Boot: POST, bootstrap reads the config register, IOS loads from flash, startup-config loads from NVRAM.
- No startup-config means the setup dialog appears; answer no and configure by hand.
- SSH (TCP 22) and Telnet (TCP 23) arrive on VTY lines and need an IP path; SSH is the secure choice.
Command modes: user EXEC, privileged EXEC, global and sub-configuration
Think of IOS modes as the floors of a building connected by one staircase. You always enter on the ground floor, you climb one floor at a time, and some doors on each floor lead to small side rooms. To do any job you must first walk to the right floor. Every IOS command belongs to one or more modes, and the prompt tells you which floor you are on.
The modes you must know
| Mode | Prompt | How you get there | What you can do |
|---|---|---|---|
| User EXEC | R1> | Log in on console or VTY | Basic show commands, ping, traceroute. No configuration, no running-config. |
| Privileged EXEC | R1# | enable | Every show command, debug, copy, reload, clear. Still no configuration. |
| Global configuration | R1(config)# | configure terminal | Commands that affect the whole device: hostname, enable secret, ip route, banner. |
| Interface config | R1(config-if)# | interface GigabitEthernet0/0 | Settings for one interface: IP address, description, shutdown. |
| Line config | R1(config-line)# | line con 0 or line vty 0 4 | Settings for the console or remote lines: password, login, exec-timeout. |
| Other sub-modes | (config-router)#, (config-vlan)# | router ospf 1, vlan 10 | Routing protocols and VLANs, covered in later modules. |
Climb with enable and configure terminal; step down with exit, jump down with end.
Moving between modes
Router> enable Router# configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router(config)# hostname R1 R1(config)# interface GigabitEthernet0/0 R1(config-if)# description LAN-to-SW1 R1(config-if)# exit ! exit goes up ONE level: back to global config R1(config)# line con 0 R1(config-line)# end ! end (or Ctrl-Z) jumps straight back to privileged EXEC R1# disable R1>
enablemoves from user to privileged EXEC (asking for the enable secret if one is set).configure terminal(usually typedconf t) enters global configuration.exitgoes up one level. In user or privileged EXEC,exitends the session completely.endor Ctrl-Z leaves any configuration mode and returns to privileged EXEC.disabledrops from privileged back to user EXEC.
Two helpful IOS behaviours
Changes take effect immediately. The moment you press Enter on a configuration command, it is active in the running-config. There is no "apply" button. That is powerful and dangerous: shutting the interface you are connected through cuts you off at once.
Global commands work from sub-modes. If you are in (config-if)# and type a global command such as line vty 0 4 or interface GigabitEthernet0/1, IOS accepts it and moves you to the new mode. You do not need to exit first. This is why pasted configurations work even without exit lines.
Worked example from lab 1. On the new switch you start at Switch>. show version works here. show running-config does not, so you type enable and the prompt becomes Switch#. Now show running-config and show ip interface brief work. configure terminal gives Switch(config)#, hostname LAB-SW1 changes the prompt to LAB-SW1(config)#, and end returns you to LAB-SW1#.
What it looks like when you try a command in the wrong mode:
Switch> show running-config
^
% Invalid input detected at '^' marker.
Switch> enable
Switch# show running-config
Building configuration...
The caret points to the first word IOS did not accept. Here it is under running-config: the show command exists in user EXEC, but that option does not.
Common mistakes. Typing exit at R1# and wondering why the session closed. Trying ping or show in config mode without do (chapter 9). Forgetting you are still inside an interface and applying a command to the wrong interface. Always glance at the prompt.
Exam traps. end and Ctrl-Z both return to privileged EXEC from any config mode; exit goes up only one level. enable is the only way from > to #. Configuration commands cannot be typed at # without configure terminal. configure terminal itself is a privileged EXEC command.
The interface that got the wrong description
An engineer labelled ports on a core switch. He entered interface GigabitEthernet1/0/10, set a description, then typed ip address for the next job without noticing he was still in the Gi1/0/10 sub-mode. The address landed on the wrong port and a server VLAN went down. show running-config interface GigabitEthernet1/0/10 revealed the mistake, no ip address removed it, and the change was repeated on the right interface.
Lesson: the prompt tells you the mode but not which interface. Re-enter the interface explicitly before each block of changes, and verify with show running-config interface.
"Walk me through the IOS command modes."
Strong answer: user EXEC (>) for basic monitoring; enable to privileged EXEC (#) for all show, debug, copy and reload; configure terminal to global config for device-wide settings; from there sub-modes such as interface, line, router and VLAN. exit goes up one level, end or Ctrl-Z returns to privileged EXEC. Add that configuration changes apply immediately to the running-config.
Key takeaways
- User EXEC
>→enable→ privileged EXEC#→configure terminal→(config)#. - Sub-modes such as
(config-if)#and(config-line)#configure one interface or one line. exitgoes up one level;endor Ctrl-Z returns straight to#.- Configuration changes take effect instantly in the running-config.
- "% Invalid input" very often means the right command in the wrong mode.
Help, shortcuts and IOS error messages
Nobody remembers every IOS command, not even engineers with twenty years of experience. What they remember is how to ask the device. Think of IOS as a patient shop assistant: you can say "what do you have?" at any moment, and it lists your options. That assistant is the question mark.
Context-sensitive help with ?
The ? key shows what you can type at this point, in this mode. There are two forms, and the space before the ? is what makes the difference:
| You type | IOS shows | Called |
|---|---|---|
? | Every command available in this mode | Command help |
cl? (no space) | Every word that starts with cl: clear clock | Word help |
clock ? (with space) | The next keyword or argument after clock | Command syntax help |
One space changes the question you are asking.
R1# cl?
clear clock
R1# clock ?
set Set the time and date
R1# show ip interface brief ?
| Output modifiers
<cr>
<cr> means "carriage return": the command is complete and you can press Enter. Arguments in angle brackets such as <1-15> or A.B.C.D tell you the type of value expected.
Tab completion and abbreviations
Type the first letters of a keyword and press Tab: IOS completes the word if only one keyword matches. Even without Tab, IOS accepts any unique abbreviation. That is why engineers type:
en ! enable conf t ! configure terminal sh ip int br ! show ip interface brief int g0/0 ! interface GigabitEthernet0/0 sh run ! show running-config wr ! write memory (saves the configuration)
The abbreviation must be unique in the current mode. c at R1# could be clear, clock, configure, connect or copy, so IOS refuses it as ambiguous.
Command history
IOS remembers your recent commands. Press the up arrow (or Ctrl-P) to recall the previous one and the down arrow (or Ctrl-N) to move forward again. show history lists the recent commands of this session; the buffer holds 10 commands by default and terminal history size 50 enlarges it for the current session. Recalling and editing a long command is much faster, and safer, than retyping it.
Keyboard shortcuts worth knowing
| Keys | Effect |
|---|---|
| Tab | Complete the current keyword |
| Ctrl-A / Ctrl-E | Jump to the start / end of the line |
| Ctrl-Z | Leave configuration mode (same as end) |
| Ctrl-C | Abort the current input; in config mode it returns to privileged EXEC |
| Ctrl-Shift-6 | Break sequence: interrupt a running ping, traceroute or name lookup |
| Space / Enter / q at --More-- | Next page / next line / stop the output |
Long output pauses at --More--. terminal length 0 turns paging off for the session, which is handy before copying a whole configuration.
The three error messages
R1# confgure terminal
^
% Invalid input detected at '^' marker.
R1# clock set
% Incomplete command.
R1# c
% Ambiguous command: "c"
- % Invalid input detected at '^' marker: the word under the caret is wrong (a typo, a keyword that does not exist, or the wrong mode). Look exactly where the caret points.
- % Incomplete command: the start is right but required arguments are missing. Recall the line and add
?to see what comes next. - % Ambiguous command: the abbreviation matches more than one keyword. Type more letters.
The "Translating..." freeze and no ip domain-lookup
If you mistype a command at an EXEC prompt, for example shw, IOS assumes the unknown word is a host name you want to Telnet to and tries to resolve it with DNS:
R1# shw
Translating "shw"...domain server (255.255.255.255)
% Unknown command or computer name, or unable to find computer address
With no DNS server configured it broadcasts and waits several seconds. Press Ctrl-Shift-6 to cut the wait short, and prevent it permanently in lab devices with no ip domain-lookup in global configuration, which you will do in lab 2.
Worked example. You need to set the clock but do not remember the format. clock ? shows set. clock set ? shows hh:mm:ss. clock set 10:30:00 ? shows the day, then month, then year. Four question marks later you typed clock set 10:30:00 29 September 2026 correctly on the first attempt, without a manual.
Common mistakes. Typing show? when you wanted show ? (you get word help instead of the options). Pressing Ctrl-C to stop a ping (use Ctrl-Shift-6). Retyping a 60-character command instead of using the up arrow. Ignoring where the caret points and re-typing the same typo.
Exam traps. ? directly after letters lists matching keywords; ? after a space lists the next argument. <cr> means the command is complete. The history buffer default is 10 commands. Ctrl-Shift-6 is the break sequence. Know the exact wording of Invalid, Incomplete and Ambiguous.
The five-minute ping
A trainee pinged an unreachable address with a repeat count of 10000 while troubleshooting and the console was locked, printing dots. She pressed Ctrl-C again and again with no effect and was about to pull the power. A colleague pressed Ctrl-Shift-6 and the ping stopped instantly, returning the prompt.
Lesson: on IOS the break sequence is Ctrl-Shift-6, not Ctrl-C. Learn it before you need it.
"You cannot remember the syntax of a command on a Cisco device. What do you do?"
Strong answer: use context-sensitive help. ? lists commands in the current mode, abc? lists keywords starting with abc, and command ? shows the next argument, with <cr> meaning the command is complete. Use Tab to complete, the up arrow to recall and edit, and read the caret in "% Invalid input" to see exactly which word was wrong.
Key takeaways
?is always available: without a space it completes a word, with a space it shows the next argument.- Tab completes keywords; any unique abbreviation works (
sh ip int br). - Up arrow / Ctrl-P recalls commands;
show historylists them (10 by default). - Ctrl-Z leaves config mode; Ctrl-Shift-6 interrupts ping, traceroute and DNS lookups.
- Invalid = wrong word (see the caret), Incomplete = missing argument, Ambiguous = abbreviation too short.
Running vs startup configuration, device memory and show version
Imagine writing an important document on a whiteboard. Everyone in the room can read it and act on it right now, but if the cleaner wipes the board overnight it is gone. To keep it, you must copy it into a notebook. On a Cisco device the whiteboard is the running-config in RAM and the notebook is the startup-config in NVRAM. Forgetting to copy from one to the other is the most expensive beginner mistake in networking.
The four kinds of memory
| Memory | Keeps data after power-off? | What lives there |
|---|---|---|
| ROM | Yes (read-only) | POST, bootstrap program, ROMMON recovery monitor |
| Flash | Yes | The IOS image file(s), and other files you copy there |
| NVRAM | Yes | The startup-config (the saved configuration) |
| RAM | No | The running IOS, the running-config, routing tables, ARP and MAC tables, packet buffers |
Every configuration command edits the running-config. Only a save writes it to NVRAM.
Running-config and startup-config
The running-config is the configuration the device is using at this moment. Every command you enter in configuration mode changes it instantly. The startup-config is the copy saved in NVRAM; it is loaded into RAM at boot and becomes the new running-config. The two stay different until you save.
R1# show running-config ! what is active now (RAM) R1# show startup-config ! what will load at next boot (NVRAM) R1# copy running-config startup-config Destination filename [startup-config]? ! press Enter to accept Building configuration... [OK] R1# write memory ! older command, same result
copy running-config startup-config (copy run start) is the official command; write memory (wr) is older and still works on IOS. The copy command always reads copy source destination, which helps you remember the direction.
Undoing and erasing
- To undo one command, repeat it with
noin front:no ip domain-lookupturned lookups off,ip domain-lookupturns them back on;no descriptionremoves a description. - To throw away all unsaved changes,
reloadwithout saving: IOS asks "System configuration has been modified. Save? [yes/no]" and you answer no. The device boots from the old startup-config. - To wipe a device back to factory state:
erase startup-config(orwrite erase), thenreload. On a switch you also deleteflash:vlan.datto remove VLANs, which you will meet in the VLAN module. copy startup-config running-configmerges the saved configuration into the current one; it does not replace it. That surprises many people.
Reading show version
show version works in user EXEC and is the first command many engineers run on an unknown device. This is output from a real ISR router:
Cisco IOS Software, C2900 Software (C2900-UNIVERSALK9-M), Version 15.7(3)M8, RELEASE SOFTWARE (fc2) ROM: System Bootstrap, Version 15.0(1r)M16, RELEASE SOFTWARE (fc1) R1 uptime is 3 weeks, 2 days, 4 hours, 11 minutes System returned to ROM by power-on System image file is "flash0:c2900-universalk9-mz.SPA.157-3.M8.bin" Cisco CISCO2911/K9 (revision 1.0) with 491520K/32768K bytes of memory. Processor board ID FTX1840AHK2 3 Gigabit Ethernet interfaces 255K bytes of non-volatile configuration memory. 250880K bytes of ATA System CompactFlash 0 (Read/Write) Configuration register is 0x2102
From it you learn: the IOS version (15.7(3)M8), how long since the last reload and why ("power-on" versus "reload" or a crash), the image file name in flash, the hardware model and serial, the interface count, the NVRAM and flash sizes, and the configuration register. 0x2102 is the normal value: boot IOS from flash and load the startup-config. In the lab simulator the text is shorter and the image name differs, but the same fields are there.
Worked example. You configure R1 for thirty minutes and run show startup-config. It says startup-config is not present. Your work exists only in RAM. You run copy run start, press Enter, see [OK], and now show startup-config begins with Using 1482 out of 262144 bytes followed by your configuration. A power cut now costs you nothing.
Common mistakes. Typing copy startup-config running-config when you meant to save (the direction is reversed and nothing is saved). Saving a broken experiment as the startup-config. Believing copy start run gives a clean rollback (it merges). Forgetting to save on the second device of a pair.
Exam traps. Running-config = RAM, startup-config = NVRAM, IOS image = flash, bootstrap/POST/ROMMON = ROM. Configuration changes apply immediately but are lost at reload unless saved. show version shows the configuration register; 0x2102 is the normal boot value. erase startup-config plus reload returns a router to defaults.
The Monday-morning mystery
On Friday an engineer added a new branch subnet and static route to a WAN router and tested it successfully. Over the weekend a power maintenance rebooted the building. On Monday the branch was unreachable. show version showed "System returned to ROM by power-on" and an uptime of 1 day; show running-config had no trace of Friday's work. Nothing had been saved. The change was re-applied from the ticket notes and saved with copy run start, and the team added "save and verify startup-config" to their change checklist.
Lesson: a change is not finished until it is saved. Uptime in show version is your first clue after an unexplained outage.
"What is the difference between the running-config and the startup-config?"
Strong answer: the running-config lives in RAM and is what the device uses right now; every configuration command changes it immediately. The startup-config lives in NVRAM and is loaded at boot. Changes are lost at reload unless you run copy running-config startup-config (or write memory). Mention that copy start run merges rather than replaces, and that you can compare the two to spot unsaved changes.
Key takeaways
- ROM: POST and bootstrap. Flash: IOS image. NVRAM: startup-config. RAM: running-config and tables.
- Configuration commands change the running-config instantly; nothing is saved automatically.
- Save with
copy running-config startup-configorwrite memory; copy is always source then destination. show versionreveals IOS version, uptime, reload reason, image file and configuration register (0x2102).- Undo with
no; factory-reset witherase startup-configandreload.
Basic device setup: hostname, banner, enable secret and line passwords
A new device out of the box is like a new flat with the front door wide open and no name on the bell. Before you move furniture in, you put your name on the door, fit locks on the front door and the balcony, and stick a "private property" sign outside. On a router or switch, that first-day routine is the hostname, the banner, the enable secret, and passwords on the console and VTY lines. Lab 3 walks you through all of it.
Name it: hostname
Router(config)# hostname R1 R1(config)#
The hostname appears in the prompt, in CDP/LLDP neighbour tables, in log messages and in SSH keys. A clear naming scheme (site, role, number: BLR-CORE-SW1) saves minutes in every outage because you always know which device you are on. Hostnames must start with a letter and contain no spaces.
Warn them: banner motd
R1(config)# banner motd # Authorised access only. Activity is logged. #
The message of the day banner appears before login on the console and on remote sessions. The first character after motd is the delimiter; the banner ends at the next copy of that character, so choose one that does not appear in the text (#, ^, $). In many countries a legal warning banner is what makes unauthorised access prosecutable, so never write "Welcome".
Lock the staff door: enable secret
R1(config)# enable secret Kings@123
This password is asked for when anyone types enable. There are two variants and you must know both:
| Command | How it is stored | Use it? |
|---|---|---|
enable password | Clear text (or weak type 7 with encryption service) | No, legacy only |
enable secret | Strong one-way hash: type 5 (MD5) on older IOS, type 9 (scrypt) or 8 on current IOS | Yes, always |
If both are configured, enable secret wins and the enable password is ignored.
Lock the front door and the balcony: console and VTY lines
A line is a way into the CLI. line con 0 is the console port. line vty 0 4 is five virtual lines for Telnet/SSH sessions (switches usually also have 5 to 15). Each needs a password and the word login, which tells IOS to actually ask for it.
R1(config)# line con 0 R1(config-line)# password Con@123 R1(config-line)# login R1(config-line)# exec-timeout 5 0 ! log out after 5 min 0 s idle R1(config-line)# logging synchronous ! log messages do not break your typing R1(config-line)# exit R1(config)# line vty 0 4 R1(config-line)# password Vty@123 R1(config-line)# login R1(config-line)# end
- password without login does nothing: nobody is asked. login without a password on the console lets you in freely; on VTY lines it refuses every session with "Password required, but none set".
- exec-timeout minutes seconds closes idle sessions (default 10 minutes;
0 0means never, which you should not use in production). - logging synchronous reprints your half-typed command after a log message interrupts it.
login localuses usernames created withusername admin secret ...instead of a shared line password; together with SSH this is the production standard, configured in the device-hardening module.
Hide the rest: service password-encryption
R1(config)# service password-encryption
Line passwords and enable password are stored in clear text by default. This command scrambles them to type 7 so someone looking over your shoulder at show running-config cannot read them. Type 7 is a reversible encoding, not real encryption; free tools decode it in a second. It protects against shoulder-surfing only. The strong protection is enable secret and username ... secret.
Line passwords guard the way in; the enable secret guards privileged EXEC.
Verification
R1# show running-config | section line|enable|banner enable secret 9 $9$ofzcgzrfk201oo$cgzrfk201ooavmmofzcgzrfk201ooavmm banner motd ^C Authorised access only. Activity is logged. ^C line con 0 exec-timeout 5 0 password 7 02250B552B575D72 logging synchronous login line vty 0 4 password 7 023010422B575D72 login
Then test it the way an attacker would, from PC1:
PC1> telnet 192.168.10.1
Trying 192.168.10.1...
Connected to 192.168.10.1.
Authorised access only. Activity is logged.
User Access Verification
Password:
R1> enable
Password:
R1# show users
Line User Host(s) Idle Location
0 con 0 idle 00:00:41
*866 vty 0 idle 00:00:00 192.168.10.10
Worked example. In lab 3 R1 already has its IP address. You add the enable secret, console and VTY passwords, encryption and the banner, then Telnet from PC1. show users marks your session with * on a vty line from 192.168.10.10. Finally copy running-config startup-config on both R1 and SW1 makes it permanent.
Common mistakes. Setting a line password but forgetting login. Using enable password instead of enable secret. Securing vty 0 4 on a switch but leaving vty 5 15 open. Setting exec-timeout 0 0 on production. Believing type 7 is secure.
Exam traps. Enable secret overrides enable password. service password-encryption produces reversible type 7 and does not affect the enable secret, which is already hashed. A VTY line with login but no password refuses Telnet. The banner delimiter is the first character after motd.
The switch anyone could manage
A security audit at a college found that 40 access switches accepted Telnet with the password "cisco" and had no enable secret on some models, so the auditor reached privileged EXEC in seconds from a student lab PC. The network team pushed a standard block to every switch: enable secret, local usernames, login local on all 16 VTY lines, exec-timeout, the legal banner and service password-encryption, then saved and verified each switch. SSH replaced Telnet the following month.
Lesson: the first five minutes of configuration are security configuration. Do them on every device, every time.
"What is the difference between enable password and enable secret, and what does service password-encryption do?"
Strong answer: enable password is stored in clear text (or type 7); enable secret is a one-way hash (type 5, 8 or 9) and takes precedence if both exist. service password-encryption converts clear-text passwords such as line passwords to type 7, which only hides them from casual viewing because it is reversible. Best practice is enable secret, local users with secret, login local and SSH.
Key takeaways
- First-day routine: hostname, banner motd, enable secret, console and VTY passwords with login, exec-timeout, save.
enable secretis hashed and overridesenable password.- A line password only works with
login;login localuses local usernames instead. service password-encryptiongives weak, reversible type 7; it only stops shoulder-surfing.- Verify with
show running-config | section lineand test with a real Telnet/SSH login.
Interfaces: names, descriptions, IP addresses and interface states
Interfaces are the doors of a device. A router's doors lead to different streets (different subnets), so each door needs its own house number: an IP address. A switch's doors all open onto the same corridor, so its ports usually need no address at all. Knowing how to name a door, label it, number it and open it is the core skill of lab 2.
How interfaces are named
An interface name is its type followed by its position:
| Name | Meaning | Short form |
|---|---|---|
FastEthernet0/1 | 100 Mbps port, module 0, port 1 | fa0/1 |
GigabitEthernet0/0 | 1 Gbps port, slot 0, port 0 (routers often count from 0) | g0/0, gi0/0 |
GigabitEthernet1/0/24 | Stack member 1, module 0, port 24 (Catalyst 9000) | gi1/0/24 |
TenGigabitEthernet1/1/1 | 10 Gbps uplink on network module 1 | te1/1/1 |
Serial0/0/0 | Serial WAN interface (older routers) | s0/0/0 |
Loopback0, Vlan1 | Virtual interfaces: always-up loopback, switch virtual interface | lo0, vl1 |
The name describes the port's maximum type, not the speed it negotiated. Use show ip interface brief to see the exact names on your device before configuring.
Configuring a router interface
R1(config)# interface GigabitEthernet0/0
R1(config-if)# description LAN-to-SW1
R1(config-if)# ip address 192.168.10.1 255.255.255.0
R1(config-if)# no shutdown
! console messages a few seconds later:
%LINK-3-UPDOWN: Interface GigabitEthernet0/0, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0, changed state to up
- description is a free-text label. It changes nothing in forwarding but saves hours in troubleshooting: always say what is on the other end.
- ip address takes the address and the dotted-decimal mask. IOS does not accept
/24here. - no shutdown enables the interface. Router interfaces are administratively down by default; switch ports are enabled by default.
IOS protects you from two classic errors: it refuses an address that overlaps a subnet already on another interface (% 192.168.10.0 overlaps with GigabitEthernet0/1), and it rejects the network or broadcast address of the subnet as an interface address.
Reading show ip interface brief
R1# show ip interface brief
Interface IP-Address OK? Method Status Protocol
GigabitEthernet0/0 192.168.10.1 YES manual up up
GigabitEthernet0/1 unassigned YES unset administratively down down
GigabitEthernet0/2 unassigned YES unset administratively down down
Status is Layer 1 (is there a working physical link?) and Protocol is Layer 2 (is the data link working?). Method shows how the address was set: manual, DHCP, NVRAM (loaded from startup-config at boot) or unset.
| Status / Protocol | Meaning | Typical fix |
|---|---|---|
| administratively down / down | Someone typed shutdown (or it is a router default) | no shutdown |
| down / down | No physical link: cable unplugged or broken, far end off or shut | Check cable, far-end port, transceiver |
| up / down | Physical link fine, Layer 2 failing | Encapsulation or keepalive mismatch (serial), err-disable, far end issues |
| up / up | Working | Now test Layer 3 with ping |
Climb the ladder one step at a time: admin, physical, data link, then IP.
More interface views
show interfaces GigabitEthernet0/0: full detail, first line repeats the status (GigabitEthernet0/0 is up, line protocol is up), then MAC address, description, IP, MTU, speed/duplex, input/output counters and errors.show interfaces description: one line per interface with status and your labels. Perfect for "which port goes where?".show interfaces status(switches): port, description, status (connected / notconnect / disabled / err-disabled), VLAN, duplex, speed and type.show running-config interface GigabitEthernet0/0: only that interface's configuration.
Worked example from lab 2. Before you start, R1's Gi0/0 shows administratively down down and SW1's Gi0/1 (the other end) shows down down because the router side is off. You configure the address and no shutdown on R1. Both ends go up up. show ip interface brief on R1 now shows 192.168.10.1 with method manual. After a reload it would say NVRAM, because the address came from the startup-config.
Common mistakes. Forgetting no shutdown on a router. Typing ip address 192.168.10.1/24 (IOS needs the dotted mask). Putting the address on the wrong interface because you did not re-enter the right one. Assuming up/up means the IP is correct: the status says nothing about the address or mask.
Exam traps. "administratively down" always means the shutdown command. down/down points to Layer 1. up/down points to Layer 2. Router interfaces default to shutdown; switch ports default to no shutdown. The interface name shows the hardware type, not the negotiated speed.
The new branch that would not come up
A branch router was racked and the WAN team reported "link down". The engineer checked show ip interface brief: the LAN interface was administratively down and the WAN interface down down. no shutdown fixed the LAN. For the WAN, show interfaces showed no input at all; the fibre patch lead at the provider's box was in the wrong port. After re-patching it went up up and the branch came online.
Lesson: the two columns of show ip interface brief tell you which layer to fix. Read them before touching anything.
"An interface shows up/down. What does that tell you and what would you check?"
Strong answer: Layer 1 is fine (there is a signal) but Layer 2 is not: on serial links an encapsulation or keepalive mismatch or missing clock; on Ethernet an err-disabled or negotiation problem on the far end. Compare with administratively down (someone typed shutdown) and down/down (cable or far end). Check show interfaces, the far-end configuration and logs.
Key takeaways
- Interface names are type plus position:
GigabitEthernet0/0,FastEthernet0/1,GigabitEthernet1/0/24. - Router interface setup:
description,ip address A.B.C.D mask,no shutdown. - Router interfaces are shut by default; switch ports are enabled by default.
- Status = Layer 1, Protocol = Layer 2: admin down, down/down, up/down, up/up each point to a different fix.
show interfaces descriptionandshow interfaces statusanswer "what is plugged in where?".
Switch management: the VLAN 1 SVI and ip default-gateway
A Layer 2 switch is like a postal sorting room: it reads the address on each envelope (the destination MAC) and pushes it to the right pigeonhole, without ever needing a postal address of its own. So why do we give a switch an IP address at all? Because the people who run the sorting room need to phone it. The IP address is not for forwarding user traffic; it is for managing the switch.
What the management IP is for
Without an IP address a switch forwards frames perfectly, but you can only manage it from the console. With an IP address you can:
- log in remotely with SSH (or Telnet in a lab) from your desk,
- send its logs to a syslog server and its alarms and counters to an SNMP monitoring system,
- synchronise its clock with NTP, back up its configuration and upgrade its IOS over the network,
- ping from the switch itself when troubleshooting.
Where the address goes: the SVI
Switch ports are Layer 2 ports, so you cannot put an IP address on FastEthernet0/1 of a Layer 2 switch. Instead, the switch has a virtual Layer 3 interface for a VLAN, called a switch virtual interface (SVI). By default every port is in VLAN 1, so on a new switch the SVI to use is interface Vlan1. You will learn VLANs properly in the VLAN module; for now, think of VLAN 1 as "the one LAN every port starts in".
The SVI is the switch's own "host" inside VLAN 1. The default gateway lets it reply beyond its subnet.
Configuration
Switch(config)# hostname SW1
SW1(config)# interface vlan 1
SW1(config-if)# ip address 192.168.10.2 255.255.255.0
SW1(config-if)# no shutdown ! the SVI can be shut by default
SW1(config-if)# exit
SW1(config)# ip default-gateway 192.168.10.1
SW1(config)# interface FastEthernet0/1
SW1(config-if)# description PC1
SW1(config-if)# interface GigabitEthernet0/1
SW1(config-if)# description Uplink-R1
SW1(config-if)# end
Why the switch needs ip default-gateway
A Layer 2 switch does not route. Its IP stack behaves like a PC: it can talk directly to hosts in its own subnet, and for everything else it must send traffic to a gateway. If your admin laptop is on 10.50.0.0/24 and the switch is on 192.168.10.0/24, the switch receives your SSH request fine, but its reply has nowhere to go without ip default-gateway. The session simply times out.
A Layer 3 switch with ip routing enabled ignores ip default-gateway; it uses its routing table, so you give it a default route (ip route 0.0.0.0 0.0.0.0 192.168.10.1) instead. You will meet that in the routing modules.
SVI states
An SVI comes up only when two things are true: it is not shut down, and at least one port in that VLAN is up (in a forwarding state). An SVI whose VLAN has no active port shows up down. In lab 2 Fa0/1 (PC1) and Gi0/1 (R1) are in VLAN 1 and up, so Vlan1 reaches up up after no shutdown.
SW1# show ip interface brief | include Vlan|up FastEthernet0/1 unassigned YES unset up up GigabitEthernet0/1 unassigned YES unset up up Vlan1 192.168.10.2 YES manual up up SW1# ping 192.168.10.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.10.1, timeout is 2 seconds: .!!!! Success rate is 80 percent (4/5), round-trip min/avg/max = 1/1/2 ms
The first dot is normal: the first echo was dropped while the switch resolved R1's MAC address with ARP. A second ping shows !!!!!.
Worked example. An admin on 10.50.0.20 tries to SSH to SW1 at 192.168.10.2 and times out. On the console, show running-config | include default-gateway returns nothing. After ip default-gateway 192.168.10.1 the session connects immediately. The request always reached the switch; only the reply was lost.
Common mistakes. Trying ip address on a physical port of a Layer 2 switch (it is not accepted). Forgetting no shutdown on the SVI. Setting a default gateway that is not in the SVI's subnet. Using ip default-gateway on a Layer 3 switch with routing enabled and wondering why it has no effect.
Exam traps. A Layer 2 switch needs an IP address only for management, placed on an SVI. ip default-gateway is used when IP routing is disabled; with ip routing use a default route. An SVI is up/up only when it is not shut and at least one port in its VLAN is up. Best practice is a dedicated management VLAN instead of VLAN 1.
The switch that could be pinged but never managed
After a floor move, the monitoring system showed an access switch as "up" (ping from the same subnet worked) but backups and SSH from the NOC failed every night. The switch's SVI had been re-addressed into the new floor subnet, but the old ip default-gateway pointing at the previous floor's router remained. Replies to the NOC went to a gateway that no longer existed on that subnet. Updating the default gateway fixed SSH, SNMP and backups at once.
Lesson: when a switch answers local pings but not remote management, check ip default-gateway first.
"Why does a Layer 2 switch need an IP address, and where do you configure it?"
Strong answer: it does not need one to forward frames; the IP is for management: SSH, SNMP, syslog, NTP, backups and ping. It goes on an SVI such as interface Vlan1 (ideally a dedicated management VLAN) with no shutdown, plus ip default-gateway so the switch can reply to hosts in other subnets. On a Layer 3 switch with routing enabled you use a default route instead.
Key takeaways
- A Layer 2 switch forwards frames without an IP; the IP address is only for managing it.
- The management address goes on an SVI (
interface Vlan1on a new switch) withno shutdown. ip default-gatewaylets the switch reply to admins and servers in other subnets.- An SVI is up/up only if it is not shut and a port in its VLAN is up.
- Layer 3 switches with
ip routinguse a default route, notip default-gateway.
Show commands, output filters and the do command
A doctor does not operate before looking at the X-ray. In networking, show commands are your X-rays: they change nothing and tell you everything. The skill is not only knowing which show to run, but cutting a 400-line output down to the three lines that matter. That is what output filters are for.
The show commands you will use every day
| Command | Answers the question |
|---|---|
show version | Which IOS, which hardware, how long up, why it last rebooted, config register? |
show running-config | What is configured right now? |
show startup-config | What will load at the next boot? |
show ip interface brief | Which interfaces are up, and with which IP addresses? |
show interfaces [name] | Detailed status, MAC, speed, duplex, counters and errors |
show interfaces description | What is each port labelled as? |
show interfaces status | (switch) connected / notconnect, VLAN, speed and duplex per port |
show ip route | (router) Which networks does it know and how does it reach them? |
show arp / show mac address-table | Which IP maps to which MAC / which MAC is on which switch port? |
show users, show history, show clock | Who is logged in, what did I type, what time does the device think it is? |
Output filters: the pipe
Add | (pipe) after any show command, followed by a filter keyword and a pattern. The pattern is a regular expression, but plain words work fine. Filters are case-sensitive on real IOS.
| Filter | Shows | Example |
|---|---|---|
| include X | Only lines containing X | show run | include hostname |
| exclude X | Every line except those containing X | show ip int brief | exclude unassigned |
| begin X | Everything from the first line containing X | show run | begin line con |
| section X | Each block whose top line contains X, with its indented lines | show run | section interface |
| count X | How many lines match | show ip int brief | count up |
The pipe turns a long output into the few lines you need.
R1# show running-config | section line
line con 0
exec-timeout 5 0
password 7 02250B552B575D72
logging synchronous
login
line vty 0 4
password 7 023010422B575D72
login
R1# show ip interface brief | exclude unassigned
Interface IP-Address OK? Method Status Protocol
GigabitEthernet0/0 192.168.10.1 YES manual up up
Two more tools help with long output. show running-config interface GigabitEthernet0/0 prints only that interface. terminal length 0 disables the --More-- pause for your session so you can copy everything at once.
Running EXEC commands from config mode: do
You are in the middle of configuring an interface and want to check the result. Without do you would need end, show, configure terminal, interface ... again. With do you stay where you are:
LAB-SW1(config)# do show running-config | include hostname hostname LAB-SW1 R1(config-if)# do show ip interface brief R1(config-if)# do ping 192.168.10.2 R1(config)# do copy running-config startup-config
do works for any privileged EXEC command, including ping and copy. Help (?) also works after do. Without do, typing show in config mode gives % Invalid input, because show is not a configuration command.
Worked example from lab 1. After hostname LAB-SW1 you are at LAB-SW1(config)#. You type do show running-config | include hostname and get exactly one line: hostname LAB-SW1. Then end and show history list every command you typed in this session, which is also how you prove to an auditor what you did.
A verification habit
Every change should be followed by a matching show: after ip address, show ip interface brief; after line passwords, show running-config | section line; after saving, show startup-config | include hostname. The pattern "configure, verify, save, verify" catches most mistakes within seconds.
Common mistakes. Using a lowercase pattern for uppercase text (| include vlan does not match Vlan1 on real IOS). Filtering with | include when you need the whole block (| section). Forgetting the space rules: show run | inc hostname works, show run |inc hostname also works, but a missing pattern gives % Incomplete command. Typing show in config mode without do.
Exam traps. include, exclude, begin and section are the filters most often tested. section keeps the indented child lines; include does not. do runs EXEC commands from any configuration mode. show commands never change the configuration.
Finding one password line in 3000
During an audit, a team had to prove that all 120 switches had passwords on every VTY line. Scrolling through show running-config on each switch would have taken days. They ran show running-config | section line vty on each device (later through an automation script) and checked for login local and transport input ssh. Four switches had a second line vty 5 15 block with no login method. Those were fixed the same afternoon.
Lesson: filters turn "read everything" into "check exactly this". They are also the first step to automation.
"How do you quickly check one part of a large running configuration?"
Strong answer: use output modifiers. show running-config | section line vty for a block, | include for single lines, | begin to jump to a point, | exclude to remove noise, show running-config interface X for one interface. From config mode use do show ... so you do not have to leave the mode. Mention that patterns are regular expressions and case-sensitive.
Key takeaways
showcommands change nothing; learn the core set: version, running/startup-config, ip interface brief, interfaces, ip route.- Pipe filters:
include,exclude,begin,section,count. sectionreturns whole configuration blocks, including indented lines.doruns any privileged EXEC command (show, ping, copy) from configuration mode.- Build the habit: configure, verify, save, verify.
IOS files, backups and password recovery
Every good household keeps copies of important documents in a safe, and knows where the spare key is hidden in case someone is locked out. A network device is the same. Its IOS image and configuration are files that should be backed up, and there is a documented way back in if the password is lost. This chapter gives you the concepts; the labs run on a simulator without a file server, so read the outputs carefully.
Files on the device: flash and NVRAM
IOS treats storage as file systems with names ending in a colon: flash: (or bootflash:, flash0:), nvram:, and network ones such as tftp:, ftp: and scp:. dir flash: (or show flash:) lists what is stored:
R1# dir flash:
Directory of flash0:/
1 -rw- 107430700 Jun 12 2026 09:14:22 +00:00 c2900-universalk9-mz.SPA.157-3.M8.bin
2 -rw- 2903 Sep 28 2026 17:02:10 +00:00 pre-change-backup.cfg
256487424 bytes total (148893696 bytes free)
The image name tells you the platform (c2900), the feature set (universalk9 = all features, licence-controlled), the format (mz = compressed, runs from RAM), and the version (157-3.M8 = 15.7(3)M8). On IOS XE switches you will see a .bin bundle or packages.conf in install mode.
Backing up the configuration
The simplest backup is a copy on the device itself: copy running-config flash:pre-change-backup.cfg. A real backup lives off the device, on a TFTP, FTP or SCP server:
R1# copy running-config tftp: Address or name of remote host []? 192.168.10.50 Destination filename [r1-confg]? !! 1482 bytes copied in 0.084 secs (17643 bytes/sec)
TFTP (UDP 69) has no authentication and no encryption, so it belongs only on a trusted management network; SCP (over SSH) is the secure choice. Restoring works in the other direction: copy tftp: running-config. Remember from chapter 5 that copying into the running-config merges: commands in the file are added or changed, but lines that are missing from the file are not removed. To restore a clean configuration, copy the file to the startup-config and reload.
Keep at least one copy off the device. Know which direction merges and which replaces.
Upgrading IOS, in outline
- Check
show versionanddir flash:for the current image and free space. - Copy the new image:
copy tftp: flash:(or scp), then verify it withverify /md5 flash:filename. - Point the boot at it:
boot system flash:new-image.bin, save, andreloadin a maintenance window. - Confirm the new version with
show version. Keep the old image until you are sure.
The configuration register
The 16-bit configuration register, read by the bootstrap, controls how a router boots. Three values matter for the CCNA:
| Value | Effect |
|---|---|
| 0x2102 | Normal: boot IOS from flash, load startup-config, console at 9600 |
| 0x2142 | Boot IOS but ignore the startup-config in NVRAM (used for password recovery) |
| 0x2100 | Stop in ROMMON at boot |
You change it with config-register 0x2102 in global configuration (takes effect at next reload) or confreg in ROMMON. show version shows it on the last line, and warns when a change is pending: Configuration register is 0x2142 (will be 0x2102 at next reload).
Password recovery on a router, conceptually
If nobody knows the enable secret, you need physical console access; that requirement is the security control.
- Connect to the console and power-cycle the router. Send a Break during the first 60 seconds to enter ROMMON (
rommon 1 >). confreg 0x2142, thenreset. The router boots and ignores NVRAM, so there is no password. Answer no to the setup dialog.enable, thencopy startup-config running-config. Here the merge is exactly what you want: the old configuration loads into RAM, and you are already in privileged EXEC.configure terminal,enable secret NewStrongPass, andno shutdownon the interfaces that should be up (the merge leaves them shut).config-register 0x2102,copy running-config startup-config, and reload to check a normal boot.
Catalyst switches use a different path (hold the MODE button while powering on, then rename the configuration file), but the idea is the same: console access plus skipping the saved configuration. no service password-recovery disables this path for high-security sites; recovery is then only possible by erasing the configuration.
Worked example. After a recovery a colleague forgets step 5. Weeks later a routine reload brings the router up with an empty configuration and the setup dialog; the branch is down. show version shows Configuration register is 0x2142. Setting 0x2102, and restoring the configuration from the TFTP backup into the startup-config, fixes it.
Common mistakes. Forgetting to set the register back to 0x2102. Forgetting no shutdown after the merge. Using copy tftp: running-config as a clean restore (it merges). Keeping backups only on the device's own flash. Leaving TFTP open on an untrusted network.
Exam traps. 0x2102 normal boot; 0x2142 ignore startup-config. Password recovery needs console access and a Break in ROMMON. Copying into the running-config merges. The IOS image lives in flash; configuration backups can go to flash, TFTP, FTP or SCP. show version displays the configuration register.
The router that forgot its configuration every time
A training lab router came up with no configuration after every reload, even though copy run start reported [OK]. The engineer checked show startup-config: the configuration was there. Then show version: Configuration register is 0x2142, left over from a password-recovery exercise. The router was ignoring its perfectly good startup-config. config-register 0x2102 and one reload fixed it.
Lesson: if a saved configuration never loads, check the configuration register before anything else.
"How would you recover a lost enable secret on a Cisco router?"
Strong answer: with console access, break into ROMMON during boot, set confreg 0x2142 and reset so the router ignores the startup-config. Enter privileged mode, copy startup-config running-config, set a new enable secret, no shutdown the interfaces, set config-register 0x2102, save and reload. Mention that physical access is the security boundary and that no service password-recovery can disable the procedure.
Key takeaways
dir flash:lists the IOS image and files; the image name encodes platform, features and version.- Back up configurations off the device (TFTP in a lab, SCP in production);
copyis source then destination. - Copying into the running-config merges; copying into the startup-config and reloading replaces.
- Configuration register: 0x2102 normal, 0x2142 skip NVRAM, 0x2100 ROMMON.
- Password recovery: console, Break, 0x2142, copy start run, new secret, no shut, back to 0x2102, save.
Troubleshooting workflow: "I cannot ping my first router"
When a car will not start, a good mechanic does not replace the engine first. He checks, in order: is there fuel, is the battery charged, does the starter turn, is there a spark. Each check is quick and rules out a whole class of problems. Network troubleshooting works the same way. For the classic first-day ticket, "PC1 cannot ping R1", a fixed order of checks finds the fault in minutes, every time.
The workflow
Bottom-up and nearest-first: each step is fast and rules out a whole class of faults.
Step 1: the right mode on the right device
Read the prompt. % Invalid input on show running-config means you are at >, not #. Check the hostname in the prompt matches the device in the ticket; in a rack of identical switches it is easy to be on the wrong console.
Step 2: interface state on both ends
R1# show ip interface brief
Interface IP-Address OK? Method Status Protocol
GigabitEthernet0/0 192.168.10.1 YES manual administratively down down
Administratively down: somebody forgot no shutdown (the router default). down/down: look at the cable and the switch port at the other end (show interfaces status on SW1). Fix the lowest broken layer first; nothing above it can work.
Step 3: addressing and masks
Both ends must be in the same subnet with the same mask. show running-config interface GigabitEthernet0/0 on R1 and show ip interface brief on SW1 give you the numbers. Typical faults: 192.168.10.1 255.255.255.128 on R1 while PC1 is .200 (outside the /25), a swapped digit (192.168.1.10), or a duplicate address, which IOS reports in the log:
%IP-4-DUPADDR: Duplicate address 192.168.10.1 on GigabitEthernet0/0, sourced by 5254.00ab.cd01
Step 4: the host
On the PC check address, mask and default gateway. A PC with the right address but gateway 192.168.10.254 can still ping R1 (same subnet) but nothing beyond it, a very common half-working symptom. A PC with the wrong mask may think R1 is on another network and send the ping to a gateway that does not exist.
Step 5: ping hop by hop, nearest first
PC1> ping 192.168.10.2
192.168.10.2 icmp_seq=1 timeout
192.168.10.2 icmp_seq=2 timeout
R1# ping 192.168.10.2
Sending 5, 100-byte ICMP Echos to 192.168.10.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
Ping the nearest thing first: PC1 to its gateway R1, then to SW1's management address. If the gateway answers but SW1 does not, the fault is on SW1 (next step). Check show arp on R1: an entry with Incomplete means the ARP request got no reply, so the target is down, shut or in another VLAN. The first . in .!!!! is normal ARP delay, not a fault.
Step 6: switch management and remote login
- SW1's
Vlan1administratively down: addno shutdownunderinterface vlan 1. - SW1 answers pings from its own subnet but not from the NOC:
ip default-gatewayis missing or wrong. - Telnet says
Password required, but none set: the VTY lines haveloginbut no password. - Telnet works but
enablesays% No password set: remote users cannot reach privileged EXEC until an enable secret exists. - Telnet is refused outright: check
transport inputon the VTY lines, and that SSH-only lines are not being tested with Telnet.
PC1> telnet 192.168.10.1
Trying 192.168.10.1...
Connected to 192.168.10.1.
Password required, but none set
[Connection to 192.168.10.1 closed by foreign host]
Step 7: save, and write it down
If the ticket says "it worked yesterday", check show version for uptime and reload reason, then compare the running and startup configurations: a reload with unsaved changes looks exactly like a mysterious outage. After fixing, copy running-config startup-config and note the root cause in the ticket.
Worked example. Ticket: "PC1 cannot ping R1 or SW1." show ip interface brief on R1: Gi0/0 administratively down. no shutdown: PC1 now pings R1. SW1 still silent. On SW1, Vlan1 is administratively down. no shutdown: PC1 pings SW1. From R1's other subnet, SW1 still does not answer: ip default-gateway 192.168.10.1 fixes that. Three faults, three layers, fifteen minutes, then save on both devices.
Common mistakes. Jumping straight to the configuration before checking interface states. Changing several things at once, so you never learn which one fixed it. Testing from a far subnet before testing locally. Forgetting to save after the fix, so the problem returns at the next reload.
Exam traps. A host with a wrong default gateway can still ping hosts in its own subnet. Administratively down always means shutdown. Password required, but none set means VTY login with no password. % No password set on enable over VTY means no enable secret. Unsaved changes are lost at reload.
The printer that "broke the network"
A small office reported that nobody could reach the router after a new network printer was installed. show ip interface brief on the router was up/up with the right address, but the log showed %IP-4-DUPADDR: Duplicate address 192.168.10.1. The printer had been given the gateway's address as its own static IP. Half the PCs had the printer's MAC in their ARP cache for 192.168.10.1. Re-addressing the printer and clearing ARP caches restored everything.
Lesson: when the interface is up/up and the configuration is right, look at the logs and ARP. Addressing problems are often outside the router.
"A user says they cannot ping the default gateway. How do you troubleshoot?"
Strong answer: work bottom-up and nearest-first. Check the router interface with show ip interface brief (admin down, down/down, up/down), then the switch port. Verify IP and mask on both sides are in the same subnet and there is no duplicate IP (logs, ARP). Check the PC's IP, mask and gateway. Ping step by step and look at the ARP table. Change one thing at a time, verify after each, and save when fixed.
Key takeaways
- Order: mode and device, interface state, addressing, host settings, hop-by-hop ping, management, save.
- Always check both ends of a link with
show ip interface brief. - Same subnet and same mask on both ends; watch for duplicate IPs in the log.
- Switch management failures are usually a shut SVI or a missing
ip default-gateway. - Change one thing at a time, verify, then save and document the root cause.
Summary and exam checklist
You started this module in front of a switch that said Switch> and nothing else. You can now connect to it, climb through its modes, ask it for help, name it, lock it, address it, verify it and save it. This chapter pulls everything together into a checklist, a glossary, the most-tested facts and a one-page command sheet you can keep next to the console.
The whole module in one line: connect, enter, identify, secure, address, save.
Can-do checklist
- I can connect to a console with the right cable and 9600 8N1, no flow control, and explain out-of-band versus in-band access.
- I can describe the boot sequence (POST, bootstrap, IOS from flash, startup-config from NVRAM, setup dialog).
- I can move between user EXEC, privileged EXEC, global config, interface and line modes, and know what
exit,endand Ctrl-Z do. - I can use
?, Tab, abbreviations and history, and interpret Invalid, Incomplete and Ambiguous errors. - I can configure hostname, banner motd, enable secret, console and VTY passwords with login, exec-timeout, logging synchronous and service password-encryption.
- I can address a router interface and a switch SVI, set
ip default-gateway, and read every state inshow ip interface brief. - I can filter output with include, exclude, begin and section, and run EXEC commands in config mode with
do. - I can save and verify the configuration, explain running versus startup, back it up, and describe password recovery with the configuration register.
- I can troubleshoot "cannot ping my router" bottom-up and nearest-first.
Mini glossary
- IOS / IOS XE
- Cisco's operating system for routers and switches; IOS XE is the current Linux-based version with the same CLI.
- Console port
- Out-of-band management port; needs no IP address.
- VTY line
- Virtual terminal line used by Telnet and SSH sessions.
- User / privileged EXEC
- The
>and#levels: look only, versus see everything and manage files. - Running-config / startup-config
- Active configuration in RAM / saved configuration in NVRAM.
- SVI
- Switch virtual interface, a Layer 3 interface for a VLAN, used for switch management.
- Configuration register
- Boot setting read by the bootstrap; 0x2102 normal, 0x2142 ignore NVRAM.
- ROMMON
- Minimal ROM monitor used for recovery when IOS cannot or should not load.
- Type 7 / type 9
- Reversible password encoding / strong scrypt hash for secrets.
Most-tested facts
| Topic | Fact |
|---|---|
| Console | 9600 baud, 8 data bits, no parity, 1 stop bit, no flow control |
| Memory | ROM: bootstrap/POST; flash: IOS; NVRAM: startup-config; RAM: running-config |
| Modes | > user, # privileged, (config)# global; end/Ctrl-Z back to # |
| Passwords | enable secret overrides enable password; type 7 is reversible; line passwords need login |
| Interfaces | Router interfaces default shutdown; admin down = shutdown; down/down = Layer 1; up/down = Layer 2 |
| Switch IP | On an SVI; needs ip default-gateway to reach other subnets |
| Saving | copy running-config startup-config = write memory; copying into running-config merges |
| Boot | Setup dialog only when there is no startup-config; 0x2142 skips it for password recovery |
Command cheat-sheet
! --- modes and help enable | disable | configure terminal | exit | end | ? | show history ! --- identity and security (global config) hostname R1 no ip domain-lookup banner motd # Authorised access only # enable secret Kings@123 service password-encryption line con 0 password Con@123 login exec-timeout 5 0 logging synchronous line vty 0 4 password Vty@123 login ! --- router interface interface GigabitEthernet0/0 description LAN-to-SW1 ip address 192.168.10.1 255.255.255.0 no shutdown ! --- switch management interface vlan 1 ip address 192.168.10.2 255.255.255.0 no shutdown ip default-gateway 192.168.10.1 ! --- verify and save (privileged EXEC, or with do in config mode) show version | show running-config | show startup-config show ip interface brief | show interfaces description | show users show running-config | section line copy running-config startup-config
Last reminders. Read the prompt before typing. Add login after every line password. no shutdown every router interface you use. Verify after every change. Save on every device you touched.
Exam traps recap. Wrong-mode questions (config commands at #), enable secret versus password precedence, type 7 being weak, admin down versus down/down, ip default-gateway on a Layer 2 switch, the merge behaviour of copy ... running-config, and the 0x2102 / 0x2142 register values.
The new-hire's first real change
A fresher at a managed-services company was given a real ticket in week two: bring up a new store's switch and router. She used the checklist from this module: console at 9600 8N1, no to the setup dialog, hostname from the naming standard, enable secret, console and VTY passwords with login, banner, interface addresses with descriptions, the SVI and default gateway, pings from both devices, a Telnet test from a store PC, and copy run start on both. Her senior reviewed show running-config and found nothing to change. The store opened on time.
Lesson: a short, repeatable routine done carefully beats clever tricks. The first configuration is the foundation for every module that follows.
"You are handed a factory-new router and switch. Talk me through your first 15 minutes."
Strong answer: console in at 9600 8N1 and decline the setup dialog; set hostname and no ip domain-lookup; enable secret; console and VTY passwords with login (or local users and SSH), exec-timeout, logging synchronous, banner and service password-encryption; address the router interface with a description and no shutdown; give the switch a management SVI and default gateway; verify with show ip interface brief and pings; save with copy run start and confirm with show startup-config.
Key takeaways
- Connect, enter, identify, secure, address, save, and verify after every step.
- Know the four memories, the mode prompts and the boot sequence cold.
- Secrets are hashed; type 7 is not security; line passwords need login.
show ip interface briefand ping, nearest-first, solve most first-day problems.- Next: the network models module, where you will follow data through every layer of the devices you just configured.