[Support #HDQ-517625]: Assistance requested for "Gap in packet sequence" log entries from noaaportIngester

Hi Gregg,

re:
> The Gap errors have gone away.  SPC identified *another* NOVRA box with
> just PID 106 configured to multicast on our public network 140.90.173.x
> The SBN1 and SBN2 servers have direct connections to NOVRA boxes and these
> servers *also* sit on the 140.90.173.x network.  So the noaaportIngester
> was receiving data from two different NOVRA boxes (i.e. the direct connect,
> and the NOVRA multicasting on 224.0.1.6 via the 140.90.173.x network).
> 
> Question, even though the various instances of noaaportIngestor are running
> and specifically listening to configured multicast addresses (i.e. see
> below), can they also pick up a multicast on 224.0.1.6, which isn't
> configured via ldmd.conf (see below)?

This is a question for Steve.  But, I have to add that the original setup
on SBN1 was to explicitly specify the Ethernet interface to listen to for
the various ports/PIDs.  I do not know how traffic on one Ethernet
interface could affect that on a different Ethernet interface.

I have a counter example that supports my surprise/incredulity that this
was the cause of all of the problems:  we were feeding all NOAAPort channels
to one of the test machines at NOAA/GSL on their public Ethernet interface
while a Novra S300N was still sending all data to their other Ethernet interface
which, like yours, was/is private.  During this experiment, there was no
interference with the two different feeds.

re:
> [ldmcp@sbn2 ~/logs]$ !ps
> ps -ef | grep noa
> root      4137  4133  4 20:57 ?        00:02:56 noaaportIngester -m 224.0.1.1 
> -n -l /home/ldmcp/logs/1.nmc.log
> root      4138  4133  0 20:57 ?        00:00:00 noaaportIngester -m 224.0.1.2 
> -n -l /home/ldmcp/logs/2.goes.log
> root      4139  4133 12 20:57 ?        00:08:19 noaaportIngester -m 224.0.1.3 
> -n -l /home/ldmcp/logs/3.nmc2.log
> root      4140  4133  0 20:57 ?        00:00:09 noaaportIngester -m 224.0.1.4 
> -n -l /home/ldmcp/logs/4.nopt.log
> root      4141  4133  1 20:57 ?        00:01:07 noaaportIngester -m 224.0.1.5 
> -n -l /home/ldmcp/logs/5.nmc3.log
> root      4142  4133  1 20:57 ?        00:00:58 noaaportIngester -m 224.0.1.8 
> -n -l /home/ldmcp/logs/8.exp.log
> root      4143  4133  0 20:57 ?        00:00:00 noaaportIngester -m 224.0.1.9 
> -n -l /home/ldmcp/logs/9.grw.log
> root      4144  4133  4 20:57 ?        00:03:05 noaaportIngester -m 
> 224.0.1.10 -n -l /home/ldmcp/logs/10.gre.log
> ldmcp    14001  9718  0 22:06 pts/1    00:00:00 grep --color=auto noa
> [ldmcp@sbn2 ~/logs]$

The question is: what does the output of 'netstat -rn' look like on
SBN2?

re:
> Please keep me on the email list of Gap errors from the different sites and
> I'll compare the information to what we see from SBN1 and SBN2.

OK, I added you to the list after seeing your previous post.

re:
> So, this has been a painful lesson on another issue of what can cause Gap
> errors, another NOVRA box multicasting any data.

I don't see how at the moment.  Hopefully Steve can likely shed some light
on this.

re:
> Sorry we didn't figure this out sooner and before contacting you.  We
> greatly appreciate all of your time, efforts and assistance.

No worries.

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: HDQ-517625
Department: Support NOAAPORT
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.