Ideally, you should use Figure 10-1 as a physical starting point, discover the network on your own, and update your drawing accordingly. To make this a true discovery lab, you should have someone else do the cabling and load the preconfigured files for you. They are in the file called tt1 layer 2 configuration. Alternatively, erase all the configurations yourself, power the devices down, and wire the new scenario as in Figure 10-2. Then you can paste in the configurations from the file provided (or configure, if you prefer).
Have the person setting up the lab use Figure 10-2 as a guide to build and configure Layer 1 and Layer 2. If you are discovering everything for yourself, I expect you to draw a diagram similar to Figure 10-2 rather than just look at mine.
NOTE
Give yourself the benefit of breaking and fixing things. Do not just paste in my troubled files, and then turn around and paste in my fixed files. Instead, use my troubled files to break things. Use the methodology, tools, and resources covered throughout the book and in your practical experiences to “spot the issues” and then fix them.
After you have discovered (or configured) and tested the lower layers, use Figure 10-3 to configure the IP addressing, hosts files, and routing protocols. Alternatively, paste the configurations in from the tt1 layer 3 configuration file. In this Trouble Ticket, configure anything that is missing on your devices to ensure end-to-end connectivity as in Figure 10-2. Don't forget to configure your hosts.
Test and fix any minor issues and move directly into the documentation lab. Compare your final configurations to the output in the “Trouble Ticket 10-1 Discovery Lab Solution” section and the tt1 layer 3 testing and tt1 final configs files.
NOTE
More so than the other chapters, you must thoroughly review the figures, examples, and configuration files provided to gain practical experience from this chapter. Even if you don't have the equipment handy, you can walk through the chapter and supporting documentation as if you did. If you think you are just at that comfortable level, do the labs anyway! You may still learn something.
Make sure you have a working configuration and take time to update your documents and tables to assist with troubleshooting later. No access lists or filters are in place at the present time, and all passwords that are configured should be broadcreek. Simple ping and trace tests via your hosts tables are sufficient at this point.
At a minimum you should have discovered the topology like that in Figure 10-2 and 10-3. In a practical environment, you should use a program that automatically discovers the devices and keeps track of changes for you, too. I am thinking of network management programs such as CiscoWorks, HP OpenView, Cisco Info Center (CIC), Visio 2000, and so on.
The device names are not just r1, r2, r3, and so on. Instead, I wanted to remind you to take the naming of devices a little more seriously in a practical environment. Having a plan for naming and addressing is important and makes it easier for you to spot things that are out of the ordinary. After working through the solution, use Trouble Ticket 2 as a reminder that you need to document your new topology.
Remember that the troubleshooting targets at the lower layers are interfaces and controllers. I assume that in your baseline you verified and documented items such as model number, serial number, RAM/Flash memory, IOS version, configuration register settings, bandwidth/speed, clocking, encapsulation, duplex, descriptions, addresses, passwords, spanning-tree portfast, VLANs, and the like. Other things that are valuable to document in practical application include the detailed location of equipment down to the wiring closet, rack, and position.
The shaded output in Examples 10-1 through 10-3 are the types of things you should have discovered and recorded on your drawing or table for the Layer 2 baseline. To support Cisco you need to adjust the commands slightly according to the CatOS or IOS command sets. Example 10-1 illustrates the types of things to look for on your routers. Much of my output has been omitted from the printed text but is included in the sample files. However, you should include everything in your baseline. For the ISDN and Frame Relay devices, refer back to those chapters for information about commands such as show frame map, show frame lmi, show isdn status, and so on. I concentrate more on them in Trouble Ticket 5.
duck>show version Cisco Internetwork Operating System Software IOS (tm) 2500 Software (C2500-JS-L), Version 12.0(21a), RELEASE SOFTWARE (fc1) Copyright 1986-2002 by cisco Systems, Inc. Compiled Sat 02-Feb-02 02:08 by nmasa Image text-base: 0x030520E0, data-base: 0x00001000 ROM: System Bootstrap, Version 5.2(8a), RELEASE SOFTWARE BOOTFLASH: 3000 Bootstrap Software (IGS-RXBOOT), Version 10.2(8a), RELEASE SOFTWARE (fc1) duck uptime is 7 hours, 34 minutes System restarted by power-on System image file is "flash:c2500-js-l.120-21a.bin" cisco 2500 (68030) processor (revision L) with 14336K/2048K bytes of memory. Processor board ID 03074719, with hardware revision 00000000 Bridging software. X.25 software, Version 3.0.0. SuperLAT software (copyright 1990 by Meridian Technology Corp). TN3270 Emulation software. 2 Ethernet/IEEE 802.3 interface(s) 2 Serial network interface(s) 32K bytes of non-volatile configuration memory. 16384K bytes of processor board System flash (Read ONLY) Configuration register is 0x2102 duck>show flash System flash directory: File Length Name/status 1 10253564 c2500-js-l.120-21a.bin [10253628 bytes used, 6523588 available, 16777216 total] 16384K bytes of processor board System flash (Read ONLY) duck>show interfaces Ethernet0 is up, line protocol is up Hardware is Lance, address is 0000.0c8d.6705 (bia 0000.0c8d.6705) Description: duck to chesapeakebay backbone MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 255/255, load 1/255 Encapsulation ARPA, loopback not set, keepalive set (10 sec) ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:13, output 00:00:03, output hang never Last clearing of "show interface" counters never Queueing strategy: fifo Output queue 0/40, 0 drops; input queue 0/75, 0 drops 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 1060 packets input, 119692 bytes, 0 no buffer Received 1060 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 0 input packets with dribble condition detected 2098 packets output, 194947 bytes, 0 underruns 0 output errors, 0 collisions, 15 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier 0 output buffer failures, 0 output buffers swapped out Ethernet1 is administratively down, line protocol is down Hardware is Lance, address is 0000.0c8d.6706 (bia 0000.0c8d.6706) MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 252/255, load 1/255 Encapsulation ARPA, loopback not set, keepalive set (10 sec) ARP type: ARPA, ARP Timeout 04:00:00 ... Serial0 is up, line protocol is up Hardware is HD64570 Description: duck to goose MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255 Encapsulation HDLC, loopback not set, keepalive set (10 sec) Last input 00:00:05, output 00:00:05, output hang never Last clearing of "show interface" counters never ... Serial1 is up, line protocol is up Hardware is HD64570 Description: duck to swan MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255 Encapsulation HDLC, loopback not set, keepalive set (10 sec) Last input 00:00:02, output 00:00:09, output hang never Last clearing of "show interface" counters never ... !!!check your interfaces if they do not match the output !!!problems mean physical or data link issues at this point !!!fix any controller or interface issues on all devices before you continue duck>enable Password: duck#clear counters Clear "show interface" counters on all interfaces [confirm] duck#show ip interface brief Interface IP-Address OK? Method Status Protocol Ethernet0 unassigned YES unset up up Ethernet1 unassigned YES unset administratively down down Serial0 unassigned YES unset up up Serial1 unassigned YES unset up up duck#show cdp neighbor detail ------------------------- Device ID: swan Entry address(es): Platform: cisco 2520, Capabilities: Router Interface: Serial1, Port ID (outgoing port): Serial1 Holdtime : 173 sec Version : Cisco Internetwork Operating System Software IOS (tm) 2500 Software (C2500-JS-L), Version 12.0(9), RELEASE SOFTWARE (fc1) Copyright 1986-2000 by cisco Systems, Inc. Compiled Mon 24-Jan-00 22:30 by bettyl ------------------------- Device ID: 005352782(chesapeakebay) Entry address(es): IP address: 10.10.10.45 Platform: WS-C2900, Capabilities: Trans-Bridge Switch Interface: Ethernet0, Port ID (outgoing port): 2/12 Holdtime : 170 sec Version : WS-C2900 Software, Version McpSW: 4.4(1) NmpSW: 4.4(1) Copyright 1995-1999 by Cisco Systems ------------------------- Device ID: goose Entry address(es): Platform: cisco 3640, Capabilities: Router Interface: Serial0, Port ID (outgoing port): Serial0/0 Holdtime : 176 sec Version : Cisco Internetwork Operating System Software IOS (tm) 3600 Software (C3640-JS-M), Version 12.0(13), RELEASE SOFTWARE (fc1) Copyright 1986-2000 by cisco Systems, Inc. Compiled Tue 05-Sep-00 21:39 by linda duck#show cdp neighbors Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge S - Switch, H - Host, I - IGMP, r - Repeater Device ID Local Intrfce Holdtme Capability Platform Port ID swan Ser 1 165 R 2520 Ser 1 005352782(chesapeakeEth 0 163 T S WS-C2900 2/12 goose Ser 0 171 R 3640 Ser 0/0 |
If your output differs from that in Example 10-1, go back and examine the Physical and Data Link Layers. For example, check link lights, controllers and clock, speed and duplex, encapsulation mismatches, interface issues, cables, and so on. Example 10-2 illustrates what to look for on your CatOS-based switch to assist with building your Layer 1 and Layer 2 baseline.
chesapeakebay>show version WS-C2900 Software, Version McpSW: 4.4(1) NmpSW: 4.4(1) Copyright 1995-1999 by Cisco Systems NMP S/W compiled on Jan 6 1999, 18:05:22 MCP S/W compiled on Jan 06 1999, 17:50:33 System Bootstrap Version: 2.2(2) Hardware Version: 2.3 Model: WS-C2900 Serial #: 005352782 Mod Port Model Serial # Versions --- ---- ---------- --------- ---------------------------------------- 1 2 WS-X2900 005352782 Hw : 2.3 Fw : 2.2(2) Fw1: 2.2(1) Sw : 4.4(1) 2 12 WS-X2901 008675483 Hw : 1.4 Fw : 3.1(1) Sw : 4.4(1) DRAM FLASH NVRAM Module Total Used Free Total Used Free Total Used Free ------ ------- ------- ------- ------- ------- ------- ----- ----- ----- 1 20480K 9972K 10508K 4096K 3584K 512K 256K 112K 144K Uptime is 0 day, 7 hours, 37 minutes chesapeakebay>show interface sl0: flags=51<UP,POINTOPOINT,RUNNING> slip 0.0.0.0 dest 0.0.0.0 sc0: flags=63<UP,BROADCAST,RUNNING> vlan 1 inet 10.10.10.45 netmask 255.255.255.0 broadcast 10.10.10.255 chesapeakebay>show port Port Name Status Vlan Level Duplex Speed Type ----- ------------------ ---------- ---------- ------ ------ ----- ------------ 1/1 notconnect 1 normal half 100 100BaseTX 1/2 notconnect 1 normal half 100 100BaseTX 2/1 notconnect 1 normal auto auto 10/100BaseTX ... 2/10 connected 1 normal a-half a-10 10/100BaseTX 2/11 to heron connected 1 normal a-half a-10 10/100BaseTX 2/12 to duck connected 1 normal a-half a-10 10/100BaseTX ... chesapeakebay> enable Enter password: chesapeakebay> (enable)set port name 2/10 to hub Port 2/10 name set. chesapeakebay> (enable)show port capabilities Model WS-X2900 Port 1/1 Type 100BaseTX Speed 100 Duplex half,full Trunk encap type ISL Trunk mode on,off,desirable,auto,nonegotiate Channel no Broadcast suppression no Flow control no Security yes Membership static,dynamic Fast start yes Rewrite no ... -------------------------------------------------------------- Model WS-X2901 Port 2/10 Type 10/100BaseTX Speed auto,10,100 Duplex half,full Trunk encap type ISL Trunk mode on,off,desirable,auto,nonegotiate Channel no Broadcast suppression pps(0-150000) Flow control no Security yes Membership static,dynamic Fast start yes Rewrite no -------------------------------------------------------------- chesapeakebay> (enable)show cdp neighbor detail Device-ID: 804 Device Addresses: IP Address: 10.10.10.40 Holdtime: 152 sec Capabilities: ROUTER Version: Cisco Internetwork Operating System Software IOS (tm) C800 Software (C800-G3-MW), Version 12.0(1)XB1, RELEASE SOFTWARE (fc1) TAC:Home:SW:IOS:Specials for info Copyright 1986-1998 by cisco Systems, Inc. Platform: Cisco C804 Port-ID (Port on Device): Ethernet0 Port (Our Port): 2/10 ___________________________________________________________________________ Device-ID: duck Device Addresses: Holdtime: 153 sec Capabilities: ROUTER Version: Cisco Internetwork Operating System Software IOS (tm) 2500 Software (C2500-JS-L), Version 12.0(21a), RELEASE SOFTWARE (fc1) Copyright 1986-2002 by cisco Systems, Inc. Platform: cisco 2500 Port-ID (Port on Device): Ethernet0 Port (Our Port): 2/12 ___________________________________________________________________________ Device-ID: heron Device Addresses: Holdtime: 124 sec Capabilities: ROUTER Version: Cisco Internetwork Operating System Software IOS (tm) 2500 Software (C2500-JS-L), Version 12.0(21a), RELEASE SOFTWARE (fc1) Copyright 1986-2002 by cisco Systems, Inc. Platform: cisco 2500 Port-ID (Port on Device): Ethernet0 Port (Our Port): 2/11 chesapeakebay> (enable)show cdp neighbors Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge S - Switch, H - Host, I - IGMP, r - Repeater Port Device-ID Port-ID Platform Capability -------- ----------------------- ----------------- ------------------ ---------- 2/10 804 Ethernet0 Cisco C804 R 2/11 duck Ethernet0 cisco 2500 R 2/12 heron Ethernet0 cisco 2500 R chesapeakebay> (enable)show cam dynamic * = Static Entry. + = Permanent Entry. # = System Entry. R = Router Entry. X = Port Security Entry VLAN Dest MAC/Route Des Destination Ports or VCs / [Protocol Type] ---- ------------------ ---------------------------------------------------- 1 00-00-0c-38-a0-5d 2/11 [ALL] 1 00-00-0c-8d-67-05 2/12 [ALL] 1 00-50-73-07-d0-76 2/10 [ALL] Total Matching CAM Entries Displayed = 3 |
NOTE
Some differences exist between the CatOS and Cisco IOS. Refer back to Chapter 6, “Shooting Trouble with CatOS and IOS,” and Chapter 7, “Shooting Trouble with VLANs on Routers and Switches,” for a quick review.
Example 10-2 illustrates some commands to get you started on baselining the 2900 CatOS-based switch. Example 10-3 does the same for kentnarrows, your IOS-based switch. However, the IOS commands are very similar to the router, so most of them are not repeated here. Interfaces, modules, trunks, ports, Address Resolution Protocol (ARP) tables, switch tables, caching, memory and CPU statistics, Hot Standby Router Protocol (HSRP), utilization, VLANs, and so on are good data to capture for future comparison.
kentnarrows#show mac-address-table Dynamic Address Count: 1 Secure Address (User-defined) Count: 0 Static Address (User-defined) Count: 0 System Self Address Count: 37 Total MAC addresses: 38 Maximum MAC addresses: 8192 Non-static Address Table: Destination Address Address Type VLAN Destination Port ------------------- ------------ ---- -------------------- 00b0.6481.e300 Dynamic 1 FastEthernet0/12 |
NOTE
Improvements are always being made. If you are used to typing show mac for short, be aware that this doesn't work in the most current Catalyst IOS. show mac is now treated as an incomplete command. One must enter show mac address (note, no hyphen).
The main point I wanted to make with reiterating the output of commands you should already be familiar with is for you not to rely only on show running-config or show config. Go back and review all the checklists and ending reviews in each and every chapter for assistance with the individual commands.
The show running-config and show startup-config/show config commands are great to get a handle on how things are configured and what you need to type in for configuration purposes. They are also quite helpful to give you a starting point for copying and pasting to speed up configuring multiple devices. However, the object of mastering the troubleshooting game is that you really need to know how to interpret the output of various other commands, not just show running-config.
Paste in the configurations from tt1 layer 3 configuration or configure the Layer 3 data as in Figure 10-3. My Layer 3 and above baseline starts in Example 10-4. Verify yours now.
duck#ping goose Sending 5, 100-byte ICMP Echos to 172.16.1.9, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 16/16/16 ms duck#ping swan Sending 5, 100-byte ICMP Echos to 172.16.3.9, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/8 ms duck#ping kentnarrows Sending 5, 100-byte ICMP Echos to 172.16.1.45, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 16/18/20 ms duck#ping chesapeakebay Sending 5, 100-byte ICMP Echos to 10.10.10.45, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/8 ms duck#ping knappsnarrows Sending 5, 100-byte ICMP Echos to 172.16.2.45, timeout is 2 seconds: .!!!! Success rate is 80 percent (4/5), round-trip min/avg/max = 4/8/12 ms duck#trace knappsnarrows Tracing the route to knappsnarrows (172.16.2.45) 1 heron (10.10.10.2) 4 msec 4 msec 4 msec 2 osprey (172.16.2.18) 4 msec 4 msec 4 msec 3 knappsnarrows (172.16.2.45) 8 msec 4 msec 8 msec duck#trace kentnarrows Tracing the route to kentnarrows (172.16.1.45) 1 goose (172.16.1.9) 8 msec 8 msec 8 msec 2 kentnarrows (172.16.1.45) 8 msec * 8 msec duck#show arp Protocol Address Age (min) Hardware Addr Type Interface Internet 10.10.10.2 13 0000.0c38.a05d ARPA Ethernet0 Internet 10.10.10.1 - 0000.0c8d.6705 ARPA Ethernet0 Internet 10.10.10.40 1 0050.7307.d076 ARPA Ethernet0 Internet 10.10.10.45 10 0010.ffe5.17ff ARPA Ethernet0 |
Example 10-4 displays the successful results of ping and trace output from the duck router, which I used as a starting point. It is not good to assume that this type of testing works from the other devices; therefore, you should repeat Example 10-4 from every device for your baseline. You may have started from hosta and worked your way around to hostb; that is an appropriate method of testing and baselining as well.
Do not continue until you can ping every device, as in Example 10-4. Check your Physical Layer and interfaces if you run into any problems.
Example 10-5 displays the interfaces on the duck router. This time not only can you check the line and protocol status but also the IP addresses. To display the masks or see other statistics, you need to look at the individual interfaces, routing tables, and show protocols command output.
duck#show ip interface brief Interface IP-Address OK? Method Status Protocol Ethernet0 10.10.10.1 YES manual up up Ethernet1 unassigned YES unset administratively down down Loopback10 172.16.1.1 YES manual up up Serial0 172.16.1.10 YES manual up up Serial1 172.16.1.17 YES manual up up duck#show interfaces e0 Ethernet0 is up, line protocol is up Hardware is Lance, address is 0000.0c8d.6705 (bia 0000.0c8d.6705) Description: duck to chesapeakebay backbone Internet address is 10.10.10.1/24 MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 255/255, load 1/255 Encapsulation ARPA, loopback not set, keepalive set (10 sec) ... duck#show interfaces s0 Serial0 is up, line protocol is up Hardware is HD64570 Description: duck to goose Internet address is 172.16.1.10/29 MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255 Encapsulation HDLC, loopback not set, keepalive set (10 sec) ... duck#show interfaces s1 Serial1 is up, line protocol is up Hardware is HD64570 Description: duck to swan Internet address is 172.16.1.17/29 MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255 Encapsulation HDLC, loopback not set, keepalive set (10 sec) ... duck#show protocols Global values: Internet Protocol routing is enabled Ethernet0 is up, line protocol is up Internet address is 10.10.10.1/24 Ethernet1 is administratively down, line protocol is down Loopback10 is up, line protocol is up Internet address is 172.16.1.1/30 Serial0 is up, line protocol is up Internet address is 172.16.1.10/29 Serial1 is up, line protocol is up Internet address is 172.16.1.17/29 |
Note the preceding show protocols output. It is quite helpful, because it very quickly shows you whether the routing process is on or off. This command also gives you the line and protocol status, as well as the IP address and mask, all in an easy-to-read format. Example 10-6 illustrates the IP protocols and routing tables on duck.
duck#show ip protocols Routing Protocol is "rip" Sending updates every 30 seconds, next due in 12 seconds Invalid after 180 seconds, hold down 180, flushed after 240 Outgoing update filter list for all interfaces is not set Incoming update filter list for all interfaces is not set Redistributing: rip Default version control: send version 2, receive version 2 Interface Send Recv Key-chain Ethernet0 1 2 1 2 Loopback10 2 2 Serial0 2 2 Serial1 2 2 Routing for Networks: 10.0.0.0 172.16.0.0 Routing Information Sources: Gateway Distance Last Update 10.10.10.2 120 00:00:14 172.16.1.18 120 00:00:18 172.16.1.9 120 00:00:19 Distance: (default is 120) duck#show ip route Codes: C - connected, S - static, I - IGRP, 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, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default U - per-user static route, o - ODR Gateway of last resort is not set 172.16.0.0/16 is variably subnetted, 11 subnets, 2 masks R 172.16.1.40/29 [120/1] via 172.16.1.9, 00:00:24, Serial0 R 172.16.2.40/29 [120/2] via 10.10.10.2, 00:00:20, Ethernet0 R 172.16.1.32/29 [120/1] via 172.16.1.9, 00:00:24, Serial0 [120/1] via 172.16.1.18, 00:00:24, Serial1 R 172.16.1.24/29 [120/1] via 172.16.1.9, 00:00:24, Serial0 [120/1] via 172.16.1.18, 00:00:24, Serial1 C 172.16.1.16/29 is directly connected, Serial1 R 172.16.2.16/29 [120/1] via 10.10.10.2, 00:00:20, Ethernet0 C 172.16.1.8/29 is directly connected, Serial0 R 172.16.2.8/29 [120/1] via 10.10.10.2, 00:00:21, Ethernet0 R 172.16.3.8/29 [120/1] via 172.16.1.18, 00:00:24, Serial1 C 172.16.1.0/30 is directly connected, Loopback10 R 172.16.2.0/30 [120/1] via 10.10.10.2, 00:00:21, Ethernet0 10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks R 10.0.0.0/8 [120/7] via 172.16.1.18, 00:00:04, Serial1 [120/7] via 10.10.10.2, 00:00:26, Ethernet0 C 10.10.10.0/24 is directly connected, Ethernet0 |
The preceding routing table shows 11 subnets for 172.16.0.0, but there should be 12. I have identified 172.16.3.16 to be the missing route, which is the ISDN network in Figure 10-3. I brought my interfaces up and then had 12 routes. It is not important that ISDN is operational in this ticket, as long as your Frame Relay link is up and running. If the 172.16.3.8 network is in your routing table, it is.
Example 10-7 displays the hosts table that is on duck and the other devices for ease of ping, trace, and telnet operations.
duck#show hosts
Default domain is not set
Name/address lookup uses domain service
Name servers are 255.255.255.255
Host Flags Age Type Address(es)
duck (perm, OK) 8 IP 10.10.10.1 172.16.1.10
172.16.1.17
heron (perm, OK) 0 IP 10.10.10.2 172.16.2.9
172.16.2.17
goose (perm, OK) 0 IP 172.16.1.9 172.16.1.25
172.16.1.33 172.16.1.41
osprey (perm, OK) 0 IP 172.16.2.18 172.16.2.41
crab (perm, OK) 8 IP 172.16.2.10 172.16.3.10
172.16.3.18
swan (perm, OK) 0 IP 172.16.3.9 172.16.1.18
172.16.1.26 172.16.1.34
172.16.3.17
chesapeakebay (perm, OK) 0 IP 10.10.10.45
kentnarrows (perm, OK) 0 IP 172.16.1.45
knappsnarrows (perm, OK) 0 IP 172.16.2.45
pingme (perm, OK) 8 IP 10.10.10.40
gwise (perm, OK) 8 IP 10.10.10.20
Host Flags Age Type Address(es)
novell (perm, OK) 8 IP 10.10.10.20
etowerdh (perm, OK) 8 IP 10.10.10.10
win98 (perm, OK) 8 IP 10.10.10.10
hosta (perm, OK) 8 IP 172.16.1.42
hostc (perm, OK) 8 IP 172.16.1.43
hostb (perm, OK) 8 IP 172.16.2.42
cat2900 (perm, OK) 8 IP 10.10.10.45
cat3512 (perm, OK) 8 IP 172.16.1.45
cat1900 (perm, OK) 8 IP 172.16.2.45
|
Example 10-8 goes on to test things from the heron router's perspective.
heron#trace kentnarrows Tracing the route to kentnarrows (172.16.1.45) 1 duck (10.10.10.1) 208 msec 124 msec 56 msec 2 goose (172.16.1.9) 12 msec 12 msec 8 msec 3 kentnarrows (172.16.1.45) 12 msec * 8 msec heron#trace knappsnarrows Tracing the route to knappsnarrows (172.16.2.45) 1 osprey (172.16.2.18) 0 msec 4 msec 0 msec 2 knappsnarrows (172.16.2.45) 12 msec 4 msec 8 msec heron#show ip interface brief Interface IP-Address OK? Method Status Protocol Ethernet0 10.10.10.2 YES manual up up Loopback10 172.16.2.2 YES manual up up Serial0 172.16.2.9 YES manual up up Serial1 172.16.2.17 YES manual up up |
Continue to baseline the other devices in the Trouble Ticket. Compare your ending configurations to the tt1 final configs file. If you want to see more of my testing, refer to the tt1 layer 3 testing file.
Note that I separated discovering Layer 1 and Layer 2 from Layer 3 in this Trouble Ticket. I wanted to once more emphasize a layered approach to discovery, configuration, and troubleshooting. It is helpful to understand whether you have a Layer 2 or Layer 1 issue causing the problem or if in fact it is something at Layer 3 or above.
NOTE
The ping command is a quick test to help you decide whether you have connectivity or data-link issues when you can't physically access equipment; it is a quick test of Layer 3 and below. The Cisco and UNIX traceroute command tests up through Layer 4 via User Datagram Protocol (UDP) packets, whereas Microsoft tracert command tests through Layer 3 with Internet Control Message Protocol (ICMP) echos.
If you need more practice after completing the discovery lab, feel free to turn this Trouble Ticket into a configuration lab or vice versa. Actually, I highly recommend it. Practice makes perfect. You can erase the configurations on all devices and configure them from scratch as in Figure 10-3.
3.138.137.127