ICMP no reply

[aconticisco]

Hello,

I am trying to test connectivity by ping an ip address but I am not getting any reply look ...

Router#ping www.mirc.com

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

When I ping the same address from another pc connected to the same segment it receives the reply fine.

Is there any config that regards this issue ?

Thanks

[johnlloyd_13]

ACL perhaps? can you post your running config and traceroute to the said website? make sure you have configured DNS on your router using the command ip name-server .

[ashok_boin]

Hi,

Yes, the tracert from both PC and router would help. I would recommed another "tracert" from local Ethernet interface (where PC segment is connected) as source interface in Extended ping. There is no name look up issue in your router as it has already translated to IP address.

And also, I would like to share  one important difference between Cisco and Windows traceroute  commands.

Traceroute of Cisco  uses UDP packets (TX) with increment in PORT number for EACH packet  (it won’t be constant at  33434, try “debug ip udp” while tracing) starting  from 33434 and increasing TTL value by default and trace the path using ICMP  Time exceeded messages from in between hops and ICMP port unreachable message  from the final destination.

Tracert of Windows uses  completely ICMP echo packets with increasing TTL and trace the path with ICMP  time exceeded messages from in between hops or ICMP echo reply from the final  destination.

Final conclusion is if  UDP packets are blocked and ICMP packets are allowed completely, then you can  trace from Windows and not from Cisco router and vice versa.

For Windows, if you are  able to ping, then you should able to trace perfectly as it completely depends  upon ICMP.

Regards...

-Ashok.

[aconticisco]

checked from wireshark and I get:

106    87.699025    Cisco_c1:58:14    Broadcast    ARP    Who has 209.240.130.48?  Tell 192.168.1.10  for every ping

here is the show run:

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 209.240.130.48, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
RouterA#show run
Building configuration...

Current configuration : 574 bytes
!
version 12.2
service timestamps debug uptime
service timestamps log uptime
service password-encryption
!
hostname RouterA
!
enable secret 5 $1$8.M1$kkl.MDa2sLa8Yx19.CN56/
!
ip subnet-zero
ip name-server 194.158.37.196
ip name-server 194.158.37.211
!
!
!
!
interface Ethernet0
ip address 192.168.1.10 255.255.255.0
!
interface Serial0
ip address 192.168.4.1 255.255.255.0
clockrate 38400
!
ip default-gateway 192.168.1.254
ip classless
ip route 0.0.0.0 0.0.0.0 Ethernet0 permanent
no ip http server
!
!
line con 0
line vty 0 4
password 7 1046100C0B131302
login
!
end

[marikakis · Accepted solution]

Your configuration includes the command "ip route 0.0.0.0 0.0.0.0 Ethernet0 permanent". The recommended practice for static routes that point to broadcast interfaces is to use both outgoing interface and next-hop IP address (propably 192.168.1.254 in your case)

e.g. ip route 0.0.0.0 0.0.0.0 Ethernet0 192.168.1.254

Please see: http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a00800ef7b2.shtml#background

With the static you have configured (i.e. without a next-hop IP address) your router (as seen in whireshark output) ARP's for a destination IP address that is not in the local subnet (that is the web site's address). This configuration requires the default gateway used by this router to support proxy ARP. Use of proxy ARP is considered bad practice (bad design, performance issues, etc). If your gateway doesn't have proxy ARP enabled, you will get no response to the ARP and your ping will fail. A PC that has the gateway's IP address configured will succeed with the ping (if no other issues exist of course).

So, as a first step, try to configure the static route with a next-hop IP address. If problem persists, please post traceroute/tracert output (from the router/PC respectively). When pings succeed it's nice to see the exclamation marks telling us that we did a good job, but when the dots appear, ping doesn't reveal much to further troubleshoot the issue.

Message was edited by: marikakis (changed mistaken word 'with' to 'without' in 1st line of 2nd paragraph)

[jimmysands73_2]

>>When I ping the same address from another pc connected to the same segment it receives the reply fine.

If another PC along the same segment is not displaying the same behavior, I would concentrate on the PC in question, while you probably already did this, have you checked the firewall settings on the machine in question?

[aconticisco]

Jimmysands73 sorry maybe it is my fault since I was not clear enough....

The following was being done from the cisco router

I am trying to test connectivity by ping an ip address but I am not getting any reply look ...

Router#ping www.mirc.com

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

then I used 1 pc to test  the ping to the site which worked fine, so I was comparing the router to the pc and not the pc with another pc.

Thank you all for the feedback

[aconticisco]

That was it !! I am copying results here, this means that ARP cache was not enabled/supported on the router. I just wonder how actually got the domain name resolved if it could not even get past the router.

Type escape sequence to abort.
Tracing the route to www.mirc.com (209.240.130.48)

  1  *  *  *
  2  *  *  *
  3  *
RouterB#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
RouterB(config)#ip route 0.0.0.0 0.0.0.0 eth
RouterB(config)#ip route 0.0.0.0 0.0.0.0 ethernet 0 192.168.1.254
RouterB(config)#^Z
RouterB#p
00:56:34: %SYS-5-CONFIG_I: Configured from console by consol
RouterB#tra
RouterB#traceroute www.mirc.com

Type escape sequence to abort.
Tracing the route to www.mirc.com (209.240.130.48)

  1  *
    dsldevice.lan (192.168.1.254) 68 msec *
  2 192.168.180.10 24 msec *  24 msec
  3  *
    217.22.189.129 24 msec *
  4 ge2-0-15-int-bkara1.datastream.com.mt (217.15.97.226) 32 msec *  20 msec
  5  *
    pos4-2-1.palermo6.pal.seabone.net (195.22.198.165) 32 msec

[marikakis]

I completely share your enthusiasm and thank you for your feedback.

ARP cache is supported. Gateway just doesn't generally respond to ARP requests for remote IP addresses such as the remote IP address of the website you are trying to ping (and your router shouldn't generally need to issue such ARP requests). Now, how the domain name of the website was actually being resolved is a good question. I cannot be sure of what's happening in your case, but sometimes in DSL setups the associated devices have some cool features not commonly found in routers that might be doing the specific trick. In my home network for example, I have configured my laptop to use the DSL modem as a DNS server. When modem sees the DNS request addressed to it, modem has the information of the real DNS server and forwards the request to it. So, maybe when you ARP for the DNS server (found on another subnet), upstream device selectively responds to such a request (but doesn't do that for other generic remote IP addresses). But again, I can't be sure. It depends on how the ISP network is configured.

[jimmysands73_2]

I am curious now....

The orginial poster wrote that it didnt happen to every computer on the segment, so why would that happen?

[marikakis]

From what I understood: there was a router and a PC connected to the same segment, but the PC was not accessing the site via that router. Both devices would access the internet using a third device positioned "in front of" them as a getaway. The PC had the IP address of the gateway configured, so, to reach a site not in the local subnet, it would ARP for the gateway's address. The router, on the other hand, was ARPing for the remote site's IP address because of that static route. Such a configuration requires that the gateway supports proxy ARP (which doesn't seem to be entirely the case here).

The DNS resolution of the site's address is not very clear, but in any case, if you do find one problem, it's generally good to fix it, because sometimes it just confuses the issue (you don't know what is causing which symptom), and other times it magically fixes everything. There were no risks involved in changing that static.

[jimmysands73_2]

Thank you for that clarification.