Re: [LARTC] proxy arp problem

Re: [LARTC] proxy arp problem

[Martin A. Brown]

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/

[LARTC] proxy arp problem

[Don Cohen]

Proxy arp seems to be the right thing for answering arp queries but
it doesn't solve the problem of decaching old cache entries.  Here's
the example:

 router --- hub --- host
             |
          firewall --

The gateway for host is router.  First I use the host to communicate
with the outside world, so it and the router have each other in their
arp caches.

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.
At this point the host and router can not talk to each other because
each is trying to use the mac address in its arp cache.  Ideally I'd
like to solve this problem without having to log in to either the
router or host.  One way, of course, is to wait for the arp caches to
time out.  I thought this was ok, cause I thought these were very
short lived, but in the case I currently face that timeout on the
router is 4 hours (!!)  (Is this common?  Or even reasonable?  Anyone
know what values are in common use?)

I notice rfc1122 (p22) suggests timeouts on the order of a minute,
which is what I expected.

If the host has a shorter timeout then here's a possible solution:
I *suspect* that when a machine sends an arp request to the router:
 from [senderMAC] to [BroadcastMAC] who has [routerIP] tell [senderIP]
the router stores in its arp cache the association [senderIP]=[senderMAC]

Of course, the client machine now sends that packet to the firewall.
The firewall sees this, stores [senderIP]=[senderMAC] in its own
cache, and replies
 [routerIP] is at [MAC of firewall interface connected to client]
What I want to add is that the firewall should also send out the
interface connected to the router:
 from [MAC of firewall interface connected to router] to
 [BroadcastMAC] who has [routerIP] tell [clientIP]
This will then elicit a reply from the router, but in fact the
firewall can ignore that since it will send its own arp request to the
router.

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.  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'll be interested in any other ideas, and even more interested in
anything that has already been implemented to solve this problem.

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