Hello there, Don, ARP cache woes! Got too much cache? ;) : Now I move the host down to the other side of the firewall, which is : doing arp proxy. In order to do that, of course, I have to add a : route to the firewall. So, in short, you have a router which is caching a link layer address much longer than you want. I, too, have had this problem in the past, and, when I am in control of the router, I kick it. When I'm not in control of it, I have called the person (in the colocation facility, at the site, in the data center) who is in control and have that person kick the router. Not so long ago, I became aware that some routers, contrary to my expectations, actually obey gratuitous ARP. I have only tested this on linux boxen, so I don't know how other operating systems handle gratuitous ARP and link layer address caching. : [.... the ] timeout on the router is 4 hours (!!) (Is this common? : Or even reasonable? Anyone know what values are in common use?) I do not find 4 hours to fall in the range of a reasonable ARP cache lifetime. ARP doesn't consume very much bandwidth. This is ethernet, after all. : I notice rfc1122 (p22) suggests timeouts on the order of a minute, : which is what I expected. Yes, dozens of seconds to several minutes seems a reasonable neighbor table lifetime. : Even better would be some mechanism that, when we add the route to the : firewall could figure out who on either end should be sent such : packets. Automated or manual? If you are manually adding the route, you could use arping to create a gratuitous ARP frame. If the router respects gratuitous ARP, your task is done. If not, then I can see only one alternative. Sharpen up your steel-toe boots, and give that router a kick. Automated? Well....if you can do it manually, you should be able to trigger it automatically, right? : Perhaps it could remember all of the arp requests that it had : seen (these are, after all, sent to broadcast, so it wouldn't need to : be in promiscuous mode) it could see from the new route (1) which ip : addresses had been used in that range, (2) which ip addresses those : addresses had tried to talk to directly. I'm not quite sure what you mean here... : I'll be interested in any other ideas, and even more interested in : anything that has already been implemented to solve this problem. I'd suggest send_arp in the fake software from the linux-ha project [1] (here's an article showing send_arp for address takeover [2]). If you don't wish to compile, arping [3] works marvelously for creating gratuitous ARP frames [4]. -Martin [1] http://www.linux-ha.org/failover/ http://www.vergenet.net/linux/fake/download/latest/ [2] http://www.onlamp.com/pub/a/onlamp/2003/04/03/linuxhacks.html [3] http://linux-ip.net/html/tools-arping.html [4] http://linux-ip.net/html/ether-arp.html http://linux-ip.net/html/ether-arp.html#ex-ether-arp-gratuitous -- Martin A. Brown --- SecurePipe, Inc. --- mabrown@xxxxxxxxxxxxxx
