echan@cadev6.intel.com (Eldon Chan ~ ) (04/25/91)
As in the diagram, what would happen if router R1 crashed after the
unsubnetted_host established the connection to subnetted-host2 via
proxy-arp from R1? Would the unsubnetted_host send another ARP request
or is it going to wait until the ARP entry aged out (20min?)
On the gateway side, would both routers response to the ARP
request for subnetted-host2 or just the router has a better route? In
the later case, I probably have to assign different default metric on
the routers to force a primary and a secondary route. Does IGRP take
care of this and provide some kind of load balancing?
subnetted-host1 unsubnetted_host
| |
----------------------------------------------
| |
| |
------ -------
| R1 | | R2 | Both routers are
------ ------- running proxy-arp
| |
| |
----------------------------------------------
|
subnetted-host2
RFC1122 mentioned that there are four mechanisms to implement ARP
timeout. I know most UNIX aged the arp table every minute, timeout the
incomplete entries every 3 minutes and complete entries every 20
minutes. What happens when the connection drops ?
Would someone tell me which vendor is using which mechanism or point me
to the source files that I can check? In particular I am interested in
SunOS, Ultrix and AIX.
Thanks in advance.
Eldon Chan
echan@scdt.intel.com
-----------------------------------------------------------------------
-----------------------------------------------------------------------
RFC1122 LINK LAYER October 1989
DISCUSSION:
The ARP specification [LINK:2] suggests but does not
require a timeout mechanism to invalidate cache entries
when hosts change their Ethernet addresses. The
prevalence of proxy ARP (see Section 2.4 of [INTRO:2])
has significantly increased the likelihood that cache
entries in hosts will become invalid, and therefore
some ARP-cache invalidation mechanism is now required
for hosts. Even in the absence of proxy ARP, a long-
period cache timeout is useful in order to
automatically correct any bad ARP data that might have
been cached.
IMPLEMENTATION:
Four mechanisms have been used, sometimes in
combination, to flush out-of-date cache entries.
(1) Timeout -- Periodically time out cache entries,
even if they are in use. Note that this timeout
should be restarted when the cache entry is
"refreshed" (by observing the source fields,
regardless of target address, of an ARP broadcast
from the system in question). For proxy ARP
situations, the timeout needs to be on the order
of a minute.
(2) Unicast Poll -- Actively poll the remote host by
periodically sending a point-to-point ARP Request
to it, and delete the entry if no ARP Reply is
received from N successive polls. Again, the
timeout should be on the order of a minute, and
typically N is 2.
(3) Link-Layer Advice -- If the link-layer driver
detects a delivery problem, flush the
corresponding ARP cache entry.
(4) Higher-layer Advice -- Provide a call from the
Internet layer to the link layer to indicate a
delivery problem. The effect of this call would
be to invalidate the corresponding cache entry.
This call would be analogous to the
"ADVISE_DELIVPROB()" call from the transport layer
to the Internet layer (see Section 3.4), and in
fact the ADVISE_DELIVPROB routine might in turn
call the link-layer advice routine to invalidate
the ARP cache entry.
Approaches (1) and (2) involve ARP cache timeouts on
the order of a minute or less. In the absence of proxy
ARP, a timeout this short could create noticeable
overhead traffic on a very large Ethernet. Therefore,
it may be necessary to configure a host to lengthen the
ARP cache timeout.alan@curta.cc.columbia.edu (Alan Crosswell) (04/29/91)
To concur about proxy-arp. SunOS and IBM VM TCP/IP arp implementations are broken. They never age out. We had tried this set up. Our fix on the unix side is to have a cron job that runs every 5 minutes or so and explicity flush the arp cache. /a
oberman@ptavv.llnl.gov (04/29/91)
In article <34622@boulder.Colorado.EDU>, alan@curta.cc.columbia.edu (Alan Crosswell) writes: > To concur about proxy-arp. SunOS and IBM VM TCP/IP arp implementations > are broken. They never age out. We had tried this set up. Our fix on > the unix side is to have a cron job that runs every 5 minutes or so and > explicity flush the arp cache. I'm not so sure of this. The problem is that if an ARP entry is accessed, it resets the timeout. And there is no way to know if the access pointed to the right place. So any entry that gets regular access NEVER times out. But it's an ARP problem, not anything wrong with SunOs. R. Kevin Oberman Lawrence Livermore National Laboratory Internet: oberman@icdc.llnl.gov (415) 422-6955 P.S. Who would ever believe me saying anything to defend SunOs? Disclaimer: Don't take this too seriously. I just like to improve my typing and probably don't really know anything useful about anything.