Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
The best troubleshooting tools are show and debug commands, specifically show ip protocols
and various routing protocol debugging commands. Let’s take a look.
First, the show ip protocols command will show you the routing protocols configured on
your router. Hopefully you have only one. Here is an example:
Router#sh ip protocols
Routing Protocol is "rip"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Sending updates every 30 seconds, next due in 27 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
Redistributing: rip
Default version control: send version 2, receive version 2
Interface Send Recv Triggered RIP Key-chain
FastEthernet0/1 2 2
Serial0/0/1 2 2
Automatic network summarization is not in effect
Maximum path: 4
Routing for Networks:
10.0.0.0
Passive Interface(s):
FastEthernet0/0
Serial0/0/0
Routing Information Sources:
Gateway Distance Last Update
10.1.11.2 120 00:00:00
10.1.5.1 120 00:00:02
Distance: (default is 120)
The above router output shows the router is running RIPv2, the interfaces participating in
the routing process, the next hop gateways (neighbors) and the administrative distance. Also,
you can see that the maximum path is 4, which means that RIP will load-balance across four
equal cost links by default.
There are dozens of debugging commands you can use, and for RIP, the debug ip rip
command is the best tool for debugging RIP routing.
*Mar 17 19:34:00.123: RIP: sending v2 update to 224.0.0.9 via
Serial0/0/1 (10.1.5.2)
*Mar 17 19:34:00.123: RIP: build update entries
*Mar 17 19:34:00.123: 10.1.10.0/24 via 0.0.0.0, metric 1, tag 0
268 Chapter 4 Configure, verify, and troubleshoot basic router operation
*Mar 17 19:34:00.123: 10.1.11.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 17 19:34:00.123: 10.1.12.0/24 via 0.0.0.0, metric 2, tag 0col
*Mar 17 19:34:03.795: RIP: received v2 update from 10.1.5.1 on
Serial0/0/1
The above debug output shows we are running RIPv2, with multicast address 224.0.0.9.
For EIGRP I am going to show you two commands. The debug eigrp packet command
and the debug ip eigrp notification command:
Router#debug eigrp packet
EIGRP Packets debugging is on
(UPDATE, REQUEST, QUERY, REPLY, HELLO, IPXSAP, PROBE, ACK, STUB,
SIAQUERY, SIAREPLY)
*Mar 21 23:17:35.050: EIGRP: Sending HELLO on FastEthernet0/1
*Mar 21 23:17:35.050: AS 10, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
*Mar 21 23:17:35.270: EIGRP: Received HELLO on Serial0/1/0 nbr 10.1.4.2
*Mar 21 23:17:35.270: AS 10, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ
un/rely 0/0 peerQ un/rely 0/0
*Mar 21 23:17:35.294: EIGRP: Received HELLO on Serial0/0/0 nbr 10.1.2.2
*Mar 21 23:17:35.294: AS 10, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ
un/rely 0/0 peerQ un/rely 0/0
*Mar 21 23:17:38.014: EIGRP: Received HELLO on Serial0/2/0 nbr 10.1.5.2
*Mar 21 23:17:38.014: AS 10, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ
un/rely 0/0 peerQ un/rely 0/0
The EIGRP 224.0.0.10 multicast is sent out every five seconds, and the Hello packets are
sent out of every active interface, as well as all the interfaces that we have neighbors connected
to. Did you notice the AS number is provided in the update? This is because if a neighbor
doesn’t have the same AS number, the Hello update would just be discarded.
The debug ip eigrp notification command (called debug ip eigrp events on pre
12.4 routers) shouldn’t show you anything at all! That’s right—the only time you’ll see output
from this command is if there’s a problem on your network, or you’ve added or deleted a network
from a router in your internetwork. Since I have a problem-free network, I’m going to
shut down an interface on my router in order to see some output:
Router(config)#int f0/1
Router(config-if)#shut
*Mar 21 23:25:43.506: IP-EIGRP(Default-IP-Routing-Table:10): Callback:
route_adjust FastEthernet0/1
*Mar 21 23:25:43.506: IP-EIGRP: Callback: ignored connected AS 0 10.1.1.0/24
*Mar 21 23:25:43.506: into: eigrp AS 10
*Mar 21 23:25:43.506: IP-EIGRP(Default-IP-Routing-Table:10): Callback:
callbackup_routes 10.1.1.0/24
Corp(config-if)#n
4.15 Troubleshoot routing issues 269
*Mar 21 23:25:45.506: %LINK-5-CHANGED: Interface FastEthernet0/1,
changed state to administratively down
*Mar 21 23:25:46.506: %LINEPROTO-5-UPDOWN: Line protocol on Interface
FastEthernet0/1, changed state to down
Router(config-if)#no shut
Router(config-if)#^Z
*Mar 21 23:25:49.570: %LINK-3-UPDOWN: Interface FastEthernet0/1,
changed state to up
*Mar 21 23:25:49.570: IP-EIGRP(Default-IP-Routing-Table:10): Callback:
lostroute 10.1.1.0/24
*Mar 21 23:25:49.570: IP-EIGRP(Default-IP-Routing-Table:0): Callback:
redist connected (config change) FastEthernet0/1
*Mar 21 23:25:49.570: IP-EIGRP(Default-IP-Routing-Table:0): Callback:
redist connected (config change) Serial0/0/0
*Mar 21 23:25:49.570: IP-EIGRP(Default-IP-Routing-Table:0): Callback:
redist connected (config change) Serial0/0/1
*Mar 21 23:25:49.570: IP-EIGRP(Default-IP-Routing-Table:0): Callback:
redist connected (config change) Serial0/1/0
*Mar 21 23:25:49.570: IP-EIGRP(Default-IP-Routing-Table:0): Callback:
redist connected (config change) Serial0/2/0
*Mar 21 23:25:49.570: IP-EIGRP(Default-IP-Routing-Table:10): Callback:
route_adjust FastEthernet0/1
Debugging is a great tool for any protocol, so let’s take a look in Table 4.11 at a few debugging
commands for troubleshooting OSPF.
I’ll start by showing you the output from the router I have, using the debug ip ospf
packet command:
Router#debug ip ospf packet
OSPF packet debugging is on
TABLE 4 . 1 1 Table 411: Debugging Commands for Troubleshooting OSPF
Command Description/Function
debug ip ospf packet Shows Hello packets being sent and received on your router.
debug ip ospf hello Shows Hello packets being sent and received on your router.
Shows more detail than the debug ip ospf packet output.
debug ip ospf adj Shows DR and DBR elections on a broadcast and nonbroadcast
multi-access network.
270 Chapter 4 Configure, verify, and troubleshoot basic router operation
*Mar 23 01:20:42.199: OSPF: rcv. v:2 t:1 l:48 rid:172.16.10.3
aid:0.0.0.0 chk:8075 aut:0 auk: from Serial0/1/0
*Mar 23 01:20:45.507: OSPF: rcv. v:2 t:1 l:48 rid:172.16.10.2
aid:0.0.0.0 chk:8076 aut:0 auk: from Serial0/0/0
*Mar 23 01:20:45.531: OSPF: rcv. v:2 t:1 l:48 rid:172.16.10.2
aid:0.0.0.0 chk:8076 aut:0 auk: from Serial0/0/1
*Mar 23 01:20:45.531: OSPF: rcv. v:2 t:1 l:48 rid:172.16.10.4
aid:0.0.0.0 chk:8074 aut:0 auk: from Serial0/2/0
*Mar 23 01:20:52.199: OSPF: rcv. v:2 t:1 l:48 rid:172.16.10.3
aid:0.0.0.0 chk:8075 aut:0 auk: from Serial0/1/0
*Mar 23 01:20:55.507: OSPF: rcv. v:2 t:1 l:48 rid:172.16.10.2
aid:0.0.0.0 chk:8076 aut:0 auk: from Serial0/0/0
In the above output, you can see that the router is both sending and receiving Hello packets
every 10 seconds from neighbor (adjacent) routers. The next command will provide the same
information, but with more detail. For example, you can see the multicast address used
(224.0.0.5) and the area:
Router#debug ip ospf hello
*Mar 23 01:18:41.103: OSPF: Send hello to 224.0.0.5 area 0 on
Serial0/1/0 from 10.1.4.1
*Mar 23 01:18:41.607: OSPF: Send hello to 224.0.0.5 area 0 on
FastEthernet0/1 from 10.1.1.1
*Mar 23 01:18:41.607: OSPF: Send hello to 224.0.0.5 area 0 on
Serial0/0/0 from 10.1.2.1
*Mar 23 01:18:41.611: OSPF: Send hello to 224.0.0.5 area 0 on
Serial0/2/0 from 10.1.5.1
*Mar 23 01:18:41.611: OSPF: Send hello to 224.0.0.5 area 0 on
Serial0/0/1 from 10.1.3.1
*Mar 23 01:18:42.199: OSPF: Rcv hello from 172.16.10.3 area 0 from
Serial0/1/0 10.1.4.2
*Mar 23 01:18:42.199: OSPF: End of hello processing
*Mar 23 01:18:45.519: OSPF: Rcv hello from 172.16.10.2 area 0 from
Serial0/0/0 10.1.2.2
*Mar 23 01:18:45.519: OSPF: End of hello processing
The last debug command I’m going show you is the debug ip ospf adj command that
will show us elections as they occur on broadcast and nonbroadcast multi-access networks:
Router#debug ip ospf adj
OSPF adjacency events debugging is on
*Mar 23 01:24:34.823: OSPF: Interface FastEthernet0/1 going Down
*Mar 23 01:24:34.823: OSPF: 172.16.10.1 address 10.1.1.1 on
FastEthernet0/1 is dead, state DOWN
4.16 Verify router hardware and software operation using the SHOW and DEBUG 271
*Mar 23 01:24:34.823: OSPF: Neighbor change Event on interface
FastEthernet0/1
*Mar 23 01:24:34.823: OSPF: DR/BDR election on FastEthernet0/1
*Mar 23 01:24:34.823: OSPF: Elect BDR 0.0.0.0
*Mar 23 01:24:34.823: OSPF: Elect DR 0.0.0.0
*Mar 23 01:24:34.823: OSPF: Elect BDR 0.0.0.0
*Mar 23 01:24:34.823: OSPF: Elect DR 0.0.0.0
*Mar 23 01:24:34.823: DR: none BDR: none
*Mar 23 01:24:34.823: OSPF: Flush network LSA immediately
*Mar 23 01:24:34.823: OSPF: Remember old DR 172.16.10.1 (id)
*Mar 23 01:24:35.323: OSPF: We are not DR to build Net Lsa for
interface FastEthernet0/1
*Mar 23 01:24:35.323: OSPF: Build router LSA for area 0, router ID
172.16.10.1, seq 0x80000006
*Mar 23 01:24:35.347: OSPF: Rcv LS UPD from 172.16.10.2 on Serial0/0/1
length 148 LSA count 1
*Mar 23 01:24:40.703: OSPF: Interface FastEthernet0/1 going Up
*Mar 23 01:24:41.203: OSPF: Build router LSA for area 0, router ID
172.16.10.1, seq 0x80000007
*Mar 23 01:24:41.231: OSPF: Rcv LS UPD from 172.16.10.2 on Serial0/0/1
length 160 LSA count 1
Exam Objectives
Remember what the command debug ip ospf packet provides to you Shows Hello packets
being sent and received on your router.
Remember what the command debug ip ospf hello provides to you Shows Hello packets being
sent and received on your router. Shows more detail than the debug ip ospf packet output.
Remember what the command debug ip ospf adj provides to you Shows DR and DBR
elections on a broadcast and nonbroadcast multi-access network.
No comments:
Post a Comment