Link to home
Start Free TrialLog in
Avatar of Dragon0x40
Dragon0x40

asked on

Ping response different when using host name versus ip address

How can responses be different when using a host name versus an ip address.

Got this same response on two different computers.

C:\>ping XXX.XX.72.119
 
Pinging XXX.XX.72.119 with 32 bytes of data:
 
Request timed out.
Request timed out.
Request timed out.
Request timed out.
 
Ping statistics for XXX.XX.72.119:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
 
C:\>ping xx-xxxxxxx-xxx-x
 
Pinging xx-xxxxxxx-xxx-x.xxx.com [XXX.XX.72.119] with 32 bytes of data:
 
Reply from YYY,YYY.188.65: Destination host unreachable.
Reply from YYY,YYY.188.65: Destination host unreachable.
Reply from YYY,YYY.188.65: Destination host unreachable.
Reply from YYY,YYY.188.65: Destination host unreachable.
 
Ping statistics for XXX.XX72.119:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms
Avatar of Premkumar Yogeswaran
Premkumar Yogeswaran
Flag of India image

Hi,

It is strange...

is the system (XXX.XX.72.119) is in network.. there might be 2 records in DNS.. for this system...

Please restart the machine once and check.. also check in DNS do it have 2 records for this machine...

Thanks,
Prem
premqlitz is most likely right, there are probably 2 records on the routing table. You can try forcing the DNS to flush by performing an
ipconfig /flushdns

Open in new window

, then an
ipconfig /registerdns

Open in new window

.
Avatar of Dragon0x40
Dragon0x40

ASKER

thanks premqlitz and Dave4125,

That is what I don't understand because it looks like DNS resolved the ip address correctly:

Pinging xx-xxxxxxx-xxx-x.xxx.com [XXX.XX.72.119] with 32 bytes of data:

So if DNS correctly resolves the hostname to XXX.XX..72.119 then I would expect the same results when I ping XXX.XX.72.119 but that is not what I get.
I can't recreate the situation because the ip address XXX.XX.72.119 is now responding to pings.

How can this even be possible?
Normally this issue resolves on its own because the routing table on the router is supposed to update without intervention.
From what I can see DNS resolved the hostname to the correct ip address.

I don't see a DNS issue.

What "issue" on the router are you referring to?

Both pings appear to be going to ip address XXX.XX..72.119 which is why I think this is odd?
Have a look at the link below from Microsoft.

http://technet.microsoft.com/en-us/library/cc940095.aspx

thanks JBond2010,

So with the message I received the packet was put on the wire but the router at YYY.YYY.188.65 did not know how to route it.

But why would the router care wether I typed "ping ip address" or  "ping  host name"?

My computer is resolving the host name to the same ip address that I am pinging.

My computer cannot send out a ping until the host name is resolved to an ip address?
This does not make sense to me.

If I ping an ip address then my computer handles this a certain way. Let's call that process "ping". Process "ping" makes a packet with dummy data and puts the ip source and destination addresses on the layer 3 packet headers and then determines whether the destination ip is on the same local subnet as one of my nics so it can send it without a gateway or if it the packet needs to be sent to a default gateway. If the destination is a local subnet then the mac address of the destination host is used on the layer 2 frame but if the destination is remote then the mac address of the default gateway is used on the layer 2 frame.

If I ping the host name then my computer cannot run process "ping" yet because it does not have an ip address. So it runs a process "dnslookup" and resolves the host name to an ip address either through my local cache or contacts a DNS server. Either way, once my computer has the ip address then it would perform process "ping" just like it did when I pinged the ip address.

I don't see why or how there could be a difference.

Of course processes "ping" and "dnslookup" are not real process names but I just use them to make the concept clear about they are two distinct processes that are not interconnected and should not affect each other. Once my computer has the ping request and the ip adress it should not matter whether I supplied the ip address or if I supplied a host name and my computer had to look up the ip address. The same process "ping" gets run both times and the ip address that I typed and the ip address that was resolved from the host name are the same then how can there be a different result?
When you pinged the hostname, your own DNS server resolved the hostname to IP address and your ping went out to that address.  Since your NIC tells your IP stack where to go for DNS queries, then it successfully resolved the hostname since your DNS server is local to your PC.

Now, when you pinged the IP address directly your router won't allow going out past the router and getting a response.  There are 2 reasons this might happen.  Your subnet mask on the client is incorrect - which makes the PC appear to be in another network and go out through the router.  The second (less likely) issue is that your Reverse Lookup Zone holds tainted records for that IP address.

The most likely scenario is a bad subnet mask either on the PC or right at the router for the locally attached subnet.
netman66 is likely on the right path here.

You say that pinging by IP address now works.  This suggests something "broken" in the interim when it failed.  This could include that the host was down, the connection to it broken and, in your case not likely, that ICMP traffic was blocked at the host - which has become rather common.

Pinging by URL requires DNS as others have mentioned.  I would venture to guess that your own DNS server could not get name resolution from the outside and thus it responds with "Destination Host Unreachable" and you see where that message is coming from:  YYY.YYY.188.65.

So, since it's likely that your own gateway router is providing DNS service as well as the path to the remote host, it's a common link in both failures.  I have seen routers "lose their mind" and do very wierd things that can't be explained with any reasoning but was fixed with a reboot of the router.  (For example, reaching some web pages but not others).  Perhaps that's what you had here.
There could also be a third issue.

Does the machine you are pinging FROM have more than one NIC? (either wired or wireless).

It's possible in this scenario (if you have a wired connection AND a wireless connection) that the PC doesn't know where to send and listen for a response since it has 2 paths to the network.
When you said that it's responding to ping now, I assume that means that it's responding to both host namd and ip address pings.

Request timed out means that the PC received no response whatsoever.
Destination host unreachable means that it received an icmp "host unreachable" response from the last router in the path.

Obviously, something was going on with the remote host. But the difference could have been in how your Windows works. When you resolve names in Windows, it does a DNS lookup but it can also do a Netbios lookup. I'm guessing here, but it's possible that when you used the name-- which is probably also registered in your domain-- the echo request may have actually been more than that, which would have resulted in a different response from the remote router.

What I would do (if you want to pursue this) is shut down a PC that you don't need, then try the test again with Wireshark running on your test PC. Check exactly what's going out and coming back. You could also compare the contents of an ICMP request to the domain-registered PC and something on the internet, for example.
thanks Netman66, fmarshall and mikebernhardt,

I pinged a nonexistant host in the same subnet and then tracert to it.

H:\>ping xxx.xx.72.124

Pinging xxx.xx.72.124 with 32 bytes of data:

Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for xxx.xx.72.124:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),


H:\>tracert xxx.xx.72.124

Tracing route to xxx.xx.72.124 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms   [10.224.8.1]
  2    <1 ms    <1 ms    <1 ms  10.0.224.5
  3    <1 ms    <1 ms    <1 ms  10.0.192.5
  4    <1 ms    <1 ms    <1 ms  10.0.192.26
  5    <1 ms    <1 ms    <1 ms  yyy.yyy.188.1
  6    <1 ms    <1 ms    <1 ms  yyy.yyy.188.65
  7     *     yyy.yyy.188.65  reports: Destination host unreachable.

yyy.yyy.188.65 is a virtual firewall.

I attempted to replicate the issue so I modified my host file and put in the host name strangehost.xxx.com (xxx is our actual domain) and when I pinged the host name the response was request timed out.

I then modified the host file with the hostname strangehost but with no domain and then when I pinged I started getting the destination host unreachable which seems exactly opposite of what happened before with the original host?

H:\>ping strangehost

Pinging strangehost.xxx.com [xxx.xx.72.124] with 32 bytes of data:

Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for xxx.xx.72.124:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

H:\>ping strangehost

Pinging strangehost [xxx.xx.72.124] with 32 bytes of data:

Request timed out.
Reply from yyy.yyy.188.65: Destination host unreachable.
Reply from yyy.yyy.188.65: Destination host unreachable.
Reply from yyy.yyy.188.65: Destination host unreachable.

Ping statistics for xxx.xx.72.124:
    Packets: Sent = 4, Received = 3, Lost = 1 (25% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

I wonder if the firewall reports back differently if so many pings within a certain period of time?

It seems that if I wait a while then I get request timed out but then if I ping again right after that I start getting destination host unreachable.

H:\>ping strangehost

Pinging strangehost [xxx.xx.72.124] with 32 bytes of data:

Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for xxx.xx.72.124:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

H:\>ping strangehost

Pinging strangehost [xxx.xx.72.124] with 32 bytes of data:

Reply from yyy.yyy.188.65: Destination host unreachable.
Reply from yyy.yyy.188.65: Destination host unreachable.
Reply from yyy.yyy.188.65: Destination host unreachable.
Reply from yyy.yyy.188.65: Destination host unreachable.

Ping statistics for xxx.xx.72.124:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

H:\>ping strangehost

Pinging strangehost [xxx.xx.72.124] with 32 bytes of data:

Request timed out.
Reply from yyy.yyy.188.65: Destination host unreachable.
Reply from yyy.yyy.188.65: Destination host unreachable.
Reply from yyy.yyy.188.65: Destination host unreachable.

Ping statistics for xxx.xx.72.124:
    Packets: Sent = 4, Received = 3, Lost = 1 (25% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

H:\>ping strangehost

Pinging strangehost [xxx.xx.72.124] with 32 bytes of data:

Request timed out.
Reply from yyy.yyy.188.65: Destination host unreachable.
Reply from yyy.yyy.188.65: Destination host unreachable.
Reply from yyy.yyy.188.65: Destination host unreachable.

Ping statistics for xxx.xx.72.124:
    Packets: Sent = 4, Received = 3, Lost = 1 (25% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

I went back and successfully pinged the original ip xxx.xx.72.119 over and over but the firewall did not ever block that. Maybe there is a rule about only allowing so many pings in a period of time to non-responding hosts and then responding differently after so many?
I doubt there is any such rule on the firewall.  It either blocks or allows ICMP requests.

You need to check the subnet mask on the firewall, your DHCP scope and whatever machine you are using for these tests.  Make sure they are all the same.

You also want to ensure you DO NOT set or give out via DHCP any DNS server IP other than your own local DNS server(s).  You can setup a Forwarder on your DNS server to relay non-authoritive queries to your ISPs DNS server (which is preferred) or rely on Root Hints (which can be buggy at times).

SOLUTION
Avatar of mikebernhardt
mikebernhardt
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
I agree with mike that the firewall is sending the unreachable messages.

Would DNS resolution, subnet mask or DHCP change after the 4th ping?

I have repeated results of the getting destination host unreachable after 4 request timed out messages.

H:\>ping -t xxx.xx.72.124

Pinging xxx.xx.72.124 with 32 bytes of data:

Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from yyy.yyy.188.65: Destination host unreachable.
Reply from yyy.yyy.188.65: Destination host unreachable.
Reply from yyy.yyy.188.65: Destination host unreachable.
Reply from yyy.yyy.188.65: Destination host unreachable.
Reply from yyy.yyy.188.65: Destination host unreachable.
Reply from yyy.yyy.188.65: Destination host unreachable.
Reply from yyy.yyy.188.65: Destination host unreachable.
Reply from yyy.yyy.188.65: Destination host unreachable.
Reply from yyy.yyy.188.65: Destination host unreachable.
Reply from yyy.yyy.188.65: Destination host unreachable.
Reply from yyy.yyy.188.65: Destination host unreachable.
Reply from yyy.yyy.188.65: Destination host unreachable.
Reply from yyy.yyy.188.65: Destination host unreachable.
Reply from yyy.yyy.188.65: Destination host unreachable.
Reply from yyy.yyy.188.65: Destination host unreachable.
Request timed out.
Request timed out.
Reply from yyy.yyy.188.65: Destination host unreachable.
Reply from yyy.yyy.188.65: Destination host unreachable.
Reply from yyy.yyy.188.65: Destination host unreachable.
Reply from yyy.yyy.188.65: Destination host unreachable.
Reply from yyy.yyy.188.65: Destination host unreachable.
Reply from yyy.yyy.188.65: Destination host unreachable.
Reply from yyy.yyy.188.65: Destination host unreachable.
Reply from yyy.yyy.188.65: Destination host unreachable.
Reply from yyy.yyy.188.65: Destination host unreachable.
Reply from yyy.yyy.188.65: Destination host unreachable.
Reply from yyy.yyy.188.65: Destination host unreachable.
Reply from yyy.yyy.188.65: Destination host unreachable.
Reply from yyy.yyy.188.65: Destination host unreachable.
Reply from yyy.yyy.188.65: Destination host unreachable.
Reply from yyy.yyy.188.65: Destination host unreachable.
Request timed out.
Request timed out.
Reply from yyy.yyy.188.65: Destination host unreachable.
Reply from yyy.yyy.188.65: Destination host unreachable.
Reply from yyy.yyy.188.65: Destination host unreachable.
Reply from yyy.yyy.188.65: Destination host unreachable.
Reply from yyy.yyy.188.65: Destination host unreachable.
Reply from yyy.yyy.188.65: Destination host unreachable.

Ping statistics for xxx.xx.72.124:
    Packets: Sent = 44, Received = 36, Lost = 8 (18% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms
Control-C
All of the IP addresses I see here are private addresses.  None of those addresses are supposed to be able to traverse the internet.  Is that consistent with what you're dealing with here?  Which device is yyy.yy.188.65?  

When a packet reaches a router there are various things that can happen:
- although unusual ( if the sendng computer has a smaller subnet that is a sub-subnet of the gateway  router LAN subnet) and, if the packet is destined for an address that's within the router's LAN subnet and outside the sending computer's subnet, it will be sent to the router. Then, many routers will just put the packet back out on the wire.  But, I understand that some routers won't do this and there may be a setting for those types to either allow it or not.
- if the packet is destined for a private address then it may depend on whether the WAN/internet port on the router has a private or public IP address.   And, it may depend on whether the destination address is actually in the WAN/internet port subnet.  For example, if one has two routers in series like this:

Internet Public Address <> 1st Router <> 1st LAN subnet <> 2nd router <> 2nd LAN subnet.

Then, traffic from the 2nd LAN destined for the 1st LAN will be destined by the 2nd router its own port on the 1st LAN.
Traffic from the 1st LAN, destined for the 2nd LAN will not generally get to the 2nd LAN because the 1st router is the gateway for the 1st LAN and it doesn't have a route added to direct traffic for the 2nd LAN to the 2nd router.  
Traffic from either LAN destined for a "foreign" private address should be dropped by the 1st router .. i.e. NOT forwarded out its WAN/Internet port to the internet....
Traffic from either LAN destined for a public IP address will go to the 1st router and forwareded on to the public internet.

Maybe you can get some insight by running a traceroute to that IP in addition to Ping.
H:\>tracert xxx.xx.72.124

Tracing route to 172.16.72.124 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms   [10.224.8.1]
  2    <1 ms    <1 ms    <1 ms  10.0.224.5
  3    <1 ms    <1 ms    <1 ms  10.0.192.5
  4    <1 ms    <1 ms    <1 ms  10.0.192.26
  5    <1 ms    <1 ms    <1 ms  yyy.yyy.188.1
  6    <1 ms    <1 ms    <1 ms  yyy.yyy.188.65
  7     *     yyy.yyy.188.65  reports: Destination host unreachable.
Host that originally was down but is now back up.

H:\>tracert xxx.xx.72.119

Tracing route to xxx.xxx.com [xxx.xx.72.119]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  xxx.xxx.com [10.224.8.1]
  2    <1 ms    <1 ms    <1 ms  10.0.224.5
  3    <1 ms    <1 ms    <1 ms  10.0.192.5
  4    <1 ms    <1 ms    <1 ms  10.0.192.26
  5    <1 ms    <1 ms    <1 ms  yyy.yyy.188.1
  6    <1 ms    <1 ms    <1 ms  yyy.yyy.188.65
  7     1 ms     1 ms    <1 ms  xxx.xxx.com [xxx.xx.72.119]

Trace complete.
I see four separate subnets with at least 3 routers between them and perhaps a firewall or two.  Passing that many interfaces you're bound to drop packets if everything isn't perfectly configured and latency is almost nothing.

Getting a destination host unreachable is normal if ICMP is filtered.
Getting a time out (in this scenario) is possible given the amount of devices and NICs this traffic has to pass through and if any single router or route cache is corrupt or in the middle of being flushed then this will happen.

It looks to be a fairly large network, so these things are likely to happen from time to time.

The important thing is to ensure your WAN links are good - speed and duplex match - and maybe even do some MTU tuning to increase performance.  Keep in mind that if these links are in the cloud then some things are beyond your control.



I don't think that my computer has anything to do with getting either message and it is the firewall that is determining what icmp messages get sent back to my computer.

So if I ping by an ip address or host name my computer works the same but there is one initial step of name resolution that is the only difference. Which is a relief because I thought that maybe I did not understand some basic concept.
I'm not saying your computer has anything to do with it.  I think the only time I mentioned your computer was when I wanted you to check the subnet mask against the router's interface for your subnet.

Other than that, I don't see anything out of the ordinary.

So, what *is* yyy.yyy.188.65 ?  Seems like the last hop before things go awry and it's the last hop to xxx.xx.72.119
ASKER CERTIFIED SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
thanks The--Captian,

Most routers/firewalls don't have this ARP timeout feature?

Most of the time I get "request timed out" messages and don't see the "destination host unreachable".
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
I myself don't often see them outside my own network (see above)

-Jon
If there is no response from a broadcast to a local host on your own subnet then you get request timed out? (There is no router to send icmp message from)

For a remote host the remote router is not configured to send ICMP host unreachables or the ICMP response is filtered on the way back then you also get request timed out?

When the remote router is still attempting to get an arp response it will send back a request timed out but when the remote router stops attempting to get an arp response then it sends a destination host unreachable?

Any articles or reference material with this in it?
Are you testing this all from the same machine?

Please provide an IPCONFIG /all output here from that machine.

Also (if possible), provide the router's LAN interface information.

Everything that you state is happening can be caused by a bad subnet mask - and so far you haven't provided this to us so we could be "guessing" forever as to the problem.

You also have not detailed how your network is configured.  Again, without knowing how you're setup there then all of our responses are simply "best guess".

thanks Netman66,

I was just trying to understand why I received different messages.

No problems with any devices!

SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
A bad subnet mask will make the computer appear to be on a different network than it is - which will cause all the traffic to attempt to go through the router.  Since the firewall is in the way, I'm betting (if it's configured properly) the rules will cause the packet to be dropped because it detects what it thinks is a spoof as the source address is coming into the wrong interface according to the client's wrong mask.  The client computer then needs to depend on it's arp and dns cache once the destination is found.  In time, this gets stale and flushes and the whole thing starts over.

Depending on what the subnet mask is (rather than what it should be), the gateway could also appear to the stack to be on a different network too.  

Either way a mismatched subnet mask causes enough of a headache to warrant looking.  

If we had a look at the ip info from the client, the router and the client's route table we could likely provide a better answer, but as I see it we're guessing right now.

Netman,

I suggest you review the previous comments by the author, especially the traceroute, since it eliminates all of your possibilities.

The traceroute rules out:

- a mask too narrow that the gateway cannot be reached
- a mask too narrow to reach a host that should be on a local subnet
- a mask too wide such that the local machine is attempting to directly deliver the packet

Cheers,
-Jon
Netman - I knew I'd seen you around before - you're the guy who helped me find that driver to insert into my XP install CD via nLite.  Thanks again - it runs great.

Cheers,
-Jon
You're welcome!