🚀 go-pugleaf

parsonsr@uhura.aston.ac.uk (R Parsons) writes:
  |We have two Sequent machines, an S27 running Dynix version 3.1.2
  |and an S700 running Dynix/ptx version 1.3.0. The problem is the same
  |on both machines.
  |
  |Both these machines are connected to various Sun's and Vaxes over ethernet.
  |There seems to be no problem with the Vaxes, but with the Sun's we seem 
  |to loose parts of the arp tables and then cannot connect to the machines
  |concerned. The arp -a display looks like this:-
  |
  |  $ arp -a
  |    -  -  -  
  |  sunserver2 (134.151.40.14) at (incomplete)
  |...
  |When you try to connect to sunserver2 with the addresses in this state
  |the connection just hangs. By adding the address manually with:-
  |
  |  arp -s sunserver2 <ethenet-address>
  |
  |all works fine, until the next time the address gets lost. 
  |
  |Sequent support here in England tell me it's a known bug and is being
  |looked at in the States. Does anyone else know of or have this problem,

We had the same problem here a little while ago. A source at Sequent told
us the problem was that SPARCs respond so fast to a Sequent's arp request 
that the Sequent's slow SCED ethernet controller can't "turn around" 
fast enough to read the response in time. We solved the problem by moving
the Sun to a different router port. This induced enough of a delay to
allow the Sequent's to respond in time. Another circumvention mentioned
by Sequent is to use arp -p (permanent) addresses for the Sparcs on our
Sequents.

Hope this helps.
----------------------------------
Ed Kubaitis (ejk@ux2.cso.uiuc.edu)
Computing & Communications Services Office - University of Illinois, Urbana

We had this problem when we first got some Sparc 2s.  Seems whats
happening is that the Sparc 2s are so fast that they answer the
Sequent's arp request before the Sequent is ready to head it.  The
solution was to make the arp entries for our 2s permanent on the
Sequent.  This was done by putting the following in our rc.local

# make permanent arp entries for machines that respond to arp requests
if [ -f /etc/arp.init ]; then
        /usr/etc/arp -f /etc/arp.init && \
                echo 'local arp entries.'                       >/dev/console

and then creating the file /etc/arp.init which contained all of our
2's ethernet address, e.g., 

fanaraaken 8:0:20:10:94:10
...

That fixed things completely.

James S. Vera      |         Internet           |Standard Disclaimers
Stanford University|   vera@anna.stanford.edu   |Blah Blah Blah Blah
+1.415.723.1089    |    FAX +1.415.725.7398     |