Trouble Tickets Solutions
These solutions are not always the only way to perform these tasks. However, the upcoming chapter scenarios are based on these solutions.
Trouble Ticket 1 Solution
There are a couple of issues in Trouble Ticket 1. First, you do not have a route to the 10.2.2.0 network in the r1 routing table, much less the r5 routing table. This is because EIGRP automatically summarizes IP at the classful boundary. Actually, you had this problem back in the IP chapter, and in this chapter's scenario. The no auto-summary command is a good command to remember for classless protocols such as EIGRP and RIPv2 that automatically summarize at the classful boundary. Look back at the routing table display in Trouble Ticket 1 to see the null 0 routes for the classful boundary of 192.168.5.0/24 and 10.0.0.0/8. Fix the issue as in Example 5-27 so that you can see both 10.1.1.0 and 10.2.2.0 from any router. This issue is referred to as discontiguous subnets. EIGRP is a classless routing protocol and certainly supports them, but not with the default automatic classful summarization. If you actually had this issue, perhaps you did not save your running-config to your startup-config when you fixed the problem earlier in the chapter. Therefore when the device rebooted because of a power problem, it read the contents of NVRAM. Turning off summarization is not best practice either. Summarize the 192.168.5.0 network using a 255.255.255.0 mask so that you minimize the impact of changes made in the internetwork.
Example 5-27. Summarizing EIGRP
r1(config)#router eigrp 500 r1(config-router)#no auto-summary r1(config-router)#interface serial 0 r1(config-if)#ip summary-address eigrp 500 192.168.5.0 ? A.B.C.D IP network mask r1(config-if)#ip summary-address eigrp 500 192.168.5.0 255.255.255.0 r3(config)#router eigrp 500 r3(config-router)#no auto-summary r3(config-router)#interface serial 0/3 r3(config-if)#ip summary-address eigrp 500 192.168.5.0 255.255.255.0 r3(config-if)#end r3#show ip route 192.168.5.0/24 is variably subnetted, 7 subnets, 2 masks C 192.168.5.96/28 is directly connected, FastEthernet2/0 C 192.168.5.64/28 is directly connected, Serial0/1 C 192.168.5.80/28 is directly connected, Serial0/0 D 192.168.5.32/28 [90/40537600] via 192.168.5.81, 00:00:40, Serial0/0 [90/40537600] via 192.168.5.49, 00:00:40, Serial0/2 [90/40537600] via 192.168.5.65, 00:00:40, Serial0/1 C 192.168.5.48/28 is directly connected, Serial0/2 D 192.168.5.0/24 is a summary, 00:00:14, Null0 D 192.168.5.16/28 [90/40537600] via 192.168.5.81, 00:00:40, Serial0/0 10.0.0.0/24 is subnetted, 2 subnets D 10.1.1.0 [90/41024000] via 192.168.5.81, 00:00:40, Serial0/0 C 10.2.2.0 is directly connected, Serial0/3 r4#show ip route D 192.168.5.0/24 [90/40514560] via 10.2.2.1, 00:00:31, Serial0/0 10.0.0.0/24 is subnetted, 2 subnets D 10.1.1.0 [90/41536000] via 10.2.2.1, 00:00:32, Serial0/0 C 10.2.2.0 is directly connected, Serial0/0 r5#show ip route D 192.168.5.0/24 [90/40537600] via 10.1.1.1, 00:00:04, Serial0 10.0.0.0/24 is subnetted, 2 subnets D 10.2.2.0 [90/41536000] via 10.1.1.1, 00:00:04, Serial0 C 10.1.1.0 is directly connected, Serial0 r5#ping 10.2.2.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.2.2.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 84/88/92 ms |
EIGRP enables you to summarize on any interface you choose and requires you to turn off classful summarization for discontiguous subnets to work. Draw yourself a picture if you need to. Draw subnet 10.1.1.0/24 on the left, 192.168.5.0/24 in the middle, and 10.2.2.0/24 on the right. Then it will be clear that you have two network 10.0.0.0 subnets separated by the 192.168.5.0 network. The no auto-summary was not necessary on r2, r4, r5, but required on r1 and r3. A good test is to go to r2 and make sure it has a route for 10.1.1.0/24 and a route for 10.2.2.0/24. However, the ping from r5 to 10.2.2.2 works just fine, too.
R1 and r3 have interfaces in multiple networks. By summarizing the 192.168.5.0 routes to r5 and r4, you significantly reduce the routing table size as well as localize the impact of changes. Note also the multiple paths to 192.168.5.32 as shaded in the r3 routing table.
Remember to save all your configurations to startup-config (NVRAM). Compare them to my SecureCRT log if you need something to compare them to. Although not specified in the Trouble Ticket, it is assumed knowledge to also copy the configurations to another location for backup (to a TFTP server, for instance).
Trouble Ticket 2 Solution
Looks like someone forgot the encapsulation on r1e0. Example 5-28 shows the fix.
Example 5-28. SAP Encapsulation
r1(config)#interface ethernet 0 r1(config-if)#encap sap r1(config-if)#!!!better try again r1(config-if)#ipx encap sap r1(config-if)#end r1#show ipx interface brief Interface IPX Network Encapsulation Status IPX State Ethernet0 516 SAP up [up] Ethernet1 unassigned not config'd up n/a Serial0 unassigned not config'd up n/a Serial1 unassigned not config'd up n/a r1#show ipx route 2 Total IPX routes. Up to 1 parallel paths and 16 hops allowed. No default route known. C 516 (SAP), Et0 R 346648E2 [02/01] via 516.0080.29e8.5c6b, 5s, Et0 r1#debug ipx sap activity IPX service debugging is on r1# 02:10:21: IPXSAP: Response (in) type 0x2 len 288 src:516.0080.29e8.5c6b dest:516.ffff.ffff.ffff(452) 02:10:21: type 0x4, "GWISE", 346648E2.0000.0000.0001(451), 1 hops 02:10:21: type 0x26B, "GWISE_TREE______________________GRN@@@@@DPJ", 346648E2.0000.0000.0001(5), 1 hops 02:10:21: type 0x278, "GWISE_TREE______________________GRN@@@@@DPJ", 346648E2.0000.0000.0001(4006), 1 hops 02:10:21: type 0x107, "GWISE", 346648E2.0000.0000.0001(8104), 1 hops 02:10:46: IPXSAP: positing update to 516.ffff.ffff.ffff via Ethernet0 (broadcast) (full) 02:10:46: IPXSAP: suppressing null update to 516.ffff.ffff.ffff r1#undebug all All possible debugging has been turned off r1#copy running-config startup-config |
It is always a good practice to show your interfaces as in the original Trouble Ticket for troubleshooting. If you were to issue the show ipx interface brief command, for instance, you would quickly see the encapsulation and status IPX network 516, whereas show ipx interface e0 would show the node address, too. Copy all configurations to a TFTP server for backup.
Trouble Ticket 3 Solution
This requires commands on the server and on the router. Use a utility such as inetcfg or the command line on the server to change the frame type to bind an appropriate IP address to the NIC. I used 192.168.5.20/28. You can unbind any other frame types for now. Remember to issue the reinitialize system command at the Novell command prompt and verify with config. Change the encapsulation on r1e0 to ARPA for Ethernet II to match the server as in Example 5-29.
Example 5-29. ARPA Encapsulation
r1(config-if)#ipx encap arpa r1(config-if)#end r1#show ipx route C 516 (ARPA), Et0 r1#ping 192.168.5.20 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.5.20, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms r1#copy running-config startup-config |
It is always a good practice to show your interfaces as in the original Trouble Ticket for troubleshooting. If you were to issue the show ipx interface brief command, for instance, you would quickly see the encapsulation and status IPX network 516 (whereas show ipx interface e0 would show the node address, too).
Trouble Ticket 4 Solution
With duplicate MAC addresses involving a router, the router address takes priority and wins out over the host. (See Example 5-30.) Although there is really no message that comes right out and tells you there is a problem until you go to use the address, the output of debug arp is quite helpful. Remember to change the MAC address back after you experiment.
Example 5-30. Duplicate MACs (Router and hostb)
r1(config)#interface ethernet 0 r1(config-if)#mac-address ? H.H.H MAC address r1(config-if)#mac-address 0080.c7aa.c887 r1(config-if)#end r1#show interface ethernet 0 Ethernet0 is up, line protocol is up Hardware is Lance, address is 0080.c7aa.c887 (bia 0000.0c8d.6705) Description: r1e0 to hosta hostb and gwise Internet address is 192.168.5.17/28 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 ... r1#debug arp ARP packet debugging is on 03:19:16: IP ARP req filtered src 192.168.5.19 0080.c7aa.c887, dst 192.168.5.17 0000.0000.0000 it's our address 03:19:18: IP ARP req filtered src 192.168.5.19 0080.c7aa.c887, dst 192.168.5.17 0000.0000.0000 it's our address 03:19:19: IP ARP req filtered src 192.168.5.19 0080.c7aa.c887, dst 192.168.5.17 0000.0000.0000 it's our address 03:19:20: IP ARP req filtered src 192.168.5.19 0080.c7aa.c887, dst 192.168.5.17 0000.0000.0000 it's our address r1#ping 192.168.5.19 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.5.19, timeout is 2 seconds: 03:20:11: IP ARP: creating incomplete entry for IP address: 192.168.5.19 03:20:12: IP ARP: sent req src 192.168.5.17 0080.c7aa.c887, dst 192.168.5.19 0000.0000.0000 Ethernet0. 03:20:13: IP ARP: sent req src 192.168.5.17 0080.c7aa.c887, dst 192.168.5.19 0000.0000.0000 Ethernet0. .... Success rate is 0 percent (0/5) r1#show arp Protocol Address Age (min) Hardware Addr Type Interface Internet 192.168.5.33 - 0000.0c8d.6706 ARPA Ethernet1 Internet 192.168.5.34 3 0000.0c38.a05d ARPA Ethernet1 Internet 192.168.5.20 3 0080.29e8.5c6b ARPA Ethernet0 Internet 192.168.5.17 - 0080.c7aa.c887 ARPA Ethernet0 Internet 192.168.5.19 0 Incomplete ARPA r1#undebug all All possible debugging has been turned off |
Because you didn't have CiscoWorks Campus Manager in your environment to help you run a report for duplicate MAC or IP addresses, your IOS show, logging, and debug commands can help you pinpoint the issue. Notice the incomplete ARP entry when you attempted to ping a host with the same MAC address as r1e0. Prior to that, note the output of debug arp where the router complains about the address. Fix the issue as in Example 5-31 and verify your ping.
Example 5-31. Resetting the MAC address Back to the Original
r1(config)#interface ethernet 0 r1(config-if)#no mac-address r1(config-if)#end r1#show interface ethernet 0 Ethernet0 is up, line protocol is up Hardware is Lance, address is 0000.0c8d.6705 (bia 0000.0c8d.6705) ... r1#show arp Protocol Address Age (min) Hardware Addr Type Interface Internet 192.168.5.33 - 0000.0c8d.6706 ARPA Ethernet1 Internet 192.168.5.34 2 0000.0c38.a05d ARPA Ethernet1 Internet 192.168.5.20 2 0080.29e8.5c6b ARPA Ethernet0 Internet 192.168.5.17 - 0000.0c8d.6705 ARPA Ethernet0 r1#ping 192.168.5.19 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.5.19, timeout is 2 seconds: .!!!! Success rate is 80 percent (4/5), round-trip min/avg/max = 1/1/4 ms r1#ping 192.168.5.19 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.5.19, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms r1#copy running-config startup-config |
If issues remain, you may need to clear the ARP table using the clear arp-cache command because the entries are kept there for a 4-hour time period in Cisco devices. Because you really can't just clear one entry, it is better practice to bounce (shut/no shut) the affected interface first. If necessary, an ARP packet is broadcast (local broadcast) to resolve the destination IP address (Layer 3) to its equivalent MAC address (Layer 2). If the destination host is on the same subnet, the MAC is the destination host's address. If the destination host is on a different subnet, however, the resulting resolution is generally the default gateway (local router interface) MAC address. Because ARP is dynamic, any leftover issues eventually fix themselves. If you do need to fix them immediately, however, remember to shut/no shut the interface first and clear arp if necessary.
Trouble Ticket 5 Solution
Figure 5-18 shows the duplicate IP on hosta (a Windows 2000 box) after I configured it with the same IP as r1e0.
The router displayed the following:
1w4d: %IP-4-DUPADDR: Duplicate address 192.168.5.17 on Ethernet0,
sourced by 0010.4ba5.ae50
IP devices detect a duplicate because they hear an ARP broadcast with a source IP that matches their own. This message immediately shows up on the console of the router and would show up with show logging history, too.
Trouble Ticket 6 Solution
Open Sniffer and observe the housekeeping traffic as I do in Figure 5-19, Figure 5-20, and Example 5-32. A quick glimpse shows that EIGRP, loop reply receipt, and CDP are running without you or me sending any data at all.
If you are opening your own Sniffer file, right-click to mark the first loop reply receipt and click the next occurrence with the same address. Scroll if needed to see the relative time column to record that they occur every 10 seconds. These are Layer 2 keepalives. Notice in particular how on Ethernet the interface talks to itself quite frequently. When an interface misses three consecutive keepalives, the line protocol goes down. By talks to itself, I mean sends to its own MAC. In the Sniffer decode, when one is determining the period by locating each occurrence, one must ignore keepalives sent by other Cisco devices (with a different source MAC).
It's important to note that the Ethernet keepalive provides a limited confidence test. On full-duplex media (UTP, fiber), for instance, the sender of the keepalive will not receive its own transmission. So the only assurance from the keepalive is that it can successfully transmit out the NIC. The receipt of the link pulses provides the only confidence in the other direction. It is quite possible to have one-way link, if the medium works only in one direction. One device will report that “line protocol is up” whereas the partner shows it as down.
In addition, loss of link (Layer 1) causes the interface status to change to down within 1 second rather than in 30 seconds (Layer 2 keepalive). This also applies to the HDLC keepalive dependence on Layer 1 (DCD, CTS, Rx clock) for serial links on the WAN.
Example 5-32. CDP Traffic
r1#debug cdp events CDP events debugging is on r1#debug cdp packets CDP packet info debugging is on 04:08:42: CDP-PA: Packet received from r3 on interface Serial1 04:08:42: **Entry found in cache** 04:08:55: CDP-PA: Packet received from r2 on interface Ethernet1 04:08:55: **Entry found in cache** 04:09:02: CDP-PA: Packet received from 804_rtr on interface Ethernet0 04:09:02: **Entry found in cache** 04:09:24: CDP-PA: Packet received from r5 on interface Serial0 04:09:24: **Entry found in cache** 04:09:30: CDP-PA: Packet sent out on Ethernet0 04:09:30: CDP-PA: Packet sent out on Ethernet1 04:09:30: CDP-PA: Packet sent out on Serial0 04:09:30: CDP-PA: Packet sent out on Serial1 04:09:42: CDP-PA: Packet received from r3 on interface Serial1 04:09:42: **Entry found in cache** ... r1#show cdp Global CDP information: Sending CDP packets every 60 seconds Sending a holdtime value of 180 seconds r1#undebug all |
Because you captured CDP packets, take time to analyze them in the protocol analyzer trace in Figure 5-20. If you are curious about the 804 router in my display, it is just being used as hub to connect some devices together. Confirm that CDP messages occur every 60 seconds and that they use the destination multicast address of 01000ccccccc as in line 7 of Figure 5-20. Also note the EIGRP AS 500 multicast hellos over 224.0.0.10.
NOTE
If you are not seeing the housekeeping output mentioned, you may have a switch in your lab scenario and special commands are required to monitor the same activity. You will become familiar with that in the next chapter. Of course, CDP could be turned off as well.
Trouble Ticket 7 Solution
The clear counters ethernet 0 command clears just the counters for the e0 interface rather than all the counters that show up when you type show interfaces at the router enable prompt. When disconnecting the cable from the Windows 2000 box, the host very quickly flashes “hardware error, the request timed out,” and then repeated a “destination host unreachable” message. When you plug the cable back in, things just pick up where they left off with the continuous ping on the host. The router receives the ARP broadcast, but the interface does not go down because it and the hosts on subnet 192.168.5.16/28 are plugged into a hub (see Example 5-33).
Example 5-33. hosta Cable Disconnect SecureCRT Output
r1#clear counters ethernet 0 Clear "show interface" counters on this interface [confirm] 00:25:45: %CLEAR-5-COUNTERS: Clear counter on interface Ethernet0 by console r1#debug arp ARP packet debugging is on 00:26:07: IP ARP: rcvd req src 192.168.5.18 0010.4ba5.ae50, dst 192.168.5.19 Ethernet0 r1#show interface ethernet 0 Ethernet0 is up, line protocol is up Hardware is Lance, address is 0000.0c8d.6705 (bia 0000.0c8d.6705) Description: r1e0 to hosta hostb and gwise Internet address is 192.168.5.17/28 ... r1#!!!this is when I plugged the cable back in r1#show interface ethernet 0 Ethernet0 is up, line protocol is up Hardware is Lance, address is 0000.0c8d.6705 (bia 0000.0c8d.6705) Description: r1e0 to hosta hostb and gwise Internet address is 192.168.5.17/28 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:00, output 00:00:02, output hang never Last clearing of "show interface" counters 00:01:33 Queueing strategy: fifo 00:27:17: IP ARP: rcvd req src 192.168.5.18 0010.4ba5.ae50, dst 192.168.5.18 Ethernet0 00:27:17: IP ARP: rcvd req src 192.168.5.18 0010.4ba5.ae50, dst 192.168.5.19 Ethernet0 00:27:17: IP ARP: rcvd req src 192.168.5.18 0010.4ba5.ae50, dst 192.168.5.18 Ethernet0 ... 00:27:18: IP ARP: rcvd req src 192.168.5.18 0010.4ba5.ae50, dst 192.168.5.18 Ethernet0 r1# |
If you analyzed the ARP table on the host with arp –a, you should have the MAC addresses and IP addresses for hosta and hostb.
Trouble Ticket 8 Solution
Configuring all routers for syslog is no more than just adding the global logging 192.168.5.18 command to each router. This assumes that you are running the syslog on hosta. The default setting for r3 fa2/0 is 100-Mbps, full-duplex (see Example 5-34). To verify or change the setting on the host, you need the software that comes with the NIC (see Figure 5-21).
Example 5-34. hostc Cable Disconnect
r3#show interface fastethernet 2/0 FastEthernet2/0 is up, line protocol is up Hardware is AmdFE, address is 00b0.6481.e300 (bia 00b0.6481.e300) Description: r3fa2/0 to hostc Internet address is 192.168.5.97/28 MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec, rely 255/255, load 1/255 Encapsulation ARPA, loopback not set, keepalive set (10 sec) Full-duplex, 100Mb/s, 100BaseTX/FX ARP type: ARPA, ARP Timeout 04:00:00 ... r3#show running-config interface fastethernet2/0 Current configuration: interface FastEthernet2/0 description r3fa2/0 to hostc ip address 192.168.5.97 255.255.255.240 no ip directed-broadcast end r3#clear counters fastethernet 2/0 Clear "show interface" counters on this interface [confirm] r3#debug arp 00:58:53: %CLEAR-5-COUNTERS: Clear counter on interface FastEthernet2/0 by console ARP packet debugging is on r3# 00:59:37: IP ARP: rcvd req src 192.168.5.98 0050.04df.5f3c, dst 192.168.5.97 FastEthernet2/0 00:59:37: IP ARP: creating entry for IP address: 192.168.5.98, hw: 0050.04df.5f3c 00:59:37: IP ARP: sent rep src 192.168.5.97 00b0.6481.e300, dst 192.168.5.98 0050.04df.5f3c FastEthernet2/0 01:00:06: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet2/0, changed state to down 01:00:06: IP ARP: sent req src 192.168.5.97 00b0.6481.e300, dst 192.168.5.98 0050.04df.5f3c FastEthernet2/0 01:00:06: IP ARP: sent rep src 192.168.5.97 00b0.6481.e300, dst 192.168.5.97 ffff.ffff.ffff FastEthernet2/0 r3#show interface fastethernet 2/0 FastEthernet2/0 is up, line protocol is down Hardware is AmdFE, address is 00b0.6481.e300 (bia 00b0.6481.e300) Description: r3fa2/0 to hostc Internet address is 192.168.5.97/28 MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec, rely 255/255, load 1/255 Encapsulation ARPA, loopback not set, keepalive set (10 sec) Full-duplex, 100Mb/s, 100BaseTX/FX ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:58, output 00:00:01, output hang never Last clearing of "show interface" counters 00:01:42 |
Trouble Ticket 8 has a point-to-point connection, whereas Trouble Ticket 7 had a shared hub connection. Line protocol goes down when the host misses three consecutive keepalives in a shared environment, but here the line protocol goes down upon loss of link. In Example 5-35, notice how because of autonegotiation the duplex setting ended up as half-duplex. This is the frequent cause of errors and bizarre problems. Although autonegotiation has certainly matured over the years, in most cases I still recommend that the settings be specified on both ends. You can hard code the duplex to full using the interface full-duplex command. Syslog should have indicated the clearing of the counters and the interface changes such as in Example 5-36.
Example 5-35. Plug the Cable Back In
01:00:56: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet2/0, changed state to up 01:00:59: IP ARP: creating incomplete entry for IP address: 192.168.5.98 01:00:59: IP ARP: sent req src 192.168.5.97 00b0.6481.e300, dst 192.168.5.98 0000.0000.0000 FastEthernet2/0 01:00:59: IP ARP: rcvd rep src 192.168.5.98 0050.04df.5f3c, dst 192.168.5.97 FastEthernet2/0 r3#show interface fastethernet 2/0 FastEthernet2/0 is up, line protocol is up Hardware is AmdFE, address is 00b0.6481.e300 (bia 00b0.6481.e300) Description: r3fa2/0 to hostc Internet address is 192.168.5.97/28 MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec, rely 255/255, load 1/255 Encapsulation ARPA, loopback not set, keepalive set (10 sec) Half-duplex, 100Mb/s, 100BaseTX/FX ARP type: ARPA, ARP Timeout 04:00:00 |
Example 5-36. Syslog Output
Nov 11 19:04:02 192.168.5.82 82: 1w5d: %CLEAR-5-COUNTERS:
Clear counter on interface FastEthernet2/0 by console
Nov 11 19:06:21 192.168.5.82 83: 1w5d: %LINEPROTO-5-UPDOWN:
Line protocol on Interface FastEthernet2/0, changed state to down
Nov 11 19:07:42 192.168.5.82 84: 1w5d: %LINEPROTO-5-UPDOWN:
Line protocol on Interface FastEthernet2/0, changed state to up
|
You have completed the chapter Trouble Tickets when you feel comfortable with the tasks assigned and the various scenarios throughout the chapter. Review or experiment in the areas where you need more help. Understanding and troubleshooting in a simple environment is certainly the foundation for understanding and troubleshooting more complex protocols and technologies. Check your understanding with the chapter review questions.