Re: [LARTC] proxy arp problem

["Martin A. Brown" <mabrown-lartc@securepipe.com>]

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@securepipe.com

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/