Joe said:
Herb -
I guess I wasn't making myself clear. Aside from the vlan config
picture this. You have a server with an ip address of 10.0.13.120
255.255.255.0. From this server you can basically ping anything via
IP or DNS in the 10.0.13.x network.
Ok, same subnet works. That is what you said to start.
You can also ping any server in
the company no matter what routable subnet it is on via IP.
If it worked by DNS this would mean that routing works AND
DNS resolution works.
If DNS ONLY fails when not on the same subnet then this
points towards broadcast name resolutions as the reason for
different results.
This is what you said to start, but is NOT what you said
in your most recent message. (It would have been quicker
for you to just post your IP and subnet masks to start.)
And say "ping by address" and "ping by DNS name" each
time you gave a result (works, fails.)
However you cannot ping them through DNS.
Pings NEVER work "through DNS" but first resolves
the DNS name to an IP so once you know that DNS
resolution is failing (you do from the information above)
then you focus SOLELY on that until (and unless) you
find you were wrong in that estimation.
This is the only server on the
switch/network that is having this problem. It recently had the IP
address changed. NSLOOKUP works fine. Below is a tracert
Give me the results for the NSLookup commands I suggested.
(Don't just tell me it works find -- and give me a way to tell
that you tried EVERY DNS server the client uses.)
C:\>tracert 10.0.2.25
Tracing route to CPSPAD11 [10.0.2.25]
DNS works. See that above? It says DNS resolves the
name CPSAD11 to 10.0.2.25
So you are back to a routing (or related issue.)
over a maximum of 30 hops:
1 <10 ms <10 ms <10 ms 10.0.13.1
2 <10 ms <10 ms <10 ms CPSPAD11 [10.0.2.25]
Trace complete.
And tracert works.
C:\>ping cpspad11
Unknown host cpspad11.
Wait a minute. This (almost) cannot happen. Clearly it
DID happen but it makes no sense.
As you can see if does resolve the name there but will not ping it by
name.
No, what you posted shows it FAILING to resolve the name.
Tracert and Ping use the same name resolution method
AND the same ICMP network protocal -- although one
of them might fail or have problems the other doesn't
see (timeouts, blocked by firewalls, etc) they both should
either succeed or fail on the name resolution.
First, I would try each of the above multiple times and
CLEAR the client cache between attempts. (Even negative
answers are cached.)
If this gives the same (weird) results you have proven a consistent
difference.
IF not then you are back to a likely case of using TWO DIFFERENT
sets of DNS names and when one of them fails it gets cached for
a few minutes giving intermittent failures while when the other
succeeds that caches the success for some time.
IF it does give the same problems then perhaps you are seeing
some weird switch problem or packet filtering on the switch.
Although most such filters would block or allow both Ping
and ICMP equally this is NOT a 100% case.
I have performed an ipconfig/flushdns several times. Not
getting cranky but I did manually edit my ipconifg/all above but took
great care in doing so. Although I did not do the nslookup
specifically as you suggested, the result was the same from all 6 DNS
servers in the domain. DNS is fine.
No, if the results above are accurately reported you have
SOME (although very weird) client-server DNS issue.
Do you really have SIX DNS servers configured for the
clients NIC->IP settings?
(I don't care how many EXIST, only how many the DNS client
knows about.)
If you do, the odds are VERY high that you are using DNS
servers from two (DIFFERENT) sets which give different
answers. (This is part of why I want to SEE the full IPConfig
and not some edited version, but there are many other things
that we can pick up from seeing the actual results and not
your interpretations of those.)
DNS clients PRESUME that EVERY DNS server will return
the SAME, and the CORRECT, results.
The machine will ping another
machine on any subnet but will only ping them USING DNS if it is on its
own subnet.
Then it's about RESOLVING DNS and not primarily about
the Ping.
Although in the weird category you could have a virus/trojan
(unlikely) in your Ping command or some weird filter (more
likely) on the Switch which blocks the request from the Ping
command but not from the Tracert.
However this latter is NOT VERY likely since both commands
use the "built-in DNS resolver". This is UNLIKE NSLookup
which uses its own resolver (i.e., IS its own resolver.)
