Example 17-1 | CCNA Practical Studies (Cisco Certification & Training)

Scenario 1

Symptom: Users off R4's Ethernet 0 network (192.168.4.0) cannot access IP-based resources located off R2's Ethernet 1 network (192.168.2.0).

Objective: Resolve the issue so that users can access those resources again. This is completed when R4 successfully can ping R2's Ethernet 1 interface IP address.

The first step in troubleshooting the issue is to verify that R4 and R2 are physically up and that the respective interfaces are in the UP and UP states. Look at R4 first and then R2. One thing that you want to be aware of is that R3 is the hub router for the Frame Relay network. (See Figure 17-1 for the physical path for these networks.) All packets from R4 going to R2 must traverse R3, so you might as well verify that R3 is operational and that the pertinent interfaces are both up.

Example 17-1 illustrates the output.

Example 17-1 show ip interface brief Command Output on R4

 R4#  show ip interface brief  Interface              IP-Address      OK? Method Status                Protocol  Ethernet0              192.168.4.4     YES NVRAM  up                    up  Loopback0              192.169.4.4     YES NVRAM  up                    up Loopback1              200.200.1.4     YES NVRAM  up                    up Loopback2              200.200.2.4     YES NVRAM  up                    up  Serial0                192.168.100.4   YES NVRAM  up                    up  Serial1                unassigned      YES unset  administratively down down R4#

First, you know that R4 is up and operational because you could Reverse Telnet to it. If the router had lost power, you would not have been able to Reverse Telnet to it from the terminal server. Second, from the output, you see that the Ethernet interface Ethernet 0 is up and up. You then will assume that users can access R4's Ethernet 0's interface.

Note

This scenario assumes that no LAN problems occur, such as a bad switch, hub, or cabling.

Third, you can see that the serial interface Serial 0 is up and up. So, the connection to the Frame Relay appears to not have any physical problems.

From this information, you can safely assume that the physical and data link layers are physically up. If there had been a physical issue with either of the layers , the status of the interface would have been down, down or up, down. You will verify correct configurations later; at this point, you just want to make sure that no physical problems are present on R4, R3, and R2, so next go to R3. See Example 17-2.

Example 17-2 show ip interface brief Command Output on R3

 R3#  show ip interface brief  Interface              IP-Address      OK? Method Status                Protocol Ethernet0              192.168.3.3     YES NVRAM  up                    up Loopback0              192.169.3.3     YES NVRAM  up                    up  Serial0                192.168.100.3   YES NVRAM  up                    up  Serial1                192.168.35.3    YES NVRAM  up                    up R3#

The only interface of concern on R3 is Serial 0, the hub interface for the Frame Relay network. The status is up and up, so no physical issues are present here. Next, go to R2. See Example 17-3.

Example 17-3 show ip interface brief Command Output on R2

 R2#  show ip interface brief  Interface              IP-Address     OK? Method Status                Protocol Ethernet0              192.168.1.2    YES NVRAM  up                    up  Ethernet1              192.168.2.2    YES NVRAM  up                    up  Loopback0              192.169.2.2    YES NVRAM  up                    up  Serial0                192.168.100.2  YES NVRAM  up                    up  R2#

By virtue of connecting to the router, you verified that it has power and that the status of interface Ethernet 1 and Serial 0 are both up and up; no physical issues are present on R4 or R2. Before you start checking for configuration errors, isolate where the communication fails. Because users on R4 cannot access IP resources on R2's Ethernet 1 interface, ping from R4 to R2's Ethernet 1 interface, then R2's Serial 0, then R3's Serial 0 interface, and so forth until you have isolated the failure.

Note

Remember, in the Frame Relay network, R4 must send to R3 all packets destined to R2. This is because no direct PVC connects R4 to R2.

Example 17-4 demonstrates this process.

Example 17-4 ping R2's Ethernet 1 from R4

 R4#  ping 192.168.2.2  Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.2.2, timeout is 2 seconds:  .....   Success rate is 0 percent (0/5)  R4#

That failed. Next try R2's Serial 0. See Example 17-5.

Example 17-5 ping R2's Serial 0 from R4

 R4#  ping 192.168.100.2  Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.100.2, timeout is 2 seconds:  .....   Success rate is 0 percent (0/5)  R4#

That failed as well. Next try R3's Serial 0, which is the next hop in the routing path. See Example 17-6.

Example 17-6 ping R3's Serial 0 from R4

 R4#  ping 192.168.100.3  Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.100.3, timeout is 2 seconds:  .....   Success rate is 0 percent (0/5)  R4#

This failed, too. Because this is the next hop from R4, you know that there is a communication breakdown between R4 and R3. Because R4 must send all packets destined for R2 through R3, you need to resolve the communication issue between R4 and R3 first. When that is resolved, you should test to see if that corrects the problem of R4 not being capable of ping ing R2's Ethernet 1 network. If it does not resolve the issue, further troubleshooting will be needed; however, first resolve the communication problem between R4 and R3.

As mentioned in the introduction to this chapter, you want to start each troubleshooting step at the physical layer of the OSI reference model and start the troubleshooting process closest to where the symptom occurs. In this case, users on R4's Ethernet 0 network cannot communicate with R2's Ethernet 1 network. So, according to the prescribed troubleshooting process, look at R4's data link layer configurations because you have already dismissed physical layer issues.

From your initial troubleshooting steps, you found a communication breakdown between R3's Serial 0 and R4's Serial 0 interfaces. This is the Frame Relay network, so you need to recall the configuration tasks and issues that pertain to Frame Relay.

First, you need to verify that you are receiving the correct DLCI from the Frame Relay switch. If are not receiving LMI, the interface would be in an UP DOWN state; you know that you are receiving LMI, so you just need to make sure that the LMI information is correct. Issue a show frame-relay pvc command to verify that you are receiving DLCI 101 on interface Serial 0. Example 17-7 displays the output from the command.

Example 17-7 show frame-relay pvc Output on R4

 R4#  show frame-relay pvc  PVC Statistics for interface Serial0 (Frame Relay DTE)  DLCI = 101  , DLCI USAGE = LOCAL,  PVC STATUS = ACTIVE  ,  INTERFACE = Serial0  input pkts 60            output pkts 75           in bytes 6040   out bytes 6930           dropped pkts 0           in FECN pkts 0   in BECN pkts 0           out FECN pkts 0          out BECN pkts 0   in DE pkts 0             out DE pkts 0   out bcast pkts 51         out bcast bytes 3690   pvc create time 00:20:26, last time pvc status changed 00:20:26 R4#

You are receiving DLCI 101, which is correct, and it is in ACTIVE status. This means that the DLCI that the Frame Relay switch is sending you through LMI is valid and is on Serial 0, the correct interface.

Frame Relay also needs mappings that map DLCIs to IP addresses. These tell the router how to forward the frame out the appropriate PVC. Verify the DLCI-to-IP address mappings on R4 by issuing the command show frame-relay map. See Example 17-8.

Example 17-8 show frame-relay map Output on R4

 R4#  show frame-relay map  Serial0 (up):  ipx 1000.0000.0000.2222 dlci 101  (0x65,0x1850), static,               broadcast,               CISCO, status defined, active Serial0 (up):  ipx 1000.0000.0000.3333 dlci 101  (0x65,0x1850), static,               broadcast,               CISCO, status defined, active R4#

Here is a problem. You see DLCI-to-IPX address mappings, but you do not see DLCI-to-IP address mappings. Remember, you need mappings for each protocol that you are using on that interface. The mappings have two ways of occurring. You can rely on Frame Relay Inverse ARP, or you can statically assign the mappings. If you recall, you used static frame-relay map statements for R4 and R2, but you let Frame Relay Inverse ARP dynamically create the mappings on R3. Frame Relay Inverse ARP is utilized on R3 because R3 has two PVCs, one to each router. Take a look at R4's configuration to verify that the frame-relay map statements are still there. See Example 17-9.

Example 17-9 R4's Running Config File

 R4#  show running-config  Building configuration... Current configuration: ! version 11.2 no service password-encryption no service udp-small-servers no service tcp-small-servers ! hostname R4 ! enable password falcons ! ip subnet-zero ip telnet source-interface Serial0 no ip domain-lookup ip host R4 192.169.4.4 ip host R1 192.169.1.1 ip host R2 192.169.2.2 ip host R3 192.169.3.3 ip host R5 192.169.5.5 ip host R6 192.169.6.6 ipx routing 0000.0000.4444 ! interface Loopback0  ip address 192.169.4.4 255.255.255.0 ! interface Loopback1  ip address 200.200.1.4 255.255.255.0 ! interface Loopback2  ip address 200.200.2.4 255.255.255.0 ! interface Ethernet0  description This interface does not connect to another IP device  ip address 192.168.4.4 255.255.255.224  ipx network 4000 !  interface Serial0  description This interface connects to R3's S0 (DLCI 101)  ip address 192.168.100.4 255.255.255.0  ip summary-address eigrp 100 200.200.0.0 255.255.0.0  encapsulation frame-relay ipx network 1000  no fair-queue  frame-relay map ipx 1000.0000.0000.2222 101 broadcast   frame-relay map ipx 1000.0000.0000.3333 101 broadcast  no frame-relay inverse-arp  frame-relay lmi-type ansi ! interface Serial1  no ip address  shutdown ! router eigrp 100  network 192.168.100.0  network 192.168.4.0  network 200.200.1.0  network 200.200.2.0  network 192.169.4.0  no auto-summary ! no ip classless ! ! ! ipx router eigrp 100  network 1000 ! ! ipx router rip  no network 1000 ! ! ! banner motd ^C This is Router 4 ^C ! line con 0  exec-timeout 0 0  password falcons  logging synchronous line aux 0 line vty 0 4  password falcons  login ! end R4#

From the highlighted section, you can see that Serial 0 has the frame-relay map statements for IPX but not for IP. Somehow they were removed, either by a configuration change not saved since the last reload or from a corrupt configuration filefrom our experience, you will probably never know.

To resolve this issue, you just need to add back the frame-relay map statements for R2's Serial 0 and R3's Serial 0. Example 17-10 takes you through the process of adding the frame-relay map statements. Don't forget to save the configuration after you have added the f rame-relay map statements.

Example 17-10 Adding frame-relay map Statements on R4

 R4#  conf t  Enter configuration commands, one per line.  End with CNTL/Z. R4(config)#  interface serial 0  R4(config-if)#  frame-relay map ip 192.168.100.2 101 broadcast  R4(config-if)#  frame-relay map ip 192.168.100.3 101 broadcast  R4(config-if)#  end  R4#  copy running-config startup-config  Building configuration... [OK] R4#

To verify that the mappings are correct, again issue the show frame-relay map command. See Example 17-11.

Example 17-11 Verify Frame Relay Mappings on R4

 R4#  show frame-relay map   Serial0 (up): ip 192.168.100.2 dlci 101(0x65,0x1850), static,   broadcast,   CISCO, status defined, active   Serial0 (up): ip 192.168.100.3 dlci 101(0x65,0x1850), static,   broadcast,   CISCO, status defined, active  Serial0 (up): ipx 1000.0000.0000.2222 dlci 101(0x65,0x1850), static,               broadcast,               CISCO, status defined, active Serial0 (up): ipx 1000.0000.0000.3333 dlci 101(0x65,0x1850), static,               broadcast,               CISCO, status defined, active R4#

From the highlighted text, you see that the mappings are correct. Verify that you can ping to R3's Serial 0 and R2's Serial 0 to see if this resolves the initial problem of R4's Ethernet 0 users not being able to access IP-based resources on R2's Ethernet 1 network. Example 17-12 illustrates the results.

Example 17-12 Verify Connectivity to R3's Serial 0 and R2's Ethernet 1

 R4#  ping 192.168.100.3  Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.100.3, timeout is 2 seconds:  !!!!!   Success rate is 100 percent (5/5)  , round-trip min/avg/max = 60/60/60 ms R4#  ping 192.168.2.2  Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.2.2, timeout is 2 seconds:  !!!!!   Success rate is 100 percent (5/5)  , round-trip min/avg/max = 88/92/104 ms R4#

Success on both interfaces! You have resolved the problem. To quickly review, you verified that the routers in the routing path, R4, R3, and R2, were operational and that all pertinent interfaces were in the UP and UP state, removing concerns that there were physical layer issues. You then did a series of ping commands to isolate where the communication breakdown occurred. After isolating the communication breakdown, you verified data link layer configuration commands with a show frame-relay pvc command and a show frame-relay map command. From the show frame-relay map command, you found that the Frame Relay mappings were missing and added those mappings manually. This was the cause of the problem.

Top