Re: ICMP's & IP src addrs


Casey Leedom (admin.cognet.ucla.edu!casey@CS.UCLA.EDU)
27 Sep 88 03:45:20 GMT


In article <8809270020.AA01343@ucbvax.Berkeley.EDU>
 tmallory@PARK-STREET.BBN.COM writes:
> In some article or another I write:
> > Hhmmm, you mean your hosts receive a packet on their ethernets and
> > don't record the mapping of source ethernet and IP addresses in their ARP
> > caches? Doesn't sound like a very good idea to me. I'd say there's
> > probably a pretty good chance you're going to have to send a packet back
> > to any host you receive one from ...
>
> Also, there is the problem that the source address in the IP header may
> well not match the source hardware address if the packet has been sent
> through a gateway. OK, so you only insert the mapping if the network
> number matches the attached network. But some hosts support multiple
> network numbers for the same network, so the packet might still have come
> from a gateway... This gets complicated, and the layering isn't very
> pretty. I don't think many hosts do it, but I'd be happy to hear
> otherwise.

  No, you're right. And me a proponent of lazy evaluation to boot ...
And I should know better than to get snide on TCP-IP. Actually I wasn't
really trying to be snide, but it came out that way. Sorry.

  But, while I'm here talking about when to put entries into your ARP
cache, I'd like to describe an interesting experience I had today and see
if anyone can explain it:

  Lawrence Livermore National Laboratory has recently joined the BARRNET,
a regional NSFNET centered in the Bay Area in California. Other members
currently include UC Berkeley, NASA Ames Research Center, Stanford, UC
Davis, and several others. LLNL is tied into the BARRNET at two points,
UCB and NASA ARC:

        Lawrence Livermore National Laboratory
                LLNL.Gov
                NET-LLL-LABNET
                128.115

        University of California, Berkeley
                Berkeley.Edu
                NET-UCB-ETHER
                128.32

        NASA Ames Research Center
                ARC.NASA.Gov
                NET-AMES-NET
                128.102

  When I look at typical host at LLNL, mozart.llnl.gov [128.115.12.1], a
Sun 3/180 running SUN OS 3.4, I see a route to UCB-ETHER via
BARRNET-GW.llnl.gov [128.115.1.100], but no ARP cache entry for
BARRNET-GW. Now:

  From UCB (vangogh.berkeley.edu):
        I can ping mozart.
        I can talk to the name server on mozart.
        I can telnet to the SMTP server on mozart.
        I can't telnet or rsh to mozart.
                Symptoms: telnet goes into a connected state (at least
                it said it did) and then hangs. No login prompt,
                nothing. I had to escape out (^]) and quit the session.
                rsh just hangs but allows ^C's to abort it, so it hasn't
                entered a fully connected state with the remote rshd.

  On mozart.llnl.gov:
        I can ping UCB (vangogh.berkeley.edu).

  After all that testing, there's still no entry for barrnet-gw in
mozart's ARP cache. If I ping barrnet-gw from mozart or attempt to
telnet to UCB from mozart, an entry for barrnet-gw is now in mozart's ARP
cache and suddenly telnet's from UCB to mozart work! SUN OS 3.5 doesn't
seem to have this problem ... Opps, nope. Read the following paragraph.

  Unfortunately, I can't get this to happen consistently. For instance,
I just deleted the entry for barrnet-gw from mozart's ARP cache and was
able to successfully telnet in from UCB. I've done this three times now
in the last five minutes and I'm beginning to doubt my memory of the
first series of test this afternoon ...

  Does anyone have any idea what's going on?

Casey



This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:43:31 GMT