Trying to ping a device

veritas_libertasveritas_libertas CISSP, GIAC x5, CompTIA x5Greenville, SC USAMember Posts: 5,735 ■■■■■■■■■■
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
Currently working on: Linux and Python

Comments

  • fsanyeefsanyee Member Posts: 171
    router rip
    no auto-summary
  • veritas_libertasveritas_libertas CISSP, GIAC x5, CompTIA x5 Greenville, SC USAMember Posts: 5,735 ■■■■■■■■■■
    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.
    Currently working on: Linux and Python
  • jamesp1983jamesp1983 Member Posts: 2,475 ■■■■□□□□□□
    fsanyee wrote: »
    router rip
    no auto-summary

    x2. there are some really good gotchas in Routing TCP/IP volumes surrounding this topic.
    "Check both the destination and return path when a route fails." "Switches create a network. Routers connect networks."
  • jamesp1983jamesp1983 Member Posts: 2,475 ■■■■□□□□□□
    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.
    "Check both the destination and return path when a route fails." "Switches create a network. Routers connect networks."
  • NetworkVeteranNetworkVeteran Member Posts: 2,338 ■■■■■■■■□□
    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_libertasveritas_libertas CISSP, GIAC x5, CompTIA x5 Greenville, SC USAMember Posts: 5,735 ■■■■■■■■■■
    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#
    Currently working on: Linux and Python
  • veritas_libertasveritas_libertas CISSP, GIAC x5, CompTIA x5 Greenville, SC USAMember Posts: 5,735 ■■■■■■■■■■
    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.
    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.
    Currently working on: Linux and Python
  • fadhilfadhil Member Posts: 200
    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.
  • NetworkVeteranNetworkVeteran Member Posts: 2,338 ■■■■■■■■□□
    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. :p
    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_libertasveritas_libertas CISSP, GIAC x5, CompTIA x5 Greenville, SC USAMember Posts: 5,735 ■■■■■■■■■■
    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.
    Currently working on: Linux and Python
  • fadhilfadhil Member Posts: 200
    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.
  • NetworkVeteranNetworkVeteran Member Posts: 2,338 ■■■■■■■■□□
    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_libertasveritas_libertas CISSP, GIAC x5, CompTIA x5 Greenville, SC USAMember Posts: 5,735 ■■■■■■■■■■
    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?"
    Currently working on: Linux and Python
  • NetworkVeteranNetworkVeteran Member Posts: 2,338 ■■■■■■■■□□
    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! :).
  • NetworkVeteranNetworkVeteran Member Posts: 2,338 ■■■■■■■■□□
    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.
  • jamesp1983jamesp1983 Member Posts: 2,475 ■■■■□□□□□□
    Exactly, just because you have a route to your destination doesn't mean the return path from destination is okay.
    "Check both the destination and return path when a route fails." "Switches create a network. Routers connect networks."
  • veritas_libertasveritas_libertas CISSP, GIAC x5, CompTIA x5 Greenville, SC USAMember Posts: 5,735 ■■■■■■■■■■
    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 icon_lol.gif

    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?
    Currently working on: Linux and Python
  • NetworkVeteranNetworkVeteran Member Posts: 2,338 ■■■■■■■■□□
    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_libertasveritas_libertas CISSP, GIAC x5, CompTIA x5 Greenville, SC USAMember Posts: 5,735 ■■■■■■■■■■
    @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.
    Currently working on: Linux and Python
Sign In or Register to comment.