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.
