Symptom: It has been reported that users on network 192.168.4.0 (R4's E0 network) cannot reach IP resources on network 192.168.3.0 (R3's Ethernet 0 network).
Objective: You will have resolved this issue when you can successfully ping 192.168.3.3 from R4.
Isolate the problem: Begin by verifying that the reported symptoms are a network issue instead of an end- user configuration problem. You can do this by issuing a ping from R4 to R3's Ethernet 0 interface of 192.168.3.3, as shown in Example 17-13.
R4# ping 192.168.3.3 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.3.3, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) R4#
The request has failed. Now that you have verified the problem, follow the prescribed troubleshooting methodology by starting at R4 and verifying Layer 1, Layer 2, and finally Layer 3.
Examine physical connectivity on R4 and verify that Ethernet 0 and Serial 0 are up by doing a show ip interfaces brief, as shown in Example 17-14.
R4# show ip int 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#
Of particular concern here is Ethernet 0 and Serial 0 because if either of these interfaces were down or if the line protocol were down, you would have a Layer 1 or 2 issue to resolve. However, you can see in the highlighted sections of Example 17-14 that both Ethernet 0 and Serial 0 interfaces are up and that the line protocol on each is up. Additionally, you can verify that R4's PVC to R3 is ACTIVE by doing a show frame-relay pvc, as shown in Example 17-15.
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 12250 output pkts 23980 in bytes 878122 out bytes 1677066 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 23474 out bcast bytes 1619636 pvc create time 3d18h, last time pvc status changed 2d16h R4#
From the highlighted portions of Example 17-15, you see that the PVC to R3 is ACTIVE and that the PVC has been up for 2 days and 16 hours, as shown by the last PVC status change in the example. Thus, to this point, you know that Layer 1 and 2 appear as you would expect them to on R4.
Next, look for a route to the 192.168.3.0 network in R4's routing table by doing a show ip route 192.168.3.0 on R4, as shown in Example 17-16.
R4# show ip route 192.168.3.0 % Network not in table R4#
It is apparent that R4 is not receiving this route. If you examine the IP routing table of R4, you can determine whether you are lacking just this one route or whether you aren't learning routes to other networks as shown in Example 17-17.
R4# 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 C 200.200.1.0/24 is directly connected, Loopback1 C 200.200.2.0/24 is directly connected, Loopback2 C 192.168.100.0/24 is directly connected, Serial0 D EX 192.168.35.0/24 [170/2169856] via 192.168.100.3 , 02:03:34, Serial0 D EX 192.168.60.0/24 [170/41536000] via 192.168.100.3, 02:03:34, Serial0 D EX 192.168.50.0/24 [170/2697984] via 192.168.100.3, 02:03:34, Serial0 D EX 192.169.1.0/24 [170/2733056] via 192.168.100.3, 01:48:05, Serial0 D EX 192.168.1.0/24 [170/2733056] via 192.168.100.3, 01:48:05, Serial0 D EX 192.168.2.0/24 [170/2733056] via 192.168.100.3, 01:48:05, Serial0 D EX 192.169.3.0/24 [170/2169856] via 192.168.100.3, 02:03:34, Serial0 D EX 192.169.2.0/24 [170/2733056] via 192.168.100.3, 01:48:06, Serial0 D EX 192.169.5.0/24 [170/2809856] via 192.168.100.3, 02:03:35, Serial0 192.168.4.0/27 is subnetted, 1 subnets C 192.168.4.0 is directly connected, Ethernet0 C 192.169.4.0/24 is directly connected, Loopback0 D EX 192.168.200.0/24 [170/41536000] via 192.168.100.3, 02:03:38, Serial0 D 200.200.0.0/16 is a summary, 02:03:38, Null0 R4#
You can see that all EIGRP routes have been learned through 192.168.100.3, as highlighted. This tells you that R3's Serial 0 interface and the Frame Relay PVC must be up to be propagating these routes to R4. Refer back to the routing protocol diagram in Figure 17-1.
Network 192.168.3.0 should be a part of EIGRP AS 100. Because it is not being propagated, you might have an EIGRP configuration issue on R3 or Ethernet 0 on R3 could be down, causing the route not to be advertised by EIGRP. Ensure that Ethernet 0 is up on R3 by doing a show ip interface brief, as demonstrated in Example 17-18.
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#
Because R3's Ethernet 0 interface is up and the line protocol is up, you might suspect the issue to be with the EIGRP configuration of R3. Do a show ip eigrp interfaces to see which interfaces on R3 are part of EIGRP AS 100, as demonstrated in Example 17-19.
R3# show ip eigrp interfaces IP-EIGRP interfaces for process 100 Xmit Queue Mean Pacing Time Multicast Pending Interface Peers Un/Reliable SRTT Un/Reliable Flow Timer Routes Se0 2 0/0 91 0/15 262 0 R3#
You can see that Serial 0 is a part of EIGRP process (AS) 100, but R3's Ethernet 0 is not. At this point, the EIGRP configuration is definitely suspect. Examine the running config of R3, as shown in Example 17-20.
R3# 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 R3 ! enable password falcons ! username all no ip domain-lookup ip host R3 192.169.3.3 ip host R1 192.169.1.1 ip host R2 192.169.2.2 ip host R4 192.169.4.4 ip host R5 192.169.5.5 ip host R6 192.169.6.6 ipx routing 0000.0000.3333 ! interface Loopback0 ip address 192.169.3.3 255.255.255.0 ! interface Ethernet0 ip address 192.168.3.3 255.255.255.0 ipx network 3000 ipx network 3001 encapsulation SAP secondary ! interface Serial0 description This interface connects to R2's S0(DLCI 200) and R4's S0 (DLCI 100) ip address 192.168.100.3 255.255.255.0 ip access-group 101 in encapsulation frame-relay no ip split-horizon eigrp 100 ipx network 1000 no ipx split-horizon eigrp 100 no fair-queue frame-relay lmi-type ansi ! interface Serial1 description This interface connects to R5's S0 (DCE) ip address 192.168.35.3 255.255.255.0 ipx network 3500 ! router eigrp 100 redistribute igrp 200 metric 200 200 255 1 1500 network 192.168.100.0 ! router igrp 200 redistribute eigrp 100 metric 2000 200 255 1 1500 network 192.168.35.0 network 192.169.3.0 ! no ip classless access-list 101 deny tcp any 192.168.50.0 0.0.0.255 eq www access-list 101 deny tcp any 192.168.30.0 0.0.0.255 eq ftp access-list 101 deny tcp any 192.168.30.0 0.0.0.255 eq ftp-data access-list 101 permit ip any any ! ! ! ipx router eigrp 100 network 1000 ! ! ipx router rip no network 1000 ! ! ! banner motd ^C This is Router 3 ^C ! line con 0 exec-timeout 0 0 password falcons logging synchronous line aux 0 line vty 0 4 password falcons login ! end R3#
In Example 17-20, the EIGRP configuration has been highlighted. Notice that network 192.168.3.0 is not a part of EIGRP AS 100. It sure is difficult to get good help these days. Someone must have incorrectly removed this network from EIGRP. Correct this error by adding the network back into EIGRP AS 100, saving the configuration, and then doing a show ip eigrp interfaces, as shown in Example 17-21.
R3# conf t Enter configuration commands, one per line. End with CNTL/Z. R3(config)# router eigrp 100 R3(config-router)# network 192.168.3.0 R3(config-router)# ^Z R3# %SYS-5-CONFIG_I: Configured from console by console R3# copy run start Building configuration... [OK] R3#sho ip eigrp int IP-EIGRP interfaces for process 100 Xmit Queue Mean Pacing Time Multicast Pending Interface Peers Un/Reliable SRTT Un/Reliable Flow Timer Routes Se0 2 0/0 114 0/15 50 0 Et0 0 0/0 0 0/10 0 0 R3#
Now you see that R3's Ethernet 0 network of 192.168.3.0 is being advertised in EIGRP process 100. You can verify that R4 receives this route as you expect by returning to R4 and doing a show ip route 192.168.3.0, as demonstrated in Example 17-22.
R4# show ip route 192.168.3.0 Routing entry for 192.168.3.0/24 Known via "eigrp 100", distance 90, metric 2195456, type internal Redistributing via eigrp 100 Last update from 192.168.100.3 on Serial0, 00:04:15 ago Routing Descriptor Blocks: * 192.168.100.3, from 192.168.100.3, 00:04:15 ago, via Serial0 Route metric is 2195456, traffic share count is 1 Total delay is 21000 microseconds, minimum bandwidth is 1544 Kbit Reliability 255/255, minimum MTU 1500 bytes Loading 1/255, Hops 1 R4#
R4 has now received this route, which was learned through 192.168.100.3, as highlighted. Now ping 192.168.3.3 from R4, as shown in Example 17-23.
R4# ping 192.168.3.3 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.3.3, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 60/60/60 ms R4#
You got 100 percent success! You have successfully resolved this issue.
Top |