Strange ARP operation
Strange ARP operation
(OP)
Perhaps someone can explain what seems to me to be some strange operation in the ARP cache on at least 1 XP pro client:
While reviewing some network logs on a minor broadcast storm, I noticed that many clients were asking for an arp resolution for our router within a few second period.
I grabbed one of the clients involved and looked at its arp table. The default gateway's address was not in the arp table.
I pinged www.google.com to force a packet to the router, and the gateway entry was cached - just like you'd expect.
BUT, less than 3 minutes later it was gone again!
I repeated the test and got the same results - including the entry dropping out in <3mins.
I repeated the test again, but this time used googles IP address rather than domain name. This time, the GW address didn't even cache!
This seems most confusing. I checked the NetBT timeout entry in the registry and it was at its usual 10 mins - I expanded it to 20 with no change in the above tests.
The DNS server for the client is on the same subnet as the client so resolving www.google.com should not force a request for the GW address.
Can anyone explain what is going on here? It is not at all the behaviour I expect with ARP.
Thanks!
While reviewing some network logs on a minor broadcast storm, I noticed that many clients were asking for an arp resolution for our router within a few second period.
I grabbed one of the clients involved and looked at its arp table. The default gateway's address was not in the arp table.
I pinged www.google.com to force a packet to the router, and the gateway entry was cached - just like you'd expect.
BUT, less than 3 minutes later it was gone again!
I repeated the test and got the same results - including the entry dropping out in <3mins.
I repeated the test again, but this time used googles IP address rather than domain name. This time, the GW address didn't even cache!
This seems most confusing. I checked the NetBT timeout entry in the registry and it was at its usual 10 mins - I expanded it to 20 with no change in the above tests.
The DNS server for the client is on the same subnet as the client so resolving www.google.com should not force a request for the GW address.
Can anyone explain what is going on here? It is not at all the behaviour I expect with ARP.
Thanks!
RE: Strange ARP operation
I'm not sure why you it was no longer in the cache earlier on in your post. Are you sure you are not mistaken bacause the theory says that this is impossible. There is no way you can get a reply from an internet IP via ping if you PC can't resolve the default gateways IP to MAC via ARP.
Take a look at my IT blog guides, knowledgebase and technical resources at http://think-like-a-computer.com
RE: Strange ARP operation
Instead, it only cached it for the domain name.
So, that makes no sense,
and the fact that the entry only stayed in the arp cache for 3 mins makes no sense,
The 3 minute arp cache time makes for a lot of unnecessary arp traffic.
Another piece of information is that I performed the same ping test to a local client and that one fell off the cache in <3 mins too. I wanted to prove to myself that it wasn't just the router address that was affected...
thanks for your comments - any help is appreciated...
RE: Strange ARP operation
Maybe this is the default.
Can you say where the reg key is? You mention the NetBT entry. I am assuming this means it is related to NetBIOS without knowing the full reg key path. If so then this vaule will have nothing to do with your ARP cache time as NetBIOS is used to resolve names to IP not IP to mac. Am I missing something?
Also have you redone the test just make sure? As in queried and outbound IP then check the ARP table, then do the same for the DNS name AFTER the ARP entry has expired.
Just an idea what could have happened...What if your first query cached the mac in the ARP table. Then by the time you looked through your table and pinged the DNS name it was close to 3 mins so it resolved the IP via the cache, let's say 2:50. 10 seconds later you pull up your ARP table again but by now it is over 3 mins and the entry has expired so it shows it is no longer there...???? A possibility?
This is why I am saying try the test again but force it to clear the cache after your first ping using the following:
arp -d *
Let me know the outcome.
Take a look at my IT blog guides, knowledgebase and technical resources at http://think-like-a-computer.com
RE: Strange ARP operation
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters
You are correct - this is for the netbios cache - I wasn't paying close enough attention. Thanks for catching me.
On your last paragraph, I'm not sure what you're saying. This is the batch file I use to test on a remote client:
REM %1 remote client to test on
REM %2 host or address to arp resolve
REM %3 pause between arp table checks (after a 100 second default pause)
REM Snapshot ARP to prove address isnt already in table
psexec \\%1 cmd /c arp -a
REM ping address to add to arp table
psexec \\%1 cmd /c ping %2
REM Snapshot ARP to prove address is in table
psexec \\%1 cmd /c arp -a
REM Show time address went into arp table
echo.|time|find "current"
REM Wait a default 100 seconds before beginning to watch table
sleep 100
REM Scan table 300 times once every %3 mins
for /l %%i in (1,1,100) do (psexec \\%1 cmd /c arp -a) & (echo.|time|find "current") & (sleep %3)
REM END
and actually when I use this method with both googles domain name and IP address, I see exactly what I expect to see (both cache arp) - so that looks ok. Maybe you're right about why it didnt before.
So that brings us back to: Can the Arp timeout be adjusted? Our network topology is pretty stable and 3 mins is shorter than it needs to be.
Thanks for your help
RE: Strange ARP operation
The bit you need os ArpCacheLife and it describes exactly what you said about it being 2 minutes.
On my last paragraph what I mean is that maybe you pinged the DNS name close to 3 mins after the first ping. What this means is that the first ping cached the arp entry and a timer was now on it counting down from 3 mins. Your second ping DID NOT refresh the timer on the cached record and because it was cached this is how it resolved it the second time. This second ping you did at say 2:55 after the first ping (close to the 3 min timeout). THEN by the time you checked the ARP table again to see if it was cached it had expired. This is because on the second ping you may done done it at 2:55 so there was only 5 seconds left for it to stay in the cache. By the time you checked the arp cache again 10 secs later it had expired. This would give the illusion to you that it wasn't caching the mac when you did the second ping. Does that make sense now?
Glad to have helped.
Take a look at my IT blog guides, knowledgebase and technical resources at http://think-like-a-computer.com