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

Re: virtual upstream LDM and firewalls

Larry,

>Date: Mon, 22 Aug 2005 15:15:52 -0500
>From: Larry Hinson <address@hidden>
>To: Steve Emmerson <address@hidden>
>Subject: Re: virtual upstream LDM and firewalls

The above message contained the following:

> We reverted back to the original HP Gauntlet firewall last Friday and 
> _/most/_ of the problems I described went away.     We tested the 
> failover on the PDS (Product Distribution) servers twice today, and 
> everything worked as I expected.   The downstream LDM on the AWIPS side 
> indicated that it was aware of a disconnect from the upstream LDM, and 
> re-established the connection once the LDM was started on the backup PDS 
> server.  I'm not so sure that happened with the Juniper Firewall,  as 
> you explained, and so was trying to communicate with a defunct upstream 
> LDM.

There could also be problems with any network switches between the
upstream host and the firewall as they attempt to translate between IP
addresses and MAC addresses.

> We will be staying on the HP Guantlet firewall for the time 
> being.   The Juniper Firewall will be further tested with LDM by NWS 
> Headquarters folks in a Lab, and not here. 

OK.  Please tell them that I'm at their disposal.

> The one anomaly that is left over with our LDM system is the time that 
> elapses between when the product is inserted into the que (on PDS) and 
> when it is received in the downstream LDM on AWIPS, which is ~20 seconds 
> (previously took longer on the Juniper firewall).  The pqinsert part is 
> being done via a script outside of the LDM server to insert products 
> into the que.  That script has a loop that is run every 15 seconds to 
> monitor files in a $HOME/data/outgoing subdirectory.  If any exist, they 
> are inserted into the que via pqinsert ...
> 
> pqinsert -v -s 100 -l $HOME/logs/ldmd.log -f NMC2 $filename
> 
> I applied the SIGCONT signal to the LDM process group, via "kill -s CONT 
> <<pid>>"  where pid was found from the ldmd.pid file, as you suggested.  
> This appears to have cut  the latency in half to 10 seconds.

That sounds right.  The main source of the latency is now the sleeping
done by the script.

Regards,
Steve Emmerson