Trying to ping a device

veritas_libertas

Yes I couldn't come up with a more creative title. Sorry. I've been playing a round with my routers and switches trying to come up with some creative labs. I switched my home network to a Class B in order to be able to interface with my lab more easily. For some reason though I can't ping from Router A to any device on subnet that my local network is on. Below is a rough drawing of my lab and network. I've also attached the startup-config. Any idea what I'm doing wrong?




Router A

Building configuration...

Current configuration : 863 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Router
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
no network-clock-participate slot 1
no network-clock-participate wic 0
ip cef
!
!
!
!
ip auth-proxy max-nodata-conns 3
ip admission max-nodata-conns 3
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
interface FastEthernet0/0
no ip address
shutdown
duplex auto
speed auto
!
interface Serial0/0
ip address 172.16.1.65 255.255.255.192
encapsulation ppp
clock rate 8000000
!
interface FastEthernet0/1
no ip address
shutdown
duplex auto
speed auto
!
router rip
version 2
network 172.16.0.0
!
ip forward-protocol nd
!
!
no ip http server
no ip http secure-server
!
!
!
!
control-plane
!
!
!
!
!
!
!
!
!
!
line con 0
line aux 0
line vty 0 4
login
!
!
end

Router B

C2651XM-2#sho run
Building configuration...

Current configuration : 904 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname C2651XM-2
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
!
resource policy
!
no network-clock-participate slot 1
no network-clock-participate wic 0
ip subnet-zero
!
!
no ip dhcp use vrf connected
!
!
ip cef
no ip ips deny-action ips-interface
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
interface FastEthernet0/0
ip address 172.16.1.62 255.255.255.192
duplex auto
speed auto
!
interface Serial0/0
ip address 172.16.1.66 255.255.255.192
encapsulation ppp
no dce-terminal-timing-enable
!
interface FastEthernet0/1
no ip address
shutdown
duplex auto
speed auto
!
router rip
version 2
network 172.16.0.0
!
ip classless
!
!
no ip http server
no ip http secure-server
!
!
!
!
control-plane
!
!
!
!
!
!
!
!
!
!
line con 0
line aux 0
line vty 0 4
!
!
end

fsanyee

router rip
no auto-summary

veritas_libertas

Okay, so I looked up auto-summary, but I'm not sure I truly understand what it does. Cisco's web site doesn't seem to make a big mention of it, and neither does Odom or Lammle.

I made the change but I still can't ping or access anything on the 172.16.1.0 subnet.

jamesp1983

fsanyee wrote: »

router rip
no auto-summary

x2. there are some really good gotchas in Routing TCP/IP volumes surrounding this topic.

jamesp1983

veritas_libertas wrote: »

Okay, so I looked up auto-summary, but I'm not sure I truly understand what it does. Cisco's web site doesn't seem to make a big mention of it, and neither does Odom or Lammle.

I made the change but I still can't ping or access anything on the 172.16.1.0 subnet.

have you tracerouted from end to end? Also, try debug ip packet detail. (don't do this in production unless you filter). check your route tables "sh ip route". Make sure you're seeing the right prefix/mask combos.

NetworkVeteran

fsanyee wrote: »

router rip
no auto-summary

That will have no effect. From a classful perspective, all router interfaces are on 172.16.x.x and its subnets.

I still can't ping or access anything on the 172.16.1.0 subnet.

This is a good opportunity to work on your debugging skills. You want to ID where the packets are being dropped and why. To this end, use traceroute. You can also use CDP to verify that L1/L2 links are up, and "show ip route" to verify L3 paths at each hop.

veritas_libertas

jamesp1983 wrote: »

have you tracerouted from end to end?

The last time I did that I had to stare at line after line of *****. I found this really odd, and I'm not sure why it would happen.

jamesp1983 wrote: »

Also, try debug ip packet detail. (don't do this in production unless you filter).

Router>en
Router#debug ip packet detail
IP packet debugging is on (detailed)
Router#ping 172.16.1.5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.5, timeout is 2 seconds:

*Mar 1 01:14:01.872: IP: tableid=0, s=172.16.1.65 (local), d=172.16.1.5 (Serial0/0), routed via FIB
*Mar 1 01:14:01.872: IP: s=172.16.1.65 (local), d=172.16.1.5 (Serial0/0), len 100, sending
*Mar 1 01:14:01.872: ICMP type=8, code=0.
*Mar 1 01:14:03.875: IP: tableid=0, s=172.16.1.65 (local), d=172.16.1.5 (Serial0/0), routed via FIB
*Mar 1 01:14:03.875: IP: s=172.16.1.65 (local), d=172.16.1.5 (Serial0/0), len 100, sending
*Mar 1 01:14:03.875: ICMP type=8, code=0.
*Mar 1 01:14:05.879: IP: tableid=0, s=172.16.1.65 (local), d=172.16.1.5 (Serial0/0), routed via FIB
*Mar 1 01:14:05.879: IP: s=172.16.1.65 (local), d=172.16.1.5 (Serial0/0), len 100, sending
*Mar 1 01:14:05.879: ICMP type=8, code=0.
*Mar 1 01:14:07.878: IP: tableid=0, s=172.16.1.65 (local), d=172.16.1.5 (Serial0/0), routed via FIB
*Mar 1 01:14:07.878: IP: s=172.16.1.65 (local), d=172.16.1.5 (Serial0/0), len 100, sending
*Mar 1 01:14:07.878: ICMP type=8, code=0.
*Mar 1 01:14:09.881: IP: tableid=0, s=172.16.1.65 (local), d=172.16.1.5 (Serial0/0), routed via FIB
*Mar 1 01:14:09.881: IP: s=172.16.1.65 (local), d=172.16.1.5 (Serial0/0), len 100, sending
*Mar 1 01:14:09.881: ICMP type=8, code=0.
Success rate is 0 percent (0/5)
Router#
*Mar 1 01:14:11.199: IP: s=172.16.1.66 (Serial0/0), d=224.0.0.9, len 52, rcvd 2
*Mar 1 01:14:11.199: UDP src=520, dst=520no debug all
All possible debugging has been turned off
Router#

veritas_libertas

NetworkVeteran wrote: »

That will have no effect. From a classful perspective, all router interfaces are on 172.16.x.x and its subnets.

That's what I thought as well.

NetworkVeteran wrote: »

This is a good opportunity to work on your debugging skills. You want to ID where the packets are being dropped and why. To this end, use traceroute. You can also use CDP to verify that L1/L2 links are up, and "show ip route" to verify L3 paths at each hop.

I can ping/access Router B fine, and ping it from Router A and Subnet 172.16.1.0 fine. I'm perplexed, and I'll admit a little embarrassed.

fadhil

In fact there are many problems in your configuration that is why, when you ping it doesn't give a result. some of your problems:- 1. You did subnetting but still you have problem of how to subnet. 2.You didn't configure in your interfaces like fa0/1. 3.you used a default network address instead of subnetwork address in your configuration while you did subnetting. in fact you didn't configure the way it suppose to be.

NetworkVeteran

fadhil wrote: »

1. You did subnetting but still you have problem of how to subnet.

Let's see... for the serial link he used: 172.16.1.65 255.255.255.192 & 172.16.1.66 255.255.255.192. Those match! For the Ethernet link, he used 172.16.1.62 255.255.255.192. That's a different subnet!

The routers don't care what he knows / doesn't know.

2.You didn't configure in your interfaces like fa0/1.

Yes, the interface names on the devices are at odds with the interface names in the diagram.

3.you used a default network address instead of subnetwork address in your configuration while you did subnetting. in fact you didn't configure the way it suppose to be.

You don't have to do this at all. If you specify the major, classful network address any interfaces that belong to it or its subnets are added to the RIP routing process. Heck, with RIP, just try typing a subnet and see what happens!

veritas_libertas

NetworkVeteran wrote: »

Yes, the interface names on the devices are at odds with the interface names in the diagram.

That would be my fault. The software I was using for diagramming didn't allow S0/0 or FA0/0 as a drop down option.

fadhil

k. fine but I think for my knowledge there is a problem is subnetting because a network of the serial links have the same subnet mask of the network of interface fa 0/1.

NetworkVeteran

veritas_libertas wrote: »

I can ping/access Router B fine, and ping it from Router A and Subnet 172.16.1.0 fine.

Work up the layers.

L2: If you're certain you can ping RouterB from both RouterA and the switch--then L2 is up. If you're not certain, you can re-verify, or so a "show cdp neighbor" on each device.

L3: "sh ip route" becomes critical to verify each device has the right routes. If they're missing anything, you could use the RIP show or debug commands to ID what might be going wrong, though they're not as nice as other protocols

veritas_libertas

NetworkVeteran wrote: »

Work up the layers.

L2: If you're certain you can ping RouterB from both RouterA and the switch--then L2 is up. If you're not certain, you can re-verify, or so a "show cdp neighbor" on each device.

L3: "sh ip route" becomes critical to verify each device has the right routes. If they're missing anything, you could use the RIP show or debug commands to ID what might be going wrong, though they're not as nice as other protocols

That's what I'm figuring it has be. I'm still learning, but the Route tables appear to be good to me. I'll post them below:

Router A:

Router#sh ip route
Codes: C - connected, S - static, 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
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks
R 172.16.1.0/26 [120/1] via 172.16.1.66, 00:00:15, Serial0/0
C 172.16.1.64/26 is directly connected, Serial0/0
C 172.16.1.66/32 is directly connected, Serial0/0
Router#


Router B:

C2651XM-2#sh ip route
Codes: C - connected, S - static, 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
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks
C 172.16.1.0/26 is directly connected, FastEthernet0/0
C 172.16.1.65/32 is directly connected, Serial0/0
C 172.16.1.64/26 is directly connected, Serial0/0
C2651XM-2#



I do have a question about the routing tables. Why does it say "172.16.0.0/16 is variably subnetted?"

NetworkVeteran

fadhil wrote: »

k. fine but I think for my knowledge there is a problem is subnetting because a network of the serial links have the same subnet mask of the network of interface fa 0/1.

Let's see... for the serial link he used: 172.16.1.65 255.255.255.192 & 172.16.1.66 255.255.255.192.

The major network is 172.16.0.0/16. He's chosen to use the /26 subnet mask of 255.255.255.192. This mask allows upto (64-2=) 62 hosts per subnet. 172.16.1.0, 172.16.1.64, 172.16.1.96, etc. are all valid subnets when using that mask.

172.16.1.65 & 172.16.1.66 are both valid host addresses on the 172.16.1.64/26 subnet.

172.16.1.62 is a valid host address on the 172.16.1.0/26 subnet.

I hope that makes sense! .

NetworkVeteran

What about the device on 172.16.1.0/26 that you're pinging... does it have its default gateway set?

To elaborate, you have to verify L3 on all devices. Given the routing table you showed, it's very likely the pings from RouterA are reaching RouterB and going out the Fa0/0 interface and then being lost.

jamesp1983

Exactly, just because you have a route to your destination doesn't mean the return path from destination is okay.

veritas_libertas

NetworkVeteran wrote: »

What about the device on 172.16.1.0/26 that you're pinging... does it have its default gateway set?

To elaborate, you have to verify L3 on all devices. Given the routing table you showed, it's very likely the pings from RouterA are reaching RouterB and going out the Fa0/0 interface and then being lost.

The light-bulb glowed so bright when you said that it wasn't even funny

My network's DHCP server, the WRT54G, is assigning the ISP modem's IP as the default-gateway to every client. For this reason an ICMP packet is not going to be headed back in the direction it needs to, right? So I turned on one of my 2950s and pointed the default-gateway back to Router B, and plugged-in Router B's FA0/0 to one of the 2950's ports. After that I could ping from the 2950 to Router A and vice-versa.

Is my theory on why this fixed the problem correct?

NetworkVeteran

veritas_libertas wrote: »

Is my theory on why this fixed the problem correct?

That sounds very plausible.

If your clients happen to be PCs, you can add static routes to them, to direct non-Internet traffic towards your Cisco routers. (For example, in Windows, type "Cmd" at the Run menu to get to a DOS prompt, and then type ROUTE HELP.) You might also consider putting your Cisco routers between your clients and your Internet router, if you're comfortable configuring DHCP and their performance doesn't negatively impact your Internet experience.

veritas_libertas

@NetworkVetern and jamesp1983: Thanks for your help troubleshooting my lab problem. I believe I learned something valuable, and I'm happy to see at least my subnetting was on track.