Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

ICMP no reply

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

1 ACCEPTED SOLUTION

Accepted Solutions

Re: ICMP no reply

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)

11 REPLIES

Re: ICMP no reply

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 .

Bronze

Re: ICMP no reply

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.

With best regards... Ashok ----------- Pls kindly rate if helpful or answered your question.
New Member

Re: ICMP no reply

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

Re: ICMP no reply

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)

Re: ICMP no reply

>>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?

New Member

Re: ICMP no reply

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

New Member

Re: ICMP no reply

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

Re: ICMP no reply

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.

Re: ICMP no reply

I am curious now....

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

Re: ICMP no reply

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.

Re: ICMP no reply

Thank you for that clarification.

3101
Views
0
Helpful
11
Replies