Jim Warner (agate!saturn!eshop@ucbvax.Berkeley.EDU)
26 Nov 88 18:08:40 GMT
In article <8811221804.AA20970@TOTO.MIT.EDU> mar@ATHENA.MIT.EDU writes:
>A way to avoid this entirely is to have the new machine broadcast an
>ARP reply when it starts up. This gratuitous ARP reply will prime
>everyone's cache with its information. Some operating systems do this
>(broadcast) already, and every ARP implementation following the RFC
>will get its cache primed.
I'm not sure which RFC you're reading. If it's RFC826 I think you
misunderstand some details. The last field of an ARP packet (request
or reply) is the protocol destination address of the target. What
do you propose to put in this field for a broadcast ARP reply? The
IP broadcast address? This will not "prime everyone's cache." It
will not prime anyone's cache. A match with the local IP address is
required in this field to add a new entry (if that's what "prime"
Now things aren't all that bad. RFC826 calls for all hosts on the
wire to update an existing ARP entry on receipt of a broadcast ARP
packet. A new entry will not be created unless the protocol destination
address matches that of the recipient. It doesn't matter whether it
is a request or a reply.
I hauled out my Ethernet analyzer and checked this behavior for
4.3BSD, Sun OS3.5 and Cisco routers and they work the way they're
supposed to. So the good news is that inventing a broadcast ARP
reply isn't necessary. The first (normal) broadcast ARP request
will have the same effect (updating old info) and doesn't require
I think that the original direction of this thread was, "can we
make some changes to a bootp server so that it can serve a large
pool of PC-type clients by dynamicly assigning their IP addresses
out of a (smaller) piece of the address space.
I see three problems:
1. The bootp protocol works through subnet gateways so that one
(or a small number of) bootp servers can service an entire
network. Helpful subnet gateways forward these requests along
staticly defined paths so that clients that don't have servers
on their local wire can get service. But information is not
carried in the request to indicate the originating subnet. Unless
the bootp.tab data base contains entries binding Ethernet addresses
to subnets, the bootp server won't know on which subnet to assign
2. I presently run two bootp servers on separate computers. They work
off identical static bootp.tab files. It doesn't matter which one
responds first to a request because they provide the same responses.
PCs have a reputation for rebooting frequently. How do I insure
that when a user does cntrl-alt-delete that he will be reassigned
to the same address he was using a few minutes prior? If I don't
get him back with the same address, he can reboot ten times and
tie up the entire dynamic address pool. Along the same lines,
what happens to the pool if the bootp server reboots and can't
remember the current dynamic assignments?
3. My boss. The last thing he does just before he goes home is pull
up a Sidekick window on his PC to look up a phone number. He
leaves for the day with his PC frozen in Sidekick -- with interrupts
disabled. When he comes in the next morning and exits Sidekick,
his PC still thinks it "owns" an IP address that was assigned 18
hours prior but that it hasn't been using or defending. Please
*don't* suggest I get a new boss.
I view the last problem as, by far, the more difficult. How can a
bootp server determine that a dynamicly assigned IP address is free
for reassignment in the face of clients as ill-behaved as MS-DOS PCs?
U.C. Santa Cruz
This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:44:54 GMT