LUNAROPS · OPERATIONAL UPLINK 100% UPTIME 1,247d POSTS 893 JEFF.MOON@LUNAROPS.DEV UTC --:--:--

Cisco IOS Command Walkthroughs

ciscoiosnetworkingcliccnareference
Contents

Every Cisco IOS device speaks the same language, whether it is a decade-old 2811 still running branch voice or a Catalyst 9300 stack freshly racked in a new data center. That shared language is both IOS’s greatest strength and the reason so many engineers stop at the surface — they learn enough commands to get the job done, never quite understanding what the output is actually telling them. This guide is a desk reference for the engineer who wants to move past cargo-cult configuration and actually read the room.

What follows is organized by task, not by keyword. The annotated output blocks are as important as the commands themselves. If you understand what each field in show ip ospf neighbor means, you can diagnose a stuck adjacency in seconds instead of thirty minutes of debug output. That is the difference between knowing how to type a command and knowing what to do with the answer.

All examples assume IOS 15.x or later unless otherwise noted. Most concepts carry directly into IOS-XE.


Device Initialization and Global Configuration

The first minutes on a new device set the tone for everything that follows. A sloppily initialized router will cause pain for years.

Hostname, Domain Name, and Disabling DNS Lookup

Router> enable
Router# configure terminal
Router(config)# hostname core-rtr-01
core-rtr-01(config)# ip domain-name lunarops.internal
core-rtr-01(config)# no ip domain-lookup

The no ip domain-lookup line deserves special attention. By default, IOS treats an unrecognized command as a hostname and attempts a DNS lookup — specifically, a broadcast to 255.255.255.255 on UDP port 53 with a 30-second timeout. If you mistype enabble or accidentally hit Enter on an incomplete command, the CLI freezes for half a minute while the router waits for a DNS response that will never come. You sit there pressing Ctrl-C wondering what happened. Disabling this lookup costs nothing and saves repeated frustration. The domain name itself is required later for RSA key generation — IOS uses hostname.domain-name as the key label.

Enable Secret vs. Enable Password

core-rtr-01(config)# enable secret MyStr0ngP@ssword

Never use enable password. The enable password command stores the password in the configuration as cleartext, or with a weak reversible encoding if service password-encryption is active. The enable secret uses MD5 by default (type 5), and on IOS 15.3(3)M+ you can use type 8 (PBKDF2-SHA-256) or type 9 (scrypt):

core-rtr-01(config)# enable algorithm-type sha256 secret MyStr0ngP@ssword

If both enable password and enable secret are configured, IOS ignores the password and uses the secret. There is no reason to configure both.

Service Password-Encryption

core-rtr-01(config)# service password-encryption

This command applies Cisco’s type 7 encoding to passwords stored in cleartext — VTY passwords, console passwords, usernames created with password instead of secret. Understand what it does and does not do: type 7 is a reversible Vigenere cipher. The encoded string can be decoded in seconds with freely available tools online. It is security theater against casual shoulder-surfing of a config printout, not cryptographic protection. Always use secret variants when available. Service password-encryption is still worth enabling as a baseline, just do not rely on it for anything sensitive.

Local User Database

core-rtr-01(config)# username admin privilege 15 algorithm-type sha256 secret AdminP@ss123

Privilege level 15 grants immediate enable-level access without requiring the user to type enable. For shared devices where different teams need different access, create users at privilege 1 and configure privilege levels for specific commands. The algorithm-type sha256 stores the password as type 8; on older IOS, secret alone uses type 5 MD5.

SSH Configuration

SSH requires a hostname, domain name, and RSA keys. Ensure both are set before generating keys.

core-rtr-01(config)# crypto key generate rsa modulus 2048
The name for the keys will be: core-rtr-01.lunarops.internal
% The key modulus size is 2048 bits
% Generating 2048 bit RSA keys, keys will be non-exportable...
[OK] (elapsed time was 3 seconds)

core-rtr-01(config)# ip ssh version 2
core-rtr-01(config)# ip ssh authentication-retries 3
core-rtr-01(config)# ip ssh time-out 60

2048-bit keys are the minimum for anything touching production. The ip ssh version 2 line is mandatory — SSHv1 has known weaknesses and there is no good reason to support it in 2026. If you want SSHv1 disabled even more explicitly, ip ssh version 2 alone is sufficient.

Console and VTY Line Configuration

core-rtr-01(config)# line console 0
core-rtr-01(config-line)# exec-timeout 10 0
core-rtr-01(config-line)# logging synchronous
core-rtr-01(config-line)# login local
core-rtr-01(config-line)# exit

core-rtr-01(config)# line vty 0 4
core-rtr-01(config-line)# exec-timeout 10 0
core-rtr-01(config-line)# transport input ssh
core-rtr-01(config-line)# login local
core-rtr-01(config-line)# exit

exec-timeout 10 0 means 10 minutes, 0 seconds of inactivity before the session closes. The two parameters are minutes and seconds. exec-timeout 0 0 disables the timeout entirely — reasonable for console in a locked data center, dangerous for VTY lines accessible from the network.

logging synchronous on the console line is quality-of-life critical. Without it, IOS log messages interrupt your typing mid-command. You type interface Gi and a CDP neighbor notification inserts itself into the middle: interface Gi%CDP-5-NBDG0/0. With logging synchronous enabled, IOS buffers the log message and reprints your partial command on a clean line after displaying the message. It does not suppress messages, it just stops them from mangling your input.

transport input ssh on VTY lines ensures Telnet is disabled. Telnet passes credentials in cleartext and should not exist on any managed network device.

core-rtr-01(config)# banner motd ^
*****************************************************************************
AUTHORIZED ACCESS ONLY. This system is the property of LunarOps.
Unauthorized access is prohibited and will be prosecuted.
All activity on this system is subject to monitoring.
*****************************************************************************
^

The ^ is the delimiter — any character not in the banner text works. Banners serve a legal function in many jurisdictions: courts have found that without an explicit warning, unauthorized users can claim they did not know access was restricted. Keep the banner factual and avoid welcoming language. “Welcome to core-rtr-01” in a banner has been used by defense attorneys to argue implied consent.

Saving Configuration

core-rtr-01# copy running-config startup-config
Destination filename [startup-config]?
Building configuration...
[OK]

! Equivalent shorthand:
core-rtr-01# write memory
Building configuration...
[OK]

Both commands do the same thing: write the running configuration from DRAM to NVRAM (or flash, on modern hardware). Neither is deprecated. write memory is faster to type; copy running-config startup-config makes the operation more explicit in documentation and scripts. write erase clears the startup configuration — useful when reimaging a device, catastrophic when typed accidentally.

Show Version — Annotated

core-rtr-01# show version
Cisco IOS Software, Version 15.9(3)M4, RELEASE SOFTWARE (fc2)   ! IOS version string
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2022 by Cisco Systems, Inc.

ROM: System Bootstrap, Version 15.9(3r)M4
BOOTLDR: System Bootstrap, Version 15.9(3r)M4

core-rtr-01 uptime is 47 weeks, 2 days, 14 hours, 3 minutes       ! Time since last reload
System returned to ROM by power-on                                  ! Reason for last reload
System image file is "flash:c2900-universalk9-mz.SPA.159-3.M4.bin" ! Image filename in flash

Cisco CISCO2911/K9 (revision 1.0) with 524288K/65536K bytes of memory.  ! RAM: main/I-O
Processor board ID FTX1234ABC                                        ! Serial number
3 Gigabit Ethernet interfaces
1 Serial(sync/async) interface
DRAM configuration is 72 bits wide with parity enabled.
255K bytes of non-volatile configuration memory.                     ! NVRAM size
250880K bytes of ATA System CompactFlash 0 (Read/Write)             ! Flash size

License Info:
License UDI:
Device#   PID                   SN
*0        CISCO2911/K9          FTX1234ABC

Technology Package License Information:
--------------------------------------------------------------
Technology    Technology-package           Technology-package
              Current       Type          Next reboot
--------------------------------------------------------------
ipbase        ipbasek9      Permanent     ipbasek9
security      None          None          None
uc            None          None          None
data          None          None          None

Configuration register is 0x2102                                    ! Config register

The configuration register at the bottom is frequently overlooked. 0x2102 is the normal boot value: load from NVRAM startup config, boot normally. 0x2142 tells the router to ignore NVRAM on boot — this is the password recovery setting. If you see 0x2142 on a device in production that nobody is doing password recovery on, something is wrong. The reload reason field is also worth checking: “power-on” is expected; “reload command” means someone deliberately reloaded; “address error at PC” or “watchdog timeout” indicates a software crash.


Interface Configuration

Physical Interface

core-rtr-01(config)# interface GigabitEthernet0/0
core-rtr-01(config-if)# description UPLINK-TO-ISP-PRIMARY
core-rtr-01(config-if)# ip address 203.0.113.2 255.255.255.252
core-rtr-01(config-if)# no shutdown
core-rtr-01(config-if)# exit

IOS physical interfaces come up administratively shut down by default on routers (switches behave differently — access ports default to enabled). The no shutdown command is required to bring the interface operationally up. Forgetting it is the single most common reason a newly configured interface does not pass traffic.

Serial Interface

core-rtr-01(config)# interface Serial0/0/0
core-rtr-01(config-if)# description T1-TO-REMOTE-SITE
core-rtr-01(config-if)# encapsulation ppp
core-rtr-01(config-if)# clock rate 1536000     ! DCE side ONLY — defines the clocking signal
core-rtr-01(config-if)# bandwidth 1536         ! Affects routing metrics, NOT actual throughput
core-rtr-01(config-if)# ip address 10.1.1.1 255.255.255.252
core-rtr-01(config-if)# no shutdown

clock rate is only applicable on the DCE (Data Communications Equipment) end of a serial connection — typically the router connected to the WAN service provider’s equipment, or the DCE end of a back-to-back serial lab cable. If you type clock rate on a DTE interface, IOS accepts it silently but ignores it. The show controllers Serial0/0/0 command tells you which end you are on: look for “DCE” or “DTE” in the output.

bandwidth is purely informational from the interface hardware perspective. It does not shape traffic, limit throughput, or communicate anything to the physical layer. What it does is feed the routing protocol metric calculation. OSPF uses the bandwidth value to compute interface cost (cost = reference bandwidth / interface bandwidth). EIGRP uses it in its composite metric. If your bandwidth statement does not reflect actual circuit capacity, your routing metrics will be wrong and traffic engineering decisions will be incorrect.

Loopback Interfaces

core-rtr-01(config)# interface Loopback0
core-rtr-01(config-if)# description ROUTER-ID-AND-MGT
core-rtr-01(config-if)# ip address 10.255.0.1 255.255.255.255
core-rtr-01(config-if)# no shutdown

Loopbacks are virtual interfaces that are always up as long as the router process is running. They never go down due to a cable fault or physical failure, which makes them ideal for three things: router-ID anchoring (OSPF and BGP prefer a loopback as router ID because it is stable), management plane reachability (SSH to the loopback survives individual physical interface failures as long as routing converges), and testing (you can ping a loopback from anywhere in the network to verify end-to-end reachability without needing a host behind the router).

Show Interfaces — Annotated

core-rtr-01# show interfaces GigabitEthernet0/0
GigabitEthernet0/0 is up, line protocol is up          ! (1) admin status / line protocol
  Hardware is CN Gigabit Ethernet, address is aabb.cc00.0100 (bia aabb.cc00.0100)
  Description: UPLINK-TO-ISP-PRIMARY
  Internet address is 203.0.113.2/30
  MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,   ! (2) MTU, bandwidth, delay
     reliability 255/255, txload 1/255, rxload 1/255   ! (3) reliability, load
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex, 1000Mb/s, media type is RJ45            ! (4) duplex and speed negotiation
  output flow-control is unsupported, input flow-control is unsupported
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:00, output 00:00:00, output hang never ! (5) last packet time
  Last clearing of "show interface" counters never
  Input queue: 0/75/0/0 (size/max/drops/flushes)       ! (6) input queue
  Total output drops: 0                                  ! (7) output drops
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 48000 bits/sec, 62 packets/sec    ! (8) 5-min average rates
  5 minute output rate 92000 bits/sec, 71 packets/sec
     1842719 packets input, 892341042 bytes, 0 no buffer ! (9) counters
     Received 4812 broadcasts (0 IP multicasts)
     0 runts, 0 giants, 0 throttles                     ! (10) layer 1/2 errors
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 0 multicast, 0 pause input
     1739284 packets output, 1203847291 bytes, 0 underruns
     0 output errors, 0 collisions, 4 interface resets  ! (11) output errors
     0 unknown protocol drops
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier, 0 pause output
     0 output buffer failures, 0 output buffers swapped out

Field-by-field explanation:

(1) Two separate status indicators. The first reflects administrative state: “up” means no shutdown has been applied. “administratively down” means shutdown is in effect. The second is line protocol: “up” means keepalives are being received and the layer-2 framing is healthy. The combination “up/down” (admin up, protocol down) typically means a physical problem — cable, transceiver, or the remote end is down. “up/up” is what you want.

(2) MTU is the maximum frame size the interface will accept. Bandwidth is what IOS uses for metric calculations — not necessarily what the wire actually runs at.

(3) Reliability is expressed as a fraction of 255. 255/255 means no errors detected; 200/255 means roughly 22% of keepalives are being lost. txload and rxload express utilization as a fraction of 255 based on the bandwidth value.

(4) Duplex mismatch is one of the most common causes of poor performance that does not look like a failure. One side at half-duplex and the other at full creates late collisions and retransmissions that appear as degraded throughput without any obvious errors at layer 3.

(5) “Last input” shows when the last packet was received. If this is incrementing normally, the interface is receiving traffic. A value of “never” on an interface that should be active is immediately suspicious.

(6) The input queue tuple is size/max/drops/flushes. Non-zero drops here indicate the input process cannot consume packets fast enough — a CPU or software issue.

(7) Output drops indicate the output queue is being overwhelmed — usually a speed mismatch between an incoming high-speed interface and a slower outgoing one, or a QoS policy issue.

(10) These are the critical error counters. Runts are frames smaller than 64 bytes (often caused by collisions on half-duplex links). Giants are frames larger than the configured MTU. CRC errors indicate bit-level corruption — bad cable, failing transceiver, or electrical interference. Input errors increment whenever any of the sub-counters increment. A consistent rate of CRC errors that continues to grow is a hardware problem until proven otherwise.

(11) Interface resets can indicate keepalive failures, software crashes, or deliberate resets. Four resets on an uptime of weeks is not alarming; 400 over 24 hours is.

Show IP Interface Brief — Annotated

core-rtr-01# show ip interface brief
Interface              IP-Address      OK? Method Status                Protocol
GigabitEthernet0/0     203.0.113.2     YES manual up                    up
GigabitEthernet0/1     10.10.1.1       YES manual up                    up
GigabitEthernet0/2     unassigned      YES unset  administratively down down
Serial0/0/0            10.1.1.1        YES manual up                    up
Loopback0              10.255.0.1      YES manual up                    up

The Method column tells you how the IP address was assigned: manual means it was typed in configuration, DHCP means it was assigned by a DHCP server, unset means no address has been configured. Status/Protocol combinations decode as follows:

Status Protocol Meaning
up up Normal operational state
up down Physical link present, L2 failing (keepalive issue, encap mismatch)
administratively down down Shutdown command is applied
down down Physical failure — no carrier (cable, SFP, remote end down)

The “OK?” column is a legacy field from early IOS versions indicating whether the IP address is valid. It is almost always YES. A NO here indicates address configuration corruption and should be investigated immediately.

MTU Considerations

core-rtr-01(config-if)# ip mtu 1492

Interface MTU (mtu command) controls the maximum frame size the hardware will accept, including all headers. IP MTU (ip mtu command) controls the maximum size of the IP datagram the interface will forward without fragmenting. They can differ. A common scenario: jumbo frame-capable links where the interface MTU is 9000 but IP MTU is kept at 1500 for compatibility. If ip mtu is not set, it defaults to the interface MTU. MTU mismatches are one of the most difficult network problems to diagnose because ICMP path MTU discovery packets are often filtered by firewalls, causing TCP connections to hang after the initial handshake succeeds.


Static Routing

Next-Hop vs. Exit Interface Syntax

! Next-hop syntax — preferred on Ethernet
core-rtr-01(config)# ip route 10.1.0.0 255.255.0.0 192.168.1.1

! Exit interface syntax — use with caution on multi-access networks
core-rtr-01(config)# ip route 10.1.0.0 255.255.0.0 GigabitEthernet0/1

! Both combined — most explicit and safest
core-rtr-01(config)# ip route 10.1.0.0 255.255.0.0 GigabitEthernet0/1 192.168.1.1

The exit interface syntax creates what is called a “connected” static route in the routing table, which tells IOS to ARP for the destination IP directly on that interface. On point-to-point links like serial interfaces, this is fine — there is only one possible next hop. On Ethernet segments (which are multi-access networks), this causes the router to ARP for every possible destination IP it tries to reach via that route — potentially flooding the network with ARP requests. Use next-hop syntax on Ethernet. Use exit interface or both together on serial and other point-to-point links.

Default Route and Floating Static

! Default route — matches everything not matched by a more specific entry
core-rtr-01(config)# ip route 0.0.0.0 0.0.0.0 203.0.113.1

! Floating static — AD of 254, used as backup when primary route disappears
core-rtr-01(config)# ip route 0.0.0.0 0.0.0.0 10.0.0.2 254

A floating static route with a higher administrative distance than the primary route (dynamically learned or lower-AD static) sits dormant in the configuration but does not appear in the routing table as long as the primary route exists. When the primary fails and its entry is removed from the table, the floating static installs itself. This is a simple and reliable failover mechanism for dual-WAN scenarios. The default static route AD is 1; OSPF external routes are 110; EIGRP external routes are 170. Set your floating static AD higher than whatever it is backing up.

Show IP Route — Annotated

core-rtr-01# show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       + - replicated route, % - next hop override, p - overrides from PfR

Gateway of last resort is 203.0.113.1 to network 0.0.0.0

S*    0.0.0.0/0 [1/0] via 203.0.113.1                  ! (1) Default route, AD=1 metric=0
      10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C        10.1.1.0/30 is directly connected, Serial0/0/0  ! (2) Connected network
L        10.1.1.1/32 is directly connected, Serial0/0/0  ! (3) Local host route
O        10.2.0.0/16 [110/65] via 10.1.1.2, 3d04h, Serial0/0/0 ! (4) OSPF route
D        10.3.0.0/16 [90/2172416] via 10.1.1.2, 1w2d, Serial0/0/0 ! (5) EIGRP route
      203.0.113.0/24 is variably subnetted, 2 subnets, 2 masks
C        203.0.113.0/30 is directly connected, GigabitEthernet0/0
L        203.0.113.2/32 is directly connected, GigabitEthernet0/0

(1) The S* code means static candidate default. The [1/0] notation is [administrative-distance/metric]. AD of 1 for static routes; metric 0 because static routes have no protocol-computed metric.

(2) C for connected means the network is directly attached. IOS installs a connected route automatically when an interface has an IP address and is in the up/up state.

(3) L for local is a /32 host route for the router’s own interface address, added in IOS 12.3 and later. It enables the router to recognize packets destined to its own address without needing to look up the connected route.

(4) O for OSPF. [110/65] means AD=110 (OSPF default) and metric=65 (the accumulated OSPF cost). The route was learned via 10.1.1.2, it is 3 days and 4 hours old, and it was last seen on Serial0/0/0. The age counter resets on each SPF recalculation.

(5) D for EIGRP (historically called DUAL, hence D). EIGRP metrics are large composite numbers — 2172416 here. The [90/...] shows AD=90, which is EIGRP’s default for internal routes.

! Longest prefix match lookup for a specific destination
core-rtr-01# show ip route 10.2.4.100
Routing entry for 10.2.0.0/16
  Known via "ospf 1", distance 110, metric 65, type intra area
  Last update from 10.1.1.2 on Serial0/0/0, 3 days, 04:14:22 ago
  Routing Descriptor Blocks:
  * 10.1.1.2, from 10.1.1.2, 3 days, 04:14:22 ago, via Serial0/0/0
      Route metric is 65, traffic share count is 1

This form shows you exactly which entry IOS will use for a given destination, following the longest prefix match rule. Useful for verifying that a specific host or subnet will be routed as expected.


OSPF (Single-Area)

Basic OSPF Configuration

core-rtr-01(config)# router ospf 1
core-rtr-01(config-router)# router-id 10.255.0.1
core-rtr-01(config-router)# passive-interface GigabitEthernet0/0   ! No hellos toward ISP
core-rtr-01(config-router)# network 10.0.0.0 0.255.255.255 area 0
core-rtr-01(config-router)# network 10.255.0.1 0.0.0.0 area 0

! Modern per-interface style (IOS 12.4+) — cleaner and more explicit:
core-rtr-01(config)# interface GigabitEthernet0/1
core-rtr-01(config-if)# ip ospf 1 area 0
core-rtr-01(config-if)# ip ospf priority 200          ! Influence DR election

Setting the router-id explicitly to a loopback address prevents OSPF from picking a random interface address as its identifier. If the router-id changes — because an interface went down and IOS chose a different highest IP — OSPF drops and rebuilds all adjacencies. This is disruptive. Explicit router-id from a stable loopback prevents this entirely.

passive-interface stops OSPF from sending Hello packets out an interface while still advertising the interface’s connected network into OSPF. Use it on any interface that faces a non-OSPF device: LAN segments with only hosts, uplinks to ISPs, stub networks. Every Hello packet on a public or host-facing interface is both unnecessary traffic and a potential information disclosure.

Show IP OSPF Neighbor — Annotated

core-rtr-01# show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
10.255.0.2       1   FULL/DR         00:00:32    10.1.1.2        Serial0/0/0
10.255.0.3       1   FULL/BDR        00:00:39    10.10.1.2       GigabitEthernet0/1
10.255.0.4       0   2WAY/DROTHER    00:00:37    10.10.1.3       GigabitEthernet0/1

Neighbor ID: The OSPF router-id of the neighbor, not its interface address. If you configured explicit router-ids (as you should), this is predictable. If not, it is the highest loopback IP or highest active interface IP on the neighbor — which can change.

Pri: OSPF priority for DR/BDR election on this interface. Priority 0 means the router is ineligible to be DR or BDR. On point-to-point links, priority is irrelevant and the state will show FULL/- (no DR election).

State: This is what you spend the most time reading. Normal states are:

  • FULL/DR or FULL/BDR — fully adjacent with the DR or BDR. Database is synchronized.
  • FULL/- — fully adjacent on a point-to-point link. Normal and healthy.
  • 2WAY/DROTHER — bidirectional communication established but not fully adjacent (this is normal for non-DR/BDR routers on multi-access segments).
  • EXSTART — beginning the database exchange. If stuck here, there is usually an MTU mismatch between neighbors.
  • EXCHANGE — exchanging database descriptor packets. Stuck here usually means packet loss or MTU issues.
  • LOADING — waiting for LSA requests to complete. Stuck here can indicate retransmission issues.
  • INIT — only one-way communication. The remote router is not sending Hellos back, or its Hellos do not include this router’s ID.
  • ATTEMPT — only relevant on NBMA networks; waiting to hear back from a statically configured neighbor.

Dead Time: Countdown from the dead interval (default 40 seconds, 4x the hello interval). When this hits zero, the neighbor is declared dead and adjacency drops. Wildly varying dead times (jumping around erratically) suggest Hello packets are being lost intermittently.

Address: The neighbor’s interface IP address on the link between the two routers.

Show IP OSPF Interface

core-rtr-01# show ip ospf interface GigabitEthernet0/1
GigabitEthernet0/1 is up, line protocol is up
  Internet Address 10.10.1.1/24, Area 0, Attached via Interface Enable
  Process ID 1, Router ID 10.255.0.1, Network Type BROADCAST, Cost: 1
  Transmit Delay is 1 sec, State DR, Priority 200
  Designated Router (ID) 10.255.0.1, Interface address 10.10.1.1
  Backup Designated Router (ID) 10.255.0.3, Interface address 10.10.1.2
  Flush timer for old DR LSA due in 00:01:53
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
  oob-resync timeout 40
    Hello due in 00:00:05
  Supports Link-local Signaling (LLS)
  Cisco NSF helper support enabled
  IETF NSF helper support enabled
  Index 1/2/2, flood queue length 0
  Next 0x0(0)/0x0(0)/0x0(0)
  Last flood scan length is 1, maximum is 7
  Last flood scan time is 0 msec, maximum is 1 msec
  Neighbor Count is 2, Adjacent neighbor count is 2
  Adjacent with neighbor 10.255.0.3  (Backup Designated Router)
  Adjacent with neighbor 10.255.0.4
  Suppress hello for 0 neighbor(s)

The hello and dead timer values must match between neighbors for adjacency to form. If one side is configured with ip ospf hello-interval 5 and the other is at the default 10, adjacency will never form. The cost value feeds directly into SPF — 1 is the minimum and means this is a high-speed interface.

Clear IP OSPF Process

core-rtr-01# clear ip ospf process
Reset ALL OSPF processes? [no]: yes

Use this command when you change the OSPF router-id and need the new ID to take effect. OSPF router-id changes do not take effect automatically — OSPF must be restarted. The impact: all adjacencies are dropped and reformed, all routes from OSPF are removed from the routing table and relearned. On a production router with many neighbors, this can cause a brief routing outage. Always schedule during a maintenance window.


EIGRP

Basic EIGRP Configuration

core-rtr-01(config)# router eigrp 100
core-rtr-01(config-router)# eigrp router-id 10.255.0.1
core-rtr-01(config-router)# network 10.0.0.0 0.255.255.255
core-rtr-01(config-router)# no auto-summary
core-rtr-01(config-router)# passive-interface GigabitEthernet0/0

no auto-summary is critical in EIGRP. With auto-summary enabled (the default on older IOS), EIGRP automatically summarizes routes at classful boundaries — advertising 10.0.0.0/8 at a major network boundary instead of the specific /24s and /16s you actually have. This causes black-holing when you have discontiguous subnets. Always disable auto-summary. Modern IOS Named EIGRP mode disables it by default.

Show IP EIGRP Neighbors — Annotated

core-rtr-01# show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(100)
H   Address         Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                    (sec)         (ms)       Cnt Num
0   10.1.1.2        Se0/0/0           11 3w1d       12   200  0  1847
1   10.10.1.2       Gi0/1             12 5d12h       3   200  0  4291

H (Handle): Internal identifier for this neighbor entry. Not meaningful for troubleshooting.

Hold: Countdown to neighbor timeout. Default hold time is 15 seconds (3x the hello interval of 5). If this repeatedly resets just before hitting zero, EIGRP hellos are arriving inconsistently — possible packet loss or interface flapping.

SRTT (Smooth Round-Trip Time): Milliseconds to receive an EIGRP acknowledgment from this neighbor. Used to calculate RTO. Dramatically high SRTT values (hundreds of ms) on a link that should be low-latency indicate a problem in the path.

RTO (Retransmission Timeout): How long EIGRP waits before retransmitting a reliable packet to this neighbor. Derived from SRTT. If Q Cnt is consistently non-zero, EIGRP is stuck retransmitting — check for packet loss.

Q Cnt: Number of EIGRP packets waiting in the queue for this neighbor. Should be 0. A stuck non-zero value means EIGRP cannot get packets through and the neighbor is on the verge of being declared dead.

Seq Num: Last sequence number received from this neighbor. Monotonically increasing. If this stops incrementing while the neighbor stays up, something is filtering EIGRP packets.

Show IP EIGRP Topology — Annotated

core-rtr-01# show ip eigrp topology
EIGRP-IPv4 Topology Table for AS(100)/ID(10.255.0.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply, r - reply Status, s - sia Status

P 10.2.0.0/16, 1 successors, FD is 2172416
        via 10.1.1.2 (2172416/28160), Serial0/0/0     ! Successor: FD/RD
        via 10.10.1.2 (2684416/28160), GigabitEthernet0/1  ! Feasible successor

P 10.3.0.0/16, 1 successors, FD is 28160
        via Connected, GigabitEthernet0/1

P / A state: Passive is normal — the route is stable. Active means EIGRP is actively querying the network because the successor route was lost and no feasible successor exists. An Active state that does not resolve (called Stuck-in-Active, or SIA) means EIGRP queries are not returning and indicates a broken topology or a device that is overwhelmed and not responding to queries.

FD (Feasible Distance): The best metric from this router to the destination via the successor route. This is the value stored in the routing table.

RD (Reported Distance): The metric reported by the neighbor (the neighbor’s FD). Shown after the / in the topology entry: (2172416/28160) means local FD is 2172416, neighbor reported 28160.

Feasibility Condition: A route is a feasible successor (and can be used for immediate failover without DUAL recalculation) only if its RD is less than the current FD. This guarantees the feasible successor is not a potential routing loop. In the example above, 10.10.1.2’s RD of 28160 is less than the current FD of 2172416, making it a feasible successor.

Unequal-Cost Load Balancing

core-rtr-01(config-router)# variance 2

EIGRP’s variance multiplier enables load balancing across unequal-cost paths. With variance 2, any feasible successor whose FD is within 2x of the successor’s FD will be used for load balancing. Traffic shares are proportional to metrics — the better path gets more traffic. Without variance, EIGRP only load-balances across equal-cost paths.


Switching — VLANs, Trunks, and STP

VLAN Creation

core-sw-01(config)# vlan 10
core-sw-01(config-vlan)# name SALES
core-sw-01(config-vlan)# exit

core-sw-01(config)# vlan 20
core-sw-01(config-vlan)# name ENGINEERING
core-sw-01(config-vlan)# exit

VLANs 1, 1002–1005 are reserved and cannot be deleted. VLAN 1 is the native VLAN by default and carries untagged traffic on trunks — leave it for management traffic only and keep it off production trunk allowed-vlan lists, or change the native VLAN to a dedicated unused VLAN.

Show VLAN Brief — Annotated

core-sw-01# show vlan brief
VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
1    default                          active    Gi1/0/1, Gi1/0/2, Gi1/0/3
10   SALES                            active    Gi1/0/4, Gi1/0/5, Gi1/0/6
20   ENGINEERING                      active    Gi1/0/7, Gi1/0/8
999  UNUSED_NATIVE                    active
1002 fddi-default                     act/unsup
1003 token-ring-default               act/unsup
1004 fddinet-default                  act/unsup
1005 trnet-default                    act/unsup

This output only shows access ports assigned to each VLAN. Trunk ports do not appear here — they carry multiple VLANs and are shown separately in show interfaces trunk. An interface that does not appear in any VLAN in this output and is not a trunk is likely in VLAN 1 by default.

Access Port Configuration

core-sw-01(config)# interface GigabitEthernet1/0/4
core-sw-01(config-if)# description SALES-WORKSTATION-FLOOR-2
core-sw-01(config-if)# switchport mode access
core-sw-01(config-if)# switchport access vlan 10
core-sw-01(config-if)# spanning-tree portfast
core-sw-01(config-if)# spanning-tree bpduguard enable
core-sw-01(config-if)# no shutdown

switchport mode access hard-sets the port to access mode, disabling DTP (Dynamic Trunking Protocol) negotiation. Never leave edge ports in the default “dynamic auto” or “dynamic desirable” mode. DTP negotiation is a switch-spoofing attack vector.

spanning-tree portfast moves the port directly to forwarding state when a device connects, bypassing the 30-second listening and learning delay. Appropriate only for access ports connected to end hosts, never for connections to other switches.

spanning-tree bpduguard enable shuts the port immediately if a BPDU is received. If someone connects a cheap unmanaged switch or a laptop running a Spanning Tree emulator to a portfast port, a BPDU would normally cause STP to reconfigure — potentially disrupting the entire spanning tree. BPDU guard prevents this by error-disabling the port instead. To recover: shutdown then no shutdown, or configure spanning-tree portfast bpduguard default to auto-recover.

Trunk Port Configuration

core-sw-01(config)# interface GigabitEthernet1/0/48
core-sw-01(config-if)# description UPLINK-TO-CORE-ROUTER
core-sw-01(config-if)# switchport trunk encapsulation dot1q
core-sw-01(config-if)# switchport mode trunk
core-sw-01(config-if)# switchport trunk native vlan 999
core-sw-01(config-if)# switchport trunk allowed vlan 10,20,30,999
core-sw-01(config-if)# no shutdown

switchport trunk encapsulation dot1q is required on switches that support both ISL and 802.1Q. On most modern Catalyst platforms, 802.1Q is the only option and this command is not needed. On older switches and in lab environments, forgetting this when it is required will cause the trunk to fail silently.

Explicitly defining allowed vlan is a best practice. The default allows all VLANs (1-4094) on a trunk. Restricting the allowed list to only VLANs that actually need to traverse the trunk limits broadcast domain propagation and is a basic security control against VLAN hopping attacks.

Show Interfaces Trunk — Annotated

core-sw-01# show interfaces trunk
Port        Mode             Encapsulation  Status        Native vlan
Gi1/0/48    on               802.1q         trunking      999

Port        Vlans allowed on trunk
Gi1/0/48    10,20,30,999

Port        Vlans allowed and active in management domain
Gi1/0/48    10,20,999

Port        Vlans in spanning tree forwarding state and not pruned
Gi1/0/48    10,20,999

Four separate VLAN lists for the trunk. Read them from bottom up to understand why traffic is or is not flowing:

The bottom list (forwarding and not pruned) is what actually carries traffic. Work upward — if a VLAN is missing from the bottom list but present in the third list (allowed and active), STP is blocking it. If it is in the second list (allowed) but not the third (active), the VLAN does not exist on this switch. If it is not in the second list, it was never added to the allowed list.

STP — Show Spanning-Tree — Annotated

core-sw-01# show spanning-tree vlan 10
VLAN0010
  Spanning tree enabled protocol ieee
  Root ID    Priority    24586                          ! (1) Root bridge info
             Address     aabb.cc01.0001
             Cost        4                              ! (2) Path cost to root
             Port        48 (GigabitEthernet1/0/48)
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    32778  (priority 32768 sys-id-ext 10)   ! (3) Local bridge
             Address     aabb.cc02.0002
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
             Aging Time  300 sec

Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi1/0/4             Desg FWD 4         128.4    P2p Edge                   ! (4)
Gi1/0/5             Desg FWD 4         128.5    P2p Edge
Gi1/0/48            Root FWD 4         128.48   P2p                        ! (5)

(1) Root ID shows the root bridge — the switch with the lowest bridge priority (tie-broken by MAC address). The root bridge is not necessarily the best-placed switch; it is simply the one with the lowest bridge ID. In production, always set bridge priorities explicitly rather than leaving it to MAC address lottery.

(2) Path cost accumulates as STP messages travel from root to edge. Lower is closer to root. The cost value depends on the STP variant: classic 802.1D uses port speed-based costs; Rapid STP (RSTP, 802.1w) uses the same default costs but converges much faster.

(3) The local switch’s own bridge ID. Priority 32778 is the default priority (32768) plus the VLAN ID (10). This is extended system ID — IOS automatically adds the VLAN number to the base priority to differentiate per-VLAN spanning trees.

(4) Port role Desg (Designated) and state FWD (Forwarding). Designated ports forward traffic toward the leaves of the spanning tree. Edge indicates portfast is configured.

(5) Role Root — this is the port that leads toward the root bridge. There is exactly one Root port per non-root switch.

Port states in STP: Blocking — receives BPDUs but does not forward frames (prevents loops). Listening — participating in STP calculations, not forwarding. Learning — building MAC table, not forwarding. Forwarding — fully operational. With RSTP, the listening state is eliminated and convergence is dramatically faster (sub-second vs. 30-50 seconds for legacy STP).

Show MAC Address-Table — Annotated

core-sw-01# show mac address-table
          Mac Address Table
-------------------------------------------
Vlan    Mac Address       Type        Ports
----    -----------       --------    -----
  10    0050.7966.0001    DYNAMIC     Gi1/0/4
  10    0050.7966.0002    DYNAMIC     Gi1/0/5
  10    aabb.cc01.0001    DYNAMIC     Gi1/0/48
   1    aabb.cc02.0002    STATIC      CPU

Dynamic entries are learned from incoming frames and age out after 300 seconds (default). Static entries are manually configured and never age out — the CPU entry is the switch’s own MAC address. If a MAC address appears on a port that should not have it, or appears on multiple ports simultaneously (which can indicate a loop), the MAC table is your first diagnostic tool.


NAT and PAT

Interface Designation and PAT Configuration

core-rtr-01(config)# interface GigabitEthernet0/0
core-rtr-01(config-if)# ip nat outside        ! Faces the public internet

core-rtr-01(config)# interface GigabitEthernet0/1
core-rtr-01(config-if)# ip nat inside         ! Faces internal RFC1918 space

! Create an ACL matching inside hosts
core-rtr-01(config)# ip access-list standard NAT_INSIDE_HOSTS
core-rtr-01(config-std-nacl)# permit 10.10.0.0 0.0.255.255
core-rtr-01(config-std-nacl)# exit

! PAT: translate all inside hosts to the outside interface's IP
core-rtr-01(config)# ip nat inside source list NAT_INSIDE_HOSTS interface GigabitEthernet0/0 overload

The overload keyword enables PAT (Port Address Translation). Without it, IOS creates one-to-one NAT translations — you would need a public IP for each private host. PAT extends the pool by multiplexing many private hosts onto a single public IP using unique port numbers. The interface keyword tells NAT to use the interface’s current IP dynamically — essential when the public IP is assigned by DHCP from the ISP.

Static NAT

! Map a specific inside host to a dedicated public IP
core-rtr-01(config)# ip nat inside source static 192.168.1.10 203.0.113.10

Static NAT creates a permanent bidirectional mapping. Traffic to 203.0.113.10 from the outside is forwarded to 192.168.1.10, and outbound traffic from 192.168.1.10 always appears as 203.0.113.10. Used for servers that need consistent public addresses — web servers, mail servers, VPN endpoints.

Show IP NAT Translations — Annotated

core-rtr-01# show ip nat translations
Pro  Inside global       Inside local        Outside local      Outside global
---  203.0.113.2:1024    10.10.1.5:1024     8.8.8.8:53         8.8.8.8:53
tcp  203.0.113.2:52341   10.10.1.10:52341   93.184.216.34:443  93.184.216.34:443
tcp  203.0.113.2:52342   10.10.1.11:3389    10.10.1.12:3389    10.10.1.12:3389
---  203.0.113.10        192.168.1.10       ---                ---

Inside local: The private IP (and port for PAT) of the host on the inside network as it originates the connection.

Inside global: The public IP (and port for PAT) that the inside host appears as to the outside world. This is what the internet sees.

Outside local: The IP of the remote server as the inside host believes it to be. In standard NAT, this equals the outside global. In double-NAT or hairpin scenarios, these can differ.

Outside global: The actual public IP of the remote server.

The translation table is your first stop for NAT debugging. If a host cannot reach the internet, look for its inside local address here. If it is missing, NAT is not triggering — check that the access-list matches the host and that the interface has ip nat inside configured. If the inside global shows the wrong public IP, check your NAT pool or interface designation.

NAT Diagnostics

! High-level statistics
core-rtr-01# show ip nat statistics
Total active translations: 47 (1 static, 46 dynamic; 46 extended)
Peak translations: 312, occurred 00:14:22 ago
Outside interfaces: GigabitEthernet0/0
Inside interfaces: GigabitEthernet0/1
Hits: 198432  Misses: 14
CEF Translated packets: 198432, CEF Punted packets: 0
Dynamic mappings:
-- Inside Source
[Id: 1] access-list NAT_INSIDE_HOSTS interface GigabitEthernet0/0 refcount 46

! Clear all dynamic translations (use when changing NAT config)
core-rtr-01# clear ip nat translation *

! Debug NAT in real time — WARNING: use only in lab or off-hours on prod
core-rtr-01# debug ip nat
NAT: s=10.10.1.5->203.0.113.2, d=8.8.8.8 [14821]
NAT*: s=8.8.8.8, d=203.0.113.2->10.10.1.5 [14821]

The asterisk in NAT* means the translation was performed in the fast path (CEF). Without the asterisk, it was process-switched. debug ip nat generates one or more lines per translated packet. On a high-traffic router, this will saturate the CPU and potentially crash the device. Do not run it on production during business hours. Use debug ip nat 10.10.1.5 to limit output to a specific host, and always undebug all immediately after collecting the information you need.

clear ip nat translation * removes all dynamic translations. Required when testing configuration changes because existing translations will continue to use the old rules until they expire. Does not clear static NAT entries.


Access Control Lists

Standard ACL

! Numbered standard — matches source IP only
core-rtr-01(config)# access-list 10 permit 192.168.1.0 0.0.0.255
core-rtr-01(config)# access-list 10 permit 10.10.0.0 0.0.255.255
! Implicit deny all follows every ACL — not shown but always present

Standard ACLs only examine source IP. Place them as close to the destination as possible to avoid blocking traffic unnecessarily before it reaches its destination.

Extended Named ACL

core-rtr-01(config)# ip access-list extended BLOCK_TELNET
core-rtr-01(config-ext-nacl)# 10 deny   tcp any any eq 23 log
core-rtr-01(config-ext-nacl)# 20 deny   tcp any any eq telnet log
core-rtr-01(config-ext-nacl)# 30 permit ip any any
core-rtr-01(config-ext-nacl)# exit

core-rtr-01(config)# interface GigabitEthernet0/0
core-rtr-01(config-if)# ip access-group BLOCK_TELNET in

Extended ACLs can match source IP, destination IP, protocol, and port numbers. Named ACLs allow editing by sequence number — you can insert a rule between existing entries without rewriting the entire list:

core-rtr-01(config)# ip access-list extended BLOCK_TELNET
core-rtr-01(config-ext-nacl)# 15 deny tcp 10.5.0.0 0.0.0.255 any eq 22

This inserts a rule with sequence number 15 between rules 10 and 20. With numbered ACLs, you would have to delete the entire ACL and re-enter every line.

Show IP Access-Lists — Annotated

core-rtr-01# show ip access-lists BLOCK_TELNET
Extended IP access list BLOCK_TELNET
    10 deny tcp any any eq telnet log (247 matches)   ! (1) sequence, action, match count
    15 deny tcp 10.5.0.0 0.0.0.255 any eq 22 (0 matches)  ! (2) zero matches — suspicious
    20 deny tcp any any eq 23 log (0 matches)
    30 permit ip any any (1948273 matches)

(1) The match count in parentheses is your most powerful troubleshooting tool. 247 matches on the telnet deny means someone is actively trying telnet connections — worth investigating. A permit rule with millions of matches is expected for a “permit ip any any” at the bottom.

(2) Zero matches on a rule that should be active is a red flag. Either no traffic matching that criterion has arrived, or the traffic was matched by an earlier rule and never reached this one. If rule 15 should be blocking SSH from the 10.5.0.0 subnet and shows zero matches, either the traffic is not originating from that subnet, it is coming from a different interface than where the ACL is applied, or the ACL is applied in the wrong direction.

The implicit deny at the end of every ACL never shows in show ip access-lists. To see if traffic is hitting the implicit deny, look for asymmetric match counts — if you expect traffic to be permitted by rule 30 but are seeing connectivity issues, check whether the permit count is increasing at all.

VTY ACL

core-rtr-01(config)# access-list 10 permit 10.10.100.0 0.0.0.255   ! Management subnet only

core-rtr-01(config)# line vty 0 4
core-rtr-01(config-line)# access-class 10 in

access-class on VTY lines is distinct from ip access-group on interfaces. ip access-group filters traffic through or to the interface. access-class restricts which source IPs can establish management sessions. This is an essential hardening step — without it, anyone who can reach the router’s IP can attempt to authenticate.


DHCP on IOS

DHCP Server Configuration

core-rtr-01(config)# ip dhcp excluded-address 10.10.1.1 10.10.1.20    ! Reserve for statics
core-rtr-01(config)# ip dhcp excluded-address 10.10.1.254

core-rtr-01(config)# ip dhcp pool VLAN10_POOL
core-rtr-01(dhcp-config)# network 10.10.1.0 255.255.255.0
core-rtr-01(dhcp-config)# default-router 10.10.1.1
core-rtr-01(dhcp-config)# dns-server 8.8.8.8 8.8.4.4
core-rtr-01(dhcp-config)# domain-name lunarops.internal
core-rtr-01(dhcp-config)# lease 7                                      ! 7 days

The excluded-address ranges must be configured before the pool, or the router may assign those IPs before learning they are reserved. This is a common misconfiguration in rushed deployments. Best practice: exclude the entire static assignment range (gateways, servers, network equipment) before defining the pool.

DHCP Relay

! On the interface facing the DHCP clients:
core-rtr-01(config-if)# ip helper-address 10.100.1.10    ! Address of the DHCP server

DHCP uses broadcast by default (DORA: Discover, Offer, Request, Acknowledge). Broadcasts do not cross router interfaces. ip helper-address converts the client’s broadcast Discover into a unicast packet forwarded to the DHCP server, and forwards the server’s unicast response back to the client as a directed broadcast. It handles not just DHCP but several other broadcast-based protocols (TFTP, TACACS, DNS broadcast) — adjust with no ip forward-protocol udp if you want to restrict forwarding to DHCP only.

Show IP DHCP Binding — Annotated

core-rtr-01# show ip dhcp binding
Bindings from all pools not associated with VRF:
IP address       Client-ID/              Lease expiration        Type       State      Interface
                 Hardware address/
                 User name
10.10.1.21       0100.5079.6600.01       Jun 02 2026 09:47 AM    Automatic  Active     Gi0/1
10.10.1.22       0100.5079.6600.02       Jun 02 2026 11:23 AM    Automatic  Active     Gi0/1
10.10.1.50       0100.5079.6601.00       Infinite                Manual     Active     Gi0/1

The Client-ID format 01xx.xx... indicates Ethernet (type 01) followed by the MAC address. Lease expiration timestamps help diagnose renewal issues — a lease that expired yesterday with a still-active binding means the client stopped renewing but the router has not aged the entry. Use clear ip dhcp binding * to flush all dynamic bindings or clear ip dhcp binding 10.10.1.21 for a specific address.

core-rtr-01# show ip dhcp pool
Pool VLAN10_POOL :
 Utilization mark (high/low)    : 100 / 0
 Subnet size (first/next)       : 0 / 0
 Total addresses                : 233
 Leased addresses               : 47
 Excluded addresses              : 21
 Pending event                  : none

 1 subnet is currently in the pool :
 Current index        IP address range                    Leased/Excluded/Total
 10.10.1.47           10.10.1.0    - 10.10.1.255         47     / 21    / 254

Pool utilization monitoring is important in environments with large numbers of endpoints. When leased + excluded approaches total, new devices cannot obtain addresses. The current index shows the next address IOS will try to allocate — useful for understanding pool exhaustion progression.


Essential Diagnostics

Extended Ping

core-rtr-01# ping
Protocol [ip]:
Target IP address: 10.2.4.100
Repeat count [5]: 100
Datagram size [100]: 1472
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: Loopback0
Type of service [0]:
Set DF bit in IP header? [no]: yes
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 100, 1472-byte ICMP Echos to 10.2.4.100, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 8/11/19 ms

Extended ping is far more useful than the default five-packet form. Sourcing from the loopback tests the full routing path as the remote device will see it. Setting the DF (Don’t Fragment) bit and varying the datagram size helps diagnose MTU issues — if large packets fail while small ones succeed, you have an MTU problem somewhere in the path. Each ! represents a successful reply; . is a timeout; U is destination unreachable.

Traceroute — Annotated

core-rtr-01# traceroute 8.8.8.8
Type escape sequence to abort.
Tracing the route to dns.google (8.8.8.8)
VRF info: (vrf in name/id, vrf out name/id)
  1 203.0.113.1 [AS 65000] 4 msec 4 msec 4 msec       ! (1) ISP gateway, 3 probes
  2 192.0.2.45 8 msec 8 msec 8 msec                   ! (2) ISP core router
  3 * * *                                               ! (3) Filtered — no response
  4 72.14.238.1 18 msec 18 msec 18 msec
  5 8.8.8.8 20 msec 20 msec 19 msec

Each row is one TTL hop. IOS sends three probes per TTL; the three time values are the RTT for each probe. Common return codes beyond the standard RTT:

Code Meaning
* Probe timed out — router either does not respond to TTL-exceeded or is filtering ICMP
!H Host unreachable — the next-hop router can reach the network but not the specific host
!N Network unreachable — no route to the destination network
!P Protocol unreachable — the host is reachable but the protocol is not allowed
!A Administratively prohibited — an ACL is blocking the traffic
!Q Source quench — congestion signal (obsolete, rarely seen)

Three consecutive * * * rows that are immediately followed by a working hop indicate a transit router that does not generate ICMP TTL-exceeded messages — this is normal behavior for some service provider core routers and does not indicate a problem. Three * * * rows at the end of a traceroute that never resolves indicates the destination is unreachable or an ACL is blocking your ICMP entirely.

CPU and Memory

core-rtr-01# show processes cpu
CPU utilization for five seconds: 8%/4%; one minute: 6%; five minutes: 5%
 PID Runtime(ms)   Invoked      uSecs   5Sec   1Min   5Min TTY Process
   1     1039        9476        109  0.00%  0.00%  0.00%   0 Chunk Manager
   2       23        1223         18  0.00%  0.00%  0.00%   0 Load Meter
 212    48392      204873        236  4.00%  3.87%  3.91%   0 IP Input
 215     8392       98234         85  0.16%  0.14%  0.13%   0 OSPF Hello

The first line shows interrupt (hardware) vs. process CPU: “8%/4%” means 8% total, 4% interrupt. High interrupt CPU (second number close to total) indicates the hardware is receiving more packets than the software can handle — a forwarding plane issue, often a DDoS or routing loop. High process CPU with low interrupt points to a specific process consuming cycles. The IP Input process at 4% is normal under moderate load. If you see IP Input at 90%+, the router is process-switching a large volume of traffic — CEF may be disabled or misconfigured.

core-rtr-01# show processes memory sorted
                   Free Memory: 241108 K
                  Total Memory: 523364 K
 PID TTY  Allocated      Freed    Holding    Getbufs    Retbufs Process
   0   0  198741688   57819256   140927808          0          0 *Init*
 212   0   12847932   11293424    1554508          0          0 IP Input

Memory leak indicators: a process whose “Holding” column grows monotonically over days without ever decreasing. Compare Allocated minus Freed versus Holding — if holding is significantly less than allocated-freed, memory is being released normally. If holding approaches allocated-freed and keeps growing, investigate that process.

Logging

core-rtr-01# show logging
Syslog logging: enabled (11 messages dropped, 1 messages rate-limited,
                0 flushes, 0 overruns, xml disabled, filtering disabled)

No Active Message Discriminator.
No Inactive Message Discriminator.

    Console logging: level debugging, 2847 messages logged, xml disabled,
                     filtering disabled
    Monitor logging: level debugging, 0 messages logged, xml disabled,
                     filtering disabled
    Buffer logging:  level debugging, 2847 messages logged, xml disabled,
                    filtering disabled
    Exception Logging: size (8192 bytes)
    Count and timestamp logging messages: disabled
    Persistent logging: disabled

Log Buffer (8192 bytes):
May 26 14:23:01.443: %LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to up
May 26 14:23:02.443: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/1, changed state to up
May 26 14:31:18.129: %OSPF-5-ADJCHG: Process 1, Nbr 10.255.0.2 on Serial0/0/0 from LOADING to FULL, Loading Done

Log messages follow the format: %FACILITY-SEVERITY-MNEMONIC: description. Severity levels: 0=Emergency, 1=Alert, 2=Critical, 3=Error, 4=Warning, 5=Notice, 6=Informational, 7=Debug. A sudden appearance of severity 3 (Error) or worse messages from facilities like OSPF, BGP, or LINEPROTO warrants immediate investigation. The logging buffer is circular — older messages are overwritten. For persistent logging, forward to a syslog server with logging host 10.100.1.20.

Debug Best Practices

! Always use terminal monitor when SSH'd in — debug output goes to console by default
core-rtr-01# terminal monitor

! Limit scope whenever possible
core-rtr-01# debug ip ospf hello
core-rtr-01# debug ip packet detail 10            ! ACL 10 limits to specific hosts

! Check what is running
core-rtr-01# show debug

! THE MOST IMPORTANT COMMAND IN YOUR DEBUG TOOLKIT:
core-rtr-01# undebug all
! Or equivalently:
core-rtr-01# no debug all

Never leave debug enabled. It is not a passive monitoring tool — every matched packet generates a log message and process-switches through the CPU rather than through CEF. On a high-traffic router, even a targeted debug ip packet for a single host can consume enough CPU to impact forwarding. Develop the habit of undebug all before you close any session where you ran debug. Consider setting no debug all in your SSH client’s disconnect script.

Show CDP Neighbors Detail

core-rtr-01# show cdp neighbors detail
-------------------------
Device ID: core-sw-01
Entry address(es):
  IP address: 10.10.1.2
Platform: cisco WS-C3750X-48P,  Capabilities: Switch IGMP
Interface: GigabitEthernet0/1,  Port ID (outgoing port): GigabitEthernet1/0/48
Holdtime : 171 sec

Version :
Cisco IOS Software, Version 15.2(4)E7...

advertisement version: 2
VTP Management Domain: ''
Native VLAN: 999
Duplex: full
Management address(es):
  IP address: 10.10.1.2

CDP is a Cisco proprietary Layer 2 discovery protocol that operates before IP is configured, making it invaluable when you are working on a device with no documentation. It tells you the neighbor’s hostname, platform, IOS version, connected interfaces, native VLAN, and management IP. On a network with no topology diagram, show cdp neighbors detail on every reachable device will reconstruct the physical topology in under an hour. Disable CDP on external-facing interfaces: no cdp enable at the interface level, or no cdp run globally if you want to disable it everywhere (you lose discovery from your own management tools in that case).


Configuration Management

Viewing and Comparing Config

core-rtr-01# show running-config
core-rtr-01# show startup-config

! View a specific section — much more efficient on large configs
core-rtr-01# show running-config | section ospf
core-rtr-01# show running-config | include ip route
core-rtr-01# show running-config interface GigabitEthernet0/0

The | section, | include, and | exclude pipes are essential on modern routers with thousands of lines of configuration. show running-config | section router ospf shows the entire OSPF block. show running-config | include ^interface shows only interface declaration lines (the ^ anchors to start of line, filtering out sub-interface commands).

TFTP Backup and Restore

! Backup running config to TFTP
core-rtr-01# copy running-config tftp:
Address or name of remote host []? 10.100.1.50
Destination filename [core-rtr-01-confg]? core-rtr-01-2026-05-28.cfg
!!
1892 bytes copied in 0.432 secs (4381 bytes/sec)

! Restore from TFTP — NOTE: this MERGES, it does not replace
core-rtr-01# copy tftp: running-config
Address or name of remote host []? 10.100.1.50
Source filename []? core-rtr-01-2026-05-28.cfg
Destination filename [running-config]?
Accessing tftp://10.100.1.50/core-rtr-01-2026-05-28.cfg...
Loading core-rtr-01-2026-05-28.cfg from 10.100.1.50 (via GigabitEthernet0/0):
!!
[OK - 1892 bytes]

The critical distinction: copy tftp: running-config merges the restored configuration into the existing running config, it does not replace it. Lines in the current config that are not in the restored file remain in effect. To perform a true replacement, use configure replace:

! Atomic config replacement — safest restore method
core-rtr-01# configure replace tftp://10.100.1.50/core-rtr-01-2026-05-28.cfg
This will apply all necessary additions and deletions
to replace the current running configuration with the
contents of the specified configuration file, which is
assumed to be a complete configuration.

A rollback timer must first be set in order to use configure replace.
Enter the number of minutes to wait before rolling back [0 for immediate]: 5

Total number of passes: 1
Rollback Done

configure replace uses a diff-based algorithm to add and remove exactly the lines needed to bring the running config in line with the target file. The rollback timer is your safety net: if you lose connectivity during the replacement (you changed the management IP and locked yourself out), the router automatically reverts to the previous config after the timer expires. Set it whenever working remotely.

Configuration Archiving

core-rtr-01(config)# archive
core-rtr-01(config-archive)# path tftp://10.100.1.50/archive/core-rtr-01-
core-rtr-01(config-archive)# maximum 20
core-rtr-01(config-archive)# time-period 1440          ! Archive every 24 hours
core-rtr-01(config-archive)# write-memory              ! Archive on write memory
core-rtr-01(config-archive)# log config
core-rtr-01(config-archive-log-cfg)# notify syslog
core-rtr-01(config-archive-log-cfg)# hidekeys          ! Don't log passwords in changes

With log config enabled under archive, IOS records every configuration change along with the username, timestamp, and the exact commands entered. This is a primitive but effective change tracking system. Review it with:

core-rtr-01# show archive log config all
 idx   sess           user@line      Logged command
    1    1        admin@vty0        |  !--- IOS Config Change Thu May 26 14:47:23 2026
    2    1        admin@vty0        |  hostname core-rtr-01
    3    2        ops@vty1          |  !--- IOS Config Change Thu May 26 15:12:44 2026
    4    2        ops@vty1          |  interface GigabitEthernet0/1
    5    2        ops@vty1          |   ip address 10.10.2.1 255.255.255.0

In environments with proper TACACS+ AAA, this pairs with TACACS accounting to give you a complete audit trail: who logged in, from where, and what they changed.


Show Command Quick Reference

The following table covers the twenty show commands you will reach for most often in production. Bookmark this section.

Command What It Tells You When to Use It
show version IOS version, uptime, reload reason, RAM/flash, license First thing on any unfamiliar device
show ip interface brief All interface IPs, admin/protocol status at a glance Quick health check, finding down interfaces
show interfaces <intf> Detailed counters, errors, duplex/speed, load Investigating performance issues, layer 1/2 faults
show ip route Full routing table with source codes and AD/metric Verifying reachability, finding routing holes
show ip route <ip> Longest-prefix match for a specific destination Confirming which route will be used for a host
show ip ospf neighbor OSPF adjacency states, dead timers Diagnosing OSPF failures, slow convergence
show ip ospf database LSA database, checking for LSA flooding issues Validating OSPF topology visibility
show ip eigrp neighbors EIGRP adjacency health, SRTT, Q count EIGRP neighbor troubleshooting
show ip eigrp topology Successor and feasible successors, active/passive state EIGRP path selection, SIA investigation
show vlan brief VLAN database, access port assignments Switching fabric verification
show interfaces trunk Trunk mode, allowed/active/forwarding VLANs VLAN propagation issues, trunk verification
show spanning-tree vlan <id> Root bridge, port roles, port states STP loop prevention, convergence issues
show mac address-table Dynamic/static MAC-to-port mappings MAC flooding, unknown unicast flooding
show ip nat translations Active NAT/PAT translations NAT debugging, session verification
show ip nat statistics Translation hit/miss counts, pool utilization NAT health overview
show ip access-lists ACL entries with match counters Confirming ACL is matching expected traffic
show ip dhcp binding Active DHCP leases, MAC-to-IP mapping DHCP assignment verification, lease auditing
show logging Recent log buffer, severity levels Event investigation, error correlation
show processes cpu Per-process CPU utilization, interrupt vs. process High-CPU diagnosis, DDoS investigation
show cdp neighbors detail Neighbor hostname, platform, IP, interface Topology discovery, cabling verification

Putting It Together

IOS rewards familiarity. The commands documented here are not exotic — they are what network engineers type every day. But reading show ip ospf neighbor and seeing a neighbor stuck in EXSTART, knowing immediately that it is an MTU mismatch, knowing to check show interfaces on both sides for differing IP MTU values, and knowing to fix it with a single ip ospf mtu-ignore or an ip mtu alignment — that is the payoff for understanding what the output actually means rather than just knowing the syntax.

A few habits that separate engineers who wrestle with these devices from those who manage them confidently: always set explicit router-ids on OSPF and EIGRP. Always disable ip domain-lookup. Always use enable secret and service password-encryption together. Always restrict VTY lines to SSH with an access-class ACL. Always configure logging synchronous on console. Always undebug all before closing a session.

The annotated output in this reference is a starting point. Real networks produce output that deviates from the textbook. An OSPF neighbor table with ten entries where nine are FULL and one is stuck in EXSTART tells a very specific story. A routing table where the default route is pointing somewhere unexpected tells another. Learning to read those stories fluently — that is what these commands are for.

Comments