[IDD #IVG-583515]: RE: EXT :20141114: NOAAPort relay Machine Set up at NG

Hi Heather,

re:
> Try 208.24.128.15, it is the external facing IP address.

Very good.

re:
> Our hostname should be noaapxcd.it-protect.com.

The fully-qualified hostname for 208.24.128.15 is wx1.it-protect.com.
noaapxcd.it-protect.com has the IP address 208.24.128.95:

[ldm@gale ~]$ nslookup noaapxcd.it-protect.com
Server:         128.117.140.56
Address:        128.117.140.56#53

Non-authoritative answer:
Name:   noaapxcd.it-protect.com
Address: 208.24.128.95

[ldm@gale ~]$ nslookup 208.24.128.95
Server:         128.117.140.56
Address:        128.117.140.56#53

Non-authoritative answer:
95.128.24.208.in-addr.arpa      name = noaapxcd.it-protect.com.

Authoritative answers can be found from:
95.128.24.208.in-addr.arpa      nameserver = ns1.it-protect.com.
95.128.24.208.in-addr.arpa      nameserver = ns2.it-protect.com.
ns1.it-protect.com      internet address = 208.24.128.5
ns2.it-protect.com      internet address = 208.24.128.1

[ldm@gale ~]$ nslookup 208.24.128.15
Server:         128.117.140.56
Address:        128.117.140.56#53

Non-authoritative answer:
15.128.24.208.in-addr.arpa      name = wx1.it-protect.com.

Authoritative answers can be found from:
15.128.24.208.in-addr.arpa      nameserver = ns2.it-protect.com.
15.128.24.208.in-addr.arpa      nameserver = ns1.it-protect.com.
ns1.it-protect.com      internet address = 208.24.128.5
ns2.it-protect.com      internet address = 208.24.128.1

[ldm@gale ~]$ nslookup wx1.it-protect.com
Server:         128.117.140.56
Address:        128.117.140.56#53

Non-authoritative answer:
Name:   wx1.it-protect.com
Address: 208.24.128.15

re:
> As for what is setup there now, it is just an LDM grabbing data from our 
> ingestor and
> decoding it.

OK.  I am not able to contact either 208.24.128.15 or 208.24.128.95 from
the LDM account on gale.unidata.ucar.edu.  It looks like access to either/both
of these machines is being blocked by a firewall.

re:
> I thought that you wanted us to host this data for others who need it as a
> backup.

That would be great, but my original intention was to feed the datastreams
being created by your NOAAPort ingester into the IDD.  This will be accomplished
by:

- your new machine REQUESTing the NOAAPort datastreams (IDS|DDPLUS, HDS,
  NEXRAD3, NGRID, NIMAGE and NOTHER) from your NOAAPort ingest machine

- designated top level IDD relay machines would REQUEST these same feeds
  from your new machine

  The addition of your new machine feeding into the IDD will increase
  the redundancy of these feeds in the IDD -- when one site is undergoing
  any sort of an outage (e.g., noisy data, machine down for service, the
  network connection is temporarily out, etc.) the data will come from
  one or more of the other redundant machines feeding into the IDD.

re:
> I wasn't aware that you wanted us to point this to YOUR ingestor.

No, I want machines that we designate to be able to REQUEST NOAAPort-derived
data streams from _your_ machine.

re:
> If that is the case, than we can do that. Do you want us to decode anything 
> or house any
> data?

Decoding and serving the data via ADDE would be icing on the cake!  The first
thing we want is input from your NOAAPort ingest machine.

re:
> I am confused what you mean by a relay?

Your new machine will essentially be relaying the data streams that are
being created by your NOAAPort ingest machine, and the relay would be
to machines that we specify at sites that are top level relays for
data flowing in the IDD.  The list of sites that I mentioned previously
were/are:

Unidata
UW/SSEC
Texas A&M
Penn State

The machines that we will want to be ALLOWed to REQUEST data from your
new machine are currently:

Unidata:
oliver.unidata.ucar.edu <-> 128.117.156.17
emo.unidata.ucar.edu    <-> 128.117.140.63
agg1.unidata.ucar.edu   <-> 128.117.130.50

UW/SSEC:
idd.ssec.wisc.edu       <-> 128.104.109.52

Texas A&M:
bigbird.tamu.edu        <-> 128.194.76.168
sasquatch.tamu.edu      <-> 128.194.76.169

Penn State:
idd.meteo.psu.edu       <-> 128.118.64.130

Comments:

1) setting up access LDM access to your new machine from gale.unidata.ucar.edu
   was only to test the accessibility

   The ultimate goal is for all of the machines listed above at the top
   level IDD relay sites being ALLOWed to REQUEST from your new machine, AND
   for these machines to be allowed through the NG firewall for LDM
   (port 388) traffic.

   Access by gale to either noaapxcd.it-protect.com or wx1.it-protect.com
   does _not_ currently work, and the reason appears to be that the NG
   firewall is blocking inbound requests on port 388.

2) I need to verify with Texas A&M that the machines listed above (bigbird
   and sasquatch) are the ones that they are using as front ends to their
   IDD relay cluster, idd.tamu.edu

3) I need to verify with Penn Staet that the machine listed above
   idd.meteo.psu.edu) is the one that they are using as front ends to their
   IDD relay cluster... I really think that this is not the machine
   that will need to be allowed by your LDM and NG firewall

If it is easier, we could discuss the "big picture" by phone.  I am in
the office today until about 4:30 MST.  My phone number is 303.497.8642.

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