Debug Commands for Routing
Lab Objectives
- Learn how to use real-time debugging to diagnose dynamic routing problems using debug ip routing, debug ip ospf, and debug eigrp.
- Build a small multi-router topology, introduce a routing-protocol misconfiguration, and use debug and show commands to locate and fix the issue.
- Understand why debugging output appears and how it maps to routing protocol behavior in production.
Tip: Debug commands display live internal events. Use them on lab devices or during maintenance windows in production — they can be CPU-intensive on busy routers.
ASCII Topology (BASE LAB TOPOLOGY — exact IPs shown on every interface)
[Internet]
203.0.113.1
|
R1 (Gateway)
Gi0/0: 10.10.10.1
Gi0/1: 10.10.20.1
Gi0/2: 10.10.30.1
/ | \
R2 R3 R4
Gi0/0: 10.10.10.2 | Gi0/0: 10.10.30.2
Gi0/1: 10.10.40.1 |
/ \ |
S1 S2 S3
/ \ | / \
PC1 PC2 PC3 PC4 PC5
IP Scheme (for reference)
- 10.10.10.0/24 — R1-R2 link
- 10.10.20.0/24 — R1-R3 link
- 10.10.30.0/24 — R1-R4 link
- 10.10.40.0/24 — R2-S1 link
- 192.168.1.0/24 — VLAN 10 (Sales)
- 192.168.2.0/24 — VLAN 20 (Engineering)
- 192.168.3.0/24 — VLAN 30 (Management)
- 203.0.113.0/24 — Public/Internet simulation
Lab Tasks (Try It Yourself First!)
Complete these tasks WITHOUT looking at the solution below. Use
?andshowcommands to figure it out.
Task 1: Configure IP connectivity between routers
Configure the physical interface IP addresses on R1–R4 as shown in the topology. Ensure interfaces are no shutdown.
Parameters:
- R1: Gi0/0 = 10.10.10.1/24, Gi0/1 = 10.10.20.1/24, Gi0/2 = 10.10.30.1/24
- R2: Gi0/0 = 10.10.10.2/24, Gi0/1 = 10.10.40.1/24
- R3: Gi0/0 = 10.10.20.2/24
- R4: Gi0/0 = 10.10.30.2/24
Task 2: Configure routing protocols (introduce a misconfiguration)
- Configure OSPF process 1 on R1, R3, and R4 advertising their connected networks into area 0.
- Intentionally misconfigure R2 to run EIGRP autonomous system 100 advertising its networks (simulate a human error so R2 is not in OSPF).
Task 3: Diagnose and fix using debug commands
- On R1 and R2, use debugging to observe routing protocol events:
- Use debug ip ospf (or appropriate OSPF debug) on R1 to watch OSPF adjacency formation and LSDB changes.
- Use debug eigrp (or appropriate EIGRP debug) on R2 to observe EIGRP activity.
- Use debug ip routing to see route updates being installed/removed.
Think About It: If R2 and R1 are directly connected but run different routing protocols, how would routes from R2 reach R1? What would you expect to see in the routing table of R1 and why?
Lab Solution
Task 1 Solution: Configure IP connectivity between routers
What we are doing: Assign the interface IP addresses that form the point-to-point links. This establishes L3 connectivity so routing protocols can form adjacencies.
R1 configuration:
hostname R1
interface GigabitEthernet0/0
ip address 10.10.10.1 255.255.255.0
no shutdown
!
interface GigabitEthernet0/1
ip address 10.10.20.1 255.255.255.0
no shutdown
!
interface GigabitEthernet0/2
ip address 10.10.30.1 255.255.255.0
no shutdown
!
ip routing
- What the commands do:
interface .../ip address ...assigns the IP to the interface.no shutdownbrings the interface up.ip routingenables L3 switching/routing (on platforms that require it).
- Why it matters: Without IPs and administratively up interfaces, routers cannot exchange routing protocol packets (Hello, Updates) and no adjacency will form.
R2 configuration:
hostname R2
interface GigabitEthernet0/0
ip address 10.10.10.2 255.255.255.0
no shutdown
!
interface GigabitEthernet0/1
ip address 10.10.40.1 255.255.255.0
no shutdown
!
ip routing
R3 configuration:
hostname R3
interface GigabitEthernet0/0
ip address 10.10.20.2 255.255.255.0
no shutdown
!
ip routing
R4 configuration:
hostname R4
interface GigabitEthernet0/0
ip address 10.10.30.2 255.255.255.0
no shutdown
!
ip routing
Verify:
R1#show ip interface brief
Interface IP-Address OK? Method Status Protocol
GigabitEthernet0/0 10.10.10.1 YES manual up up
GigabitEthernet0/1 10.10.20.1 YES manual up up
GigabitEthernet0/2 10.10.30.1 YES manual up up
R2#show ip interface brief
Interface IP-Address OK? Method Status Protocol
GigabitEthernet0/0 10.10.10.2 YES manual up up
GigabitEthernet0/1 10.10.40.1 YES manual up up
Task 2 Solution: Configure routing protocols (introduce a misconfiguration)
What we are doing: Configure OSPF on R1, R3, R4; intentionally configure EIGRP on R2 to simulate a misconfiguration that prevents R1–R2 from exchanging OSPF routes.
R1 OSPF:
router ospf 1
network 10.10.10.0 0.0.0.255 area 0
network 10.10.20.0 0.0.0.255 area 0
network 10.10.30.0 0.0.0.255 area 0
- What it does: Starts OSPF process 1 and advertises the connected subnets into area 0.
- Why it matters: OSPF routers on shared networks will form adjacencies when they share area and network statements.
R3 OSPF:
router ospf 1
network 10.10.20.0 0.0.0.255 area 0
R4 OSPF:
router ospf 1
network 10.10.30.0 0.0.0.255 area 0
R2 (intentional misconfiguration — EIGRP instead of OSPF):
router eigrp 100
network 10.10.10.0
network 10.10.40.0
no auto-summary
- What it does: Starts EIGRP AS 100 and advertises R2's connected networks.
- Why it matters: Because R2 runs EIGRP and R1 runs OSPF, they will not form a routing adjacency; routes will not be exchanged between them. This models a common human error.
Verify:
R1#show ip protocols
Routing Protocol is "ospf 1"
Router ID 10.10.10.1
Networks:
10.10.10.0 0.0.0.255 area 0
10.10.20.0 0.0.0.255 area 0
10.10.30.0 0.0.0.255 area 0
R2#show ip protocols
Routing Protocol is "eigrp 100"
AS 100
Networks:
10.10.10.0
10.10.40.0
Task 3 Solution: Diagnose and fix using debug commands
What we are doing: Use debugging to see live routing protocol behavior and confirm the misconfiguration, then fix R2 by switching it to OSPF.
Step A — Observe OSPF on R1:
R1#debug ip ospf adj
%OSPF_DEBUG: Debugging OSPF adjacency changes enabled
- What it does: Shows OSPF adjacency events (Hello/Adjacency state changes).
- Why it matters: You will not see adjacency formation attempts with R2 because R2 runs EIGRP. This confirms the mismatch.
Verification:
R1#show ip ospf neighbor
% No OSPF neighbors found
Expected output explanation: No OSPF neighbors on the 10.10.10.0 link — indicates R1 has no OSPF neighbor there.
Step B — Observe EIGRP activity on R2:
R2#debug eigrp packets
% EIGRP: Debugging EIGRP packets enabled
- What it does: Displays EIGRP packet processing (Hello, Updates).
- Why it matters: Shows R2 is sending/receiving EIGRP packets but R1 will not respond because R1 does not run EIGRP.
Verification:
R2#show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(100)
H Address Interface Hold Uptime SRTT RTO Q Seq
0 10.10.10.1 Gi0/0 11 00:02:10 40 100 0 0
Expected output explanation: R2 may show no neighbor (if R1 does not run EIGRP) or transient packets — the debug output will show EIGRP Hellos going unanswered.
Step C — Use debug ip routing on R1 to see routing table changes:
R1#debug ip routing
% IP_RTE: Debugging IP route events enabled
- What it does: Shows routes being added/removed from the routing table.
- Why it matters: Confirms that routes from 10.10.40.0 (behind R2) are not being installed on R1.
Verification:
R1#show ip route
Codes: C - connected, O - OSPF, S - static
C 10.10.10.0/24 is directly connected, GigabitEthernet0/0
C 10.10.20.0/24 is directly connected, GigabitEthernet0/1
C 10.10.30.0/24 is directly connected, GigabitEthernet0/2
O 10.10.20.0/24 [110/2] via 10.10.20.2, GigabitEthernet0/1
O 10.10.30.0/24 [110/2] via 10.10.30.2, GigabitEthernet0/2
Expected output explanation: No route to 10.10.40.0 — demonstrates missing routes because of protocol mismatch.
Step D — Fix the misconfiguration on R2: remove EIGRP and enable OSPF area 0
R2#no router eigrp 100
R2#router ospf 1
R2# network 10.10.10.0 0.0.0.255 area 0
R2# network 10.10.40.0 0.0.0.255 area 0
- What it does: Stops EIGRP and starts OSPF advertising R2's networks.
- Why it matters: Now R1 and R2 run the same routing protocol and can form an adjacency and exchange routes.
Verification after fix:
R1#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
10.10.10.2 1 FULL/BDR 00:00:36 10.10.10.2 GigabitEthernet0/0
R1#show ip route
Codes: C - connected, O - OSPF
C 10.10.10.0/24 is directly connected, GigabitEthernet0/0
O 10.10.40.0/24 [110/20] via 10.10.10.2, GigabitEthernet0/0
Expected outputs show an OSPF adjacency and the learned route to 10.10.40.0 now in R1's routing table.
Warning: Always disable debugging after you finish:
no debug all
undebug all
Troubleshooting Scenario
Scenario: R1 cannot reach 10.10.40.0 (hosts behind R2)
Symptom: Ping from R1 to 10.10.40.1 times out.
Your task: Find and fix the issue.
Hint: Look for routing protocol mismatch on the shared link.
Solution: Use show ip protocols to see active protocols; use debug ip ospf adj on R1 and debug eigrp packets on R2 to confirm protocol traffic; convert R2 to OSPF as shown in Task 3 Step D. After converting, verify adjacency and routes with show ip ospf neighbor and show ip route.
Verification Checklist
- All interfaces have the correct IP addresses and are up.
- OSPF adjacency exists between routers that should peer.
- The route to 10.10.40.0 is present in R1's routing table.
Common Mistakes
| Symptom | Cause | Fix |
|---|---|---|
| No OSPF neighbor on a shared link | One router runs a different routing protocol (e.g., EIGRP) | Check show ip protocols and configure the same protocol and area on both ends |
| Route to remote subnet not in routing table | No adjacency or missing network statement | Use show ip ospf neighbor and show ip route; verify network statements include the interface subnet |
| Debug output is noisy or causes high CPU | Debugging left enabled on production devices | Run undebug all / no debug all and use debug selectively during maintenance windows |
Challenge Task
Configure R1–R4 to form OSPF area 0 as in the lab, then intentionally introduce route filtering on R3 so it does not advertise 10.10.20.0 to R1. Your goal: use debug and show commands to find where the route is being filtered and restore full connectivity. (No step-by-step provided — discover access-lists or distribute-list usage yourself.)
Key Takeaway: Debug commands are a live window into protocol operation — use them to confirm your assumptions (adjacency formation, hello intervals, LSDB changes). In production, prefer targeted debug and use show commands first to avoid unnecessary load.