ITCertFoundryTechnical training system
COMMAND REFERENCE

Cisco IOS Command List

The configure, verify, and troubleshoot commands used throughout CCNA labs.

Device access and identity

TaskCommandEnter configurationconfigure terminalSet hostnamehostname R1Protect privileged modeenable secret <password>Save configurationcopy running-config startup-configInspect configurationshow running-config

Interfaces

TaskCommandSelect interfaceinterface gigabitEthernet 0/1Add IPv4ip address 192.0.2.1 255.255.255.0Add IPv6ipv6 address 2001:db8:1::1/64Enable interfaceno shutdownSummaryshow ip interface brief

Operational verification

show version
show cdp neighbors detail
show lldp neighbors detail
show mac address-table
show arp
show ip route
ping <destination>
traceroute <destination>

Why these commands matter

CommandWhat it tells or changesWhy you use itconfigure terminalMoves from privileged EXEC into global configuration mode.Configuration commands are rejected until you enter the correct mode.enable secretStores a hashed password for privileged EXEC access.It protects commands that can expose or change the entire device.copy running-config startup-configCopies the active configuration into nonvolatile storage.Without saving, a reload discards your work.show ip interface briefSummarizes interface addresses and line/protocol state.It quickly separates addressing, shutdown, and lower-layer problems.show running-configDisplays the configuration currently controlling the device.Use it to prove what is active rather than what you intended to type.

Read interface state correctly

Status up / protocol up means the physical and data-link layers are operational.

Administratively down means the interface is shut in configuration.

Down / down usually points toward power, cabling, transceiver, or the far-end interface.

Up / down means the physical signal exists but the Layer 2 protocol is not operating correctly.

Exam habit

Configure one logical block at a time, verify the intended state, then test forwarding. A successful ping proves reachability—not that every underlying setting is correct.

Real scenarios you'll actually face

"I just reloaded the switch and lost my config." You configured everything correctly, tested it, it worked — then someone power-cycled the closet, or a scheduled reload fired, and it's gone. `copy running-config startup-config` writes the running configuration to NVRAM; skip it and the running config is only ever one reload away from disappearing. On the job, this is the single most common self-inflicted outage, and the fix is prevention, not recovery: save immediately after every change you intend to keep, before you move on to testing the next thing.

"The device stopped responding to SSH after a config change." Most often this is `transport input ssh` applied to the VTY lines before RSA keys actually exist (`crypto key generate rsa`), or an ACL applied to the VTY lines that doesn't explicitly permit the address you're connecting from. Console access (which doesn't depend on IP reachability at all) is how you get back in to check `show running-config` on the line vty section and fix the ordering — which is exactly why you never make a remote-access change without a console session already open as a fallback.

"Interface shows up/down and won't pass traffic." `show ip interface brief` reporting up/down (not down/down, not administratively down) means the physical layer is fine but Layer 2 isn't negotiating — check `show interfaces` for duplex/speed mismatches, an encapsulation mismatch on a serial/WAN link, or (on a switch) the port being err-disabled by a security feature. Down/down instead points you toward cabling, a shut interface on this end or the far end, or a dead transceiver — different symptom, different half of the OSI model to go check first.

OFFLINE OPTION

Want a printable copy?

This complete guide is also available as a professionally formatted PDF.

Download PDF ↓