Strange ARP operation 1

[keithja]

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

http://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

http://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!

 

[muckermucker]

This is behaving as it should...At least with your last statement about DNS. Although DNS resolves the name to IP you are still pinging google from YOUR machine therfore it has to route the traffic out to the internet. How does it do that? by sending to the default gateway. In order to do that it resolves the dafault gateways IP to it's mac address and then stores it in the ARP cache so this is why it is there.

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

 

[keithja]

The DNS side is clear. I agree this part of the behaviour is ok as far as DNS operation. The curious part of the dns statement was the fact that both with, and without requiring DNS resolution, it should have needed the mac address of the router so it could route the ping to the router -then out to the internet. In which case both by IP and by Domain name, it should have recached the arp entry for the router mac.

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

 

[muckermucker]

So you are saying that when you ping other IP's on the network they also only stay in the cache for 3 mins?
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

 

[keithja]

Yes

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

 

[muckermucker]

For XP look here at this MS technet article

http://technet.microsoft.com/en-us/library/cc739819(v=ws.10).aspx

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