Cisco CCNA And CCNP Training: Five Debugs You Must Know
By Chris Bryant, CCIE #12933
There's a reason that I push CCNA and CCNP candidates to learn and use debug and show commands during their studies. Using these commands is the only way that you actually see what's going on when you enter a command! Otherwise, you're just typing and hoping things work. The problem is, they don't always work. :) And when things go wrong, you've got to know how to diagnose the problem - and the only way to do that is with debug and show commands.
The truly prepared Cisco exam candidate will take this one step further, and run these commands when everything is running correctly. Why? Look at it this way - if you don't know what debug and show command output looks like when the network's running properly, how will you know what's different when you run them during a crisis?
A reminder, as always - don't run a debug unless you know what the result is going to be. By default, debug operations get first priority when it comes to router resources, and running a CPU-intensive debug such as debug ip packet in a production network can actually lock up the router. Don't practice debugs on a production network - practice them at home.
Let's take a look at a few important debugs that every CCNA and CCNP should know how to use.
When it comes to RIP, debug ip rip is the primary debug to use. This debug will show you the contents of the routing update packets, and is vital in diagnosing RIP version mismatches and routing update authentication issues. In the following example, debug ip rip shows us that authentication is in use, it's clear-text authentication, and you can even see the routes being advertised along with their metrics.
3d04h: RIP: received packet with text authentication cisco
3d04h: RIP: received v2 update from 150.1.1.3 on Ethernet0
3d04h: 100.0.0.0/8 via 0.0.0.0 in 1 hops
3d04h: 150.1.2.0/24 via 0.0.0.0 in 1 hops
You know how to use the variance command to configure unequal-cost load-sharing with IGRP, but IGRP has no topology table that will give you the feasible successor metrics you need. With IGRP, you need to use the debug ip igrp transactions command to get these vital metrics. Below, you'll see typical readout from this debug. The metrics needed to properly calculate the variance command are found in this debug.
R1#debug ip igrp transactions
IGRP protocol debugging is on
19:17:51: IGRP: broadcasting request on Loopback0
19:17:51: IGRP: broadcasting request on Serial0
19:17:51: IGRP: broadcasting request on Serial1
19:17:51: IGRP: received update from 172.12.13.3 on Serial1
19:17:51: subnet 172.12.13.0, metric 23531 (neighbor 21531)
19:17:51: subnet 172.12.123.0, metric 23531 (neighbor 8476)
19:17:51: network 1.0.0.0, metric 24031 (neighbor 8976)
19:17:51: network 2.0.0.0, metric 22131 (neighbor 1600)
19:17:51: network 3.0.0.0, metric 22031 (neighbor 501)
19:17:51: network 172.23.0.0, metric 21631 (neighbor 1100)
Several factors are considered by OSPF-enabled routers when it comes to forming adjacencies, including hello and dead timer settings. If an adjacency doesn't form when you think it should, run debug ip ospf adj. The reason the adjacency isn't forming is usually seen quickly with this command's output. Below, debug ip ospf adj shows us that the Hello and Dead timers are mismatched, which will prevent an adjacency from forming.
R1#debug ip ospf adj
OSPF adjacency events debugging is on
2d03h: OSPF: Rcv hello from 3.3.3.3 area 0 from Serial0 172.12.123.3
2d03h: OSPF: Mismatched hello parameters from 172.12.123.3
2d03h: Dead R 40 C 120, Hello R 10 C 30 Mask R 255.255.255.0 C 255.255.255.0
Let's not ignore Layer Two! If frame relay mappings are not forming according to your configuration, run debug frame lmi. This debug will allow you to quickly diagnose and correct any LMI mismatches. The following debug frame lmi output shows us that the myseq value is incrementing while yourseen remains at zero, indicating a likely LMI type mismatch.
R1#debug frame lmi
Frame Relay LMI debugging is on
Displaying all Frame Relay LMI data
00:52:12: Serial0(out): StEnq, myseq 31, yourseen 0, DTE down
00:52:12: datagramstart = 0xE0183C, datagramsize = 14
00:52:12: FR encap = 0x00010308
00:52:12: 00 75 95 01 01 00 03 02 1F 00
00:52:12:
00:52:22: Serial0(out): StEnq, myseq 32, yourseen 0, DTE down
00:52:22: datagramstart = 0xE0183C, datagramsize = 14
00:52:22: FR encap = 0x00010308
00:52:22: 00 75 95 01 01 00 03 02 20 00
00:52:22:
00:52:32: Serial0(out): StEnq, myseq 33, yourseen 0, DTE down
00:52:32: datagramstart = 0xE0183C, datagramsize = 14
00:52:32: FR encap = 0x00010308
00:52:32: 00 75 95 01 01 00 03 02 21 00
When it comes to PPP, it can be very frustrating to try to spot a problem with a password or username. Instead of staring at the configuration for 10 minutes, run debug ppp negotiation and send a ping over the link. This command will help you spot the router with the misconfigured username or password, not to mention saving you a lot of time!
Here is the debug of a successful PPP negotiation. If there is a problem with the negotiation, you'll see it within the challenges and responses. That will give you a good idea of which router is misconfigured.
R2#debug ppp negotiation
PPP protocol negotiation debugging is on
R2#ping 172.12.21.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.12.21.1, timeout is 2 seconds:
04:01:30: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
04:01:30: BR0:1 PPP: Using dialer call direction
04:01:30: BR0:1 PPP: Treating connection as a callout
04:01:30: BR0:1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 0 load]
04:01:30: BR0:1 LCP: O CONFREQ [Closed] id 1 len 15
04:01:30: BR0:1 LCP: AuthProto CHAP (0x0305C22305)
04:01:30: BR0:1 LCP: MagicNumber 0x1158551A (0x05061158551A)
04:01:30: BR0:1 LCP: I CONFREQ [REQsent] id 1 len 15
04:01:30: BR0:1 LCP: AuthProto CHAP (0x0305C22305)
04:01:30: BR0:1 LCP: MagicNumber 0x1158F056 (0x05061158F056)
04:01:30: BR0:1 LCP: O CONFACK [REQsent] id 1 len 15
04:01:30: BR0:1 LCP: AuthProto CHAP (0x0305C22305)
04:01:30: BR0:1 LCP: MagicNumber 0x1158F056 (0x05061158F056)
04:01:30: BR0:1 LCP: I CONFACK [ACKsent] id 1 len 15
04:01:30: BR0:1 LCP: AuthProto CHAP (0x0305C22305)
04:01:30: BR0:1 LCP: MagicNumber 0x1158551A (0x05061158551A)
04:01:30: BR0:1 LCP: State is Open
04:01:30: BR0:1 PPP: P.!hase is AUTHENTICATING, by both [0 sess, 0 load]
04:01:30: BR0:1 CHAP: O CHALLENGE id 1 len 23 from "R2"
04:01:30: BR0:1 CHAP: I CHALLENGE id 1 len 23 from "R1"
04:01:30: BR0:1 CHAP: O RESPONSE id 1 len 23 from "R2"
04:01:30: BR0:1 CHAP: I SUCCESS id 1 len 4
04:01:30: BR0:1 CHAP: I RESPONSE id 1 len 23 from "R1"
04:01:30: BR0:1 CHAP: O SUCCESS id 1 len 4
04:01:30: BR0:1 PPP: Phase is UP [0 sess, 0 load]
04:01:30: BR0:1 IPCP: O CONFREQ [Closed] id 1 len 10
04:01:30: BR0:1 IPCP: Address 172.12.21.2 (0x0306AC0C1502)
04:01:30: BR0:1 CDPCP: O CONFREQ [Closed] id 1 len 4
04:01:30: BR0:1 IPCP: I CONFREQ [REQsent] id 1 len 10
04:01:30: BR0:1 IPCP: Address 172.12.21.1 (0x0306AC0C1501)
04:01:30: BR0:1 IPCP: O CONFACK [REQsent] id 1 len 10
04:01:30: BR0:1 IPCP: Address 172.12.21.1 (0x0306AC0C1501)
04:01:30: BR0:1 CDPCP: I CONFREQ [REQsent] id 1 len 4
04:01:30: BR0:1 CDPCP: O CONFACK [REQsent] id 1 len 4
04:01:30: BR0:1 IPCP: I CONFACK [ACKsent] id 1 len 10
04:01:30: BR0:1 IPCP: Addr!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 36/49/88 ms
R2#ess 172.12.21.2 (0x0306AC0C1502)
04:01:30: BR0:1 IPCP: State is Open
04:01:30: BR0:1 CDPCP: I CONFACK [ACKsent] id 1 len 4
04:01:30: BR0:1 CDPCP: State is Open
04:01:30: BR0 IPCP: Install route to 172.12.21.1
04:01:31: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to up
R2#
04:01:36: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 5551111 R1
Effectively using debugs during your CCNA and CCNP exam study will help you truly understand what's going on "behind the command" - and it will really come in handy on that day when your production network just isn't doing what you (think) you told it to do!
To your success,
Chris Bryant
CCIE #12933
chris@thebryantadvantage.com
|
