arp cache entry timeout/refresh setting.

[James Hunt]

Hi,
is there a setting that controls when the arp cache is renewed ( on hpux11.11) . The network team have asked me to investigate why it seems to be taking 12mins ( or more ) for our server to refresh its arp cache when they failover to another router. The only way we are currently getting around the situation is to manually remove an entry in the server's arp cache via the 'arp -d' command.

any help would be much appreciated.

thanks.

[Peter Godron]

James,
please have a look at:
ndd -get /dev/arp ?

[Peter Godron]

James,
sorry, quick "submit finger".

You may want to investgate the parameters with the previous command, for example:
ndd -get /dev/arp arp_cleanup_interval

[Ivan Krastev · Accepted solution]

There is one NDD parameter regarding this: arp_cleanup_interval

For 11.11 value for this is:
Min - 30000 (30s)
Max - 3600000 (1h)
Def - 300000 (5min)

You can check it with :
ndd -get /dev/arp arp_cleanup_interval

And set it for example to 10 minutes:
ndd -set /dev/arp arp_cleanup_interval 600000


regards,
ivan

[James Hunt]

Thanks everyone - I wasn't aware of this setting.
I've checked the setting and its set to 300000. So this is the default.

Questions:
1) where is this 5 mins default set? Kernel?
There's only one entry in my 'nddconf' - for 'dead gateway detection probe '. So I guess I'd need to add to this entry to nddconf if I wanted to decrease the wait?

2) Will this setting mean that the arp cache is completely cleared every 5 mins? Therefore, if no connection request is made for 10 - 12 mins I will have an empty arp cache until then?


thanks again.

[Ivan Krastev]

You can check the arp-cache with :

ndd -get /dev/arp arp_cache_report


Also if you wand to set it permanent via nnddconf use:

TRANSPORT_NAME[0]=arp
NDD_NAME[0]=arp_cleanup_interval
NDD_VALUE[0]=150000

regards,
ivan

[Bill Hassell]

> Questions:
> 1) where is this 5 mins default set? Kernel?
There's only one entry in my 'nddconf' - for 'dead gateway detection probe '. So I guess I'd need to add to this entry to nddconf if I wanted to decrease the wait?

The default setting is compiled into the driver code. It's not a kernel parameter but part of a (large) number of network-specific settings that are manipulated with ndd. But as these values are in RAM, the nddconf file is needed to make them permanent.

> 2) Will this setting mean that the arp cache is completely cleared every 5 mins? Therefore, if no connection request is made for 10 - 12 mins I will have an empty arp cache until then?

Correct, but you may be surprised at the number of 'background' connections that take place when nothing is happening (NTP, NFS, SNMP, ping, etc)

[James Hunt]

Thanks everyone. Your answers have all been a great help.

This server is very securely tied down - so I don't think thre'll be many background processes. Consequently I think it's quite likely that the length of time we were waiting for the arp cache to update is simply due to the amount of time we were waiting for an arp request for a new connection.

cheers.

[rick jones]

Failing over to another router - so this isn't just speaking to another host on the same LAN, but speaking to a host through a router yes? And this then is the router's IP-MAC mapping we are talking about?

[James Hunt]

Rick, I've spoken to the network guys and their reponse is:
"Yes. Yes. Its the ARP refresh following a failover of the routers that's causing us problems. "


Also,
the arp entry which is causing us problems is also the default gateway. We have 'dead gateway detection probe' turned off. Do these setting conflict in any way? i.e our arp entry for this IP is fixed in cache?
Basically, we seem to be keeping our arp cache entry even though the routers have failed over - but when we remove it via the 'arp -d' we get a new entry ( same IP, different mac ).

Thanks,
again.

[rick jones]

The disabling of dead GW detection shouldn't (IIRC) affect the bahaviour of ARP. There _may_ be some interaction with the "ire" settings in ndd for /dev/ip but that is pure speculation on my part.

I take it that with this router failover there is no gratuitous ARP by the router taking-over the duties?