[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 20020805: RPC Timed out error ldmping ldm problem

Mike Leuthold wrote:
> 
> > sunny89: can connect, but after a delay.  Was there a change in the DNS?
> 
> No change.  All hosts resolve fine with nslookup.
> 

So, we'll rule out DNS for the time being.

> >
> > And, sunny89 is sending you old products that you are rejecting.  How
> > often is this happening?  If you notice when this is happening, do a
> > notifyme to sunny89 and see how timely it is running.  If it's not
> > behind itself, then something is slowing down the connection, perhaps
> > packet examination from the firewall.
> This may of been because I had just rebuilt the queue.  I do eventually
> catch up.  However, even feeding from sunny89 eventually stops after a few
> hours...

It eventually stops?  Does the connection go down?  Can you give me more
details about this?

> >
> > aeolus:  can't connect, can't contact portmapper.  Is outbound port 388
> > blocked?  That would be an odd,configuration, but it's possible.  Please
> > try ping, nslookup and traceroute to aeolus.
> All work fine....I can even telnet to port 388 on aeolus.
> [ldm@nimbus etc]# telnet aeolus.ucsd.edu 388
> Trying 132.239.114.58...
> Connected to aeolus.ucsd.edu (132.239.114.58).
> Escape character is '^]'
> 

OK...

> [ldm@nimbus etc]# ping aeolus.ucsd.edu
> PING aeolus.ucsd.edu (132.239.114.58) from 128.196.30.175 : 56(84) bytes of 
> data.
> 64 bytes from aeolus.ucsd.edu (132.239.114.58): icmp_seq=0 ttl=53 time=50.104 
> msec
> 64 bytes from aeolus.ucsd.edu (132.239.114.58): icmp_seq=1 ttl=53 time=66.854 
> msec
> 64 bytes from aeolus.ucsd.edu (132.239.114.58): icmp_seq=2 ttl=53 time=56.826 
> msec
> 
> --- aeolus.ucsd.edu ping statistics ---
> 3 packets transmitted, 3 packets received, 0% packet loss
> round-trip min/avg/max/mdev = 50.104/57.928/66.854/6.882 ms
> [ldm@nimbus etc]# traceroute aeolus.ucsd.edu
> traceroute to aeolus.ucsd.edu (132.239.114.58), 30 hops max, 38 byte packets
>  1  128.196.30.1 (128.196.30.1)  1.330 ms  0.302 ms  0.273 ms
>  2  woody-vlan996-bullseye.telcom.arizona.edu (150.135.250.13)  0.340 ms  
> 0.427 ms  0.281 ms
>  3  tuco-ge1-1-woody.telcom.arizona.edu (192.80.43.25)  1.755 ms  1.143 ms  
> 1.199 ms
>  4  virgil-fa5-0-0-tuco.telcom.arizona.edu (192.80.43.34)  1.565 ms  1.532 ms 
>  1.407 ms
>  5  192.80.43.22 (192.80.43.22)  18.949 ms  19.068 ms  18.941 ms
>  6  snva-dnvr.abilene.ucaid.edu (198.32.8.1)  44.034 ms  44.117 ms  43.777 ms
>  7  losa-snva.abilene.ucaid.edu (198.32.8.18)  51.238 ms  51.891 ms  51.225 ms
>  8  USC--abilene.ATM.calren2.net (198.32.248.85)  51.747 ms  51.550 ms  
> 51.763 ms
>  9  UCSD--USC.POS.calren2.net (198.32.248.34)  54.832 ms  54.929 ms  54.985 ms
> 10  198.32.248.186 (198.32.248.186)  55.538 ms  55.835 ms  55.307 ms
> 11  sio-rsm--ucsd-gw.ucsd.edu (132.239.255.145)  56.315 ms  55.789 ms  56.663 
> ms
> 12  aeolus.ucsd.edu (132.239.114.58)  59.106 ms  55.595 ms  60.651 ms
> [ldm@nimbus etc]# nslookup aeolus.ucsd.edu
> Note:  nslookup is deprecated and may be removed from future releases.
> Consider using the `dig' or `host' programs instead.  Run nslookup with
> the `-sil[ent]' option to prevent this message from appearing.
> Server:         128.196.30.90
> Address:        128.196.30.90#53
> 
> Non-authoritative answer:
> Name:   aeolus.ucsd.edu
> Address: 132.239.114.58
> 
> >
> > suomildm1: no route to host.  Again, please try ping, nslookup, and
> > traceroute to aeolus.
> 
> same as aeolus, it all works, except for ping-my guess is that it is being
> filtered.  I tested  striker.atmos.albany.edu too.  It was fine.
> 

OK...


> >
> > This may be matter of seeing which protocols work and which don't to
> > identify what's open and what's not.
> 
> This all started when Telecom was fooling around with a firewall and I'm
> quite confident that the problem is related to that.  They say that it
> isn't running now and everything is back to 'normal'.  Would it be
> possible for them to contact you if we exaust all our testing without
> finding a solution?
> 

Yes.  Although I would have them talk with our system administrator,
Mike Schmidt.


> >
> > Also, it might be interesting to try putting these three hosts in
> > /etc/hosts on nimbus.  If they're not there already, and this change
> > causes the connections to occur faster, then something changed about the
> > DNS.
> 
> I put those in.  No change.
> 
> Thanks Anne.
> 
> Mike


I've been discussing this with Mike (our sys admin).  He was wondering
if a good old reboot might clear up some confusion.   Have you rebooted
recently?

And, if a reboot doesn't clear things up, may we log in to your machine
and take a look?

Our preference would be to try these two things, then bring in the
Telecom people.  How does that sound to you?  (If we get to the remote
login point, please either call me with the password (303) 497-8677, or
otherwise encode it in some way.)

Anne

-- 
***************************************************
Anne Wilson                     UCAR Unidata Program            
address@hidden                 P.O. Box 3000
                                  Boulder, CO  80307
----------------------------------------------------
Unidata WWW server       http://www.unidata.ucar.edu/
****************************************************