🚀 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