feffe422   
   XPost: comp.os.vms   
   From: gah@ugcs.caltech.edu   
      
   In comp.protocols.tcp-ip jbriggs444  wrote:   
   < On Oct 2, 6:00?pm, glen herrmannsfeldt  wrote:   
   <> Richard B. Gilbert  wrote:   
      
   <> < I'm not certain but I suspect that your problem is due to the fact that   
   <> < DECnet sets the Ethernet address to AA-00-04-00-FB-04. ?If you start   
   <> < TCP/IP first, it will get the original hardware address for the   
   <> < interface. ?When DECnet starts it will set the address to the DECnet   
   <> < node address and leave TCP/IP swinging in the breeze!   
      
   <> That should only happen until the ARP cache is updated. ?Any host   
   <> that tries to connect after the MAC address change will get the   
   <> new address from ARP. ?Most will update on the broadcast ARP reply,   
   <> but maybe not all.   
      
   < Broadcast ARP reply?  What broadcast ARP reply?   
      
   OK, that is why I posted here.   
      
   < ARP requests are broadcasts.   
   < ARP replies are conventionally sent as unicasts.   
      
   Other hosts should update their cache based on the broadcast   
   request, though, right?   
      
   Many years ago I found a bug related to ARP.  An HP/UX machine   
   running a third party appletalk (ethertalk) package would,   
   it seems, sometimes ARP in SNAP encapsulated mode.  The Cisco   
   router would then switch to SNAP encapsulation, but the host   
   IP stack would not recognize them.  If I ping another host from   
   the HP/UX machine it would ARP for that host, and the router   
   would update the cache.   
      
   I wouldn't be surprised if some broadcast replies.  How many   
   update the cache on broadcast requests not destined for them?   
      
   -- glen   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)