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

[IDD #DJM-823948]: Feed source for NEXRAD2

Hi Scott,

> Long time no LDM :_


> I am just setting up a new system now and would like
> to receive NEXRAD and IDS/DDPLUS

Do you mean NEXRAD3 (NEXRAD Level III products) or NEXRAD2 (NEXRAD
full volume scans) or both?

> Seems idd.cise-nsf.gov is kaput.. Can I use a separate server?

Yes, we had to shutdown LDM/IDD activities in the NSF server room
quite some time ago (we were using too much bandwidth, and NSF was
and still is going through budget-cutting).

> My machine details:
> IP
> DNS EVS0351059.evs.anl.gov (it is behind a firewall)

OK, there is no reverse DNS (IP -> name) for your machine.
Since most Unidata community sites will are not willing
to add special ALLOWs by IP address, we will need to
serve you from our top level IDD relay cluster,
idd.unidata.ucar.edu.  In order to feed you, we needed
to perform a special procedure to get an appropriate ALLOW
in-place -- we basically had to hardwire an IP->name mapping
in the /etc/hosts file for your machine on each of the real
server backends of our cluster.  Just so you know, we
do not like doing this because as a "solution", it is
very brittle.

Please test the ALLOW scheme we just created as follows:

<as 'ldm' on>
notifyme -vl- -f NEXRAD2 -h idd.unidata.ucar.edu

A status line with an OK will indicate that you are able to
REQUEST from idd.unidata.ucar.edu.  Lack of such an allow
might mean that a firewall at/close to your machine is blocking
outbound traffic to port 388.  We see this more-and-more at
.gov and .mil sites.

A couple of things to note:

- depending on the network bandwidth between idd.unidata.ucar.edu
  and your machine, you may need to split your feed REQUEST
  for the NEXRAD feed(s) into a few (e.g., 5) mutually-exclusive

  We can talk more about this if the product latencies you experience
  are unacceptable.

- you could run into some problems if you decide to run more than
  one LDM machine behind the same NAT since REQUESTs made to upstreams
  will all look like they come from the same downstream (the IP of
  the NAT device).  This should not be a huge problem; I just wanted
  to alert you to the problem if it materializes.

> Thanks!

No worries.


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: DJM-823948
Department: Support IDD
Priority: Normal
Status: Closed