[LDM #HHK-349534]: LDM data feed down

Hi,

We just verified that one of our real server backend machines for the
idd.unidata.ucar.edu cluster is denying a connection attempt from:

128.163.8.100

and this has happened 4 times:

20170724T185301.068471Z ldmd[4447] NOTE ldmd.c:637:handle_connection() Denying 
connection from "128.163.8.100" because not allowed
20170724T185326.219561Z ldmd[4563] NOTE ldmd.c:637:handle_connection() Denying 
connection from "128.163.8.100" because not allowed
20170724T194928.659837Z ldmd[25984] NOTE ldmd.c:637:handle_connection() Denying 
connection from "128.163.8.100" because not allowed
20170724T195256.762544Z ldmd[26397] NOTE ldmd.c:637:handle_connection() Denying 
connection from "128.163.8.100" because not allowed

The IP address 128.163.8.100 does not resolve to a fully qualified name:

% nslookup 128.163.8.100
Server:         208.67.222.222
Address:        208.67.222.222#53

** server can't find 100.8.163.128.in-addr.arpa.: NXDOMAIN

Question:

- was there a change in the network setup at UKy that is now trying to
  proxy the LDM connection attempt using 128.163.8.100?

  I ask because the IP addresses of your two machines are similar:

  weather.uky.edu     128.163.192.188
  weather3.ca.uky.edu 128.163.192.19


A 'notifyme' to weather.uky.edu shows that the last data product it received
had a time stamp of 160308.868706:

20170724T203625.678240Z notifyme[24231] INFO notifyme.c:217:notifymeprog_5()    
    500 20170724160307.703312 HDS 42885399  NTUS96 KNCF 241603 /pWTSNCF
20170724T203625.731963Z notifyme[24231] INFO notifyme.c:217:notifymeprog_5()    
   3501 20170724160307.902259 IDS|DDPLUS 42885435  ASUS41 KCTP 241603 /pRWRCTP
20170724T203625.878117Z notifyme[24231] INFO notifyme.c:217:notifymeprog_5()    
    144 20170724160308.868706 IDS|DDPLUS 7459206  SXCA50 KWAL 241602

Where there any changes made to the network setup at UKy around 16 UTC?

re:
> Our servers (weather.uky.edu and weather3.ca.uky.edu) are using
> weather.admin.niu.edu,weather2.admin.niu.edu and weather3.admin.niu.edu
> as ldm data feed servers over 10 years without any problems. But just
> at 12:00 this noon the ldm feeding stopped or the access is denied.
> Is possible to check feed servers how is the setup/configuration of
> ldm feeding changed today. If yes, please make change again to allow
> the access of our 2 servers.

We too are unable to contact the machines (weather, weather2 and weather3)
at NIU.  We are also not able to SSH to any of these machines like we have
in the past.  It is entirely possible that these machines are no longer
functioning as IDD relays.  Gilbert Sebenste sent a note to the ldm-users
email list a couple of months ago warning that this might happen because
of budget cuts in Illinois.

Given the uncertainty of NIU continuing to act as your IDD upstream feeder,
we suggest you change your ~ldm/etc/ldmd.conf REQUEST lines to request
the feeds from some other site(s).  This is why I asked you to check
to see if there are active ALLOWs for your machines on:

idd.tamu.edu
idd.meteo.psu.edu

Did you check those machines as I asked in a previous email?  If yes,
what were the results?

Cheers,

Tom
--
****************************************************************************
Unidata User Support                                    UCAR Unidata Program
(303) 497-8642                                                 P.O. Box 3000
address@hidden                                   Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage                       http://www.unidata.ucar.edu
****************************************************************************


Ticket Details
===================
Ticket ID: HHK-349534
Department: Support IDD
Priority: Normal
Status: Open
===================
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata 
inquiry tracking system and then made publicly available through the web.  If 
you do not want to have your interactions made available in this way, you must 
let us know in each email you send to us.