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

[LDM #BIG-900661]: Terminated obsolete upstream

Brice,

The two requests that go to the same host via an SSH tunnel will definitely be
a problem because the return IP address that the LDM sees will be the same.
Consequently, if the feedtypes of the two requests overlap at all, then the
LDM will reduce the feedtypes served by one request. If that feedtype goes to
the empty set, then that connection will drop.

The workarounds are listed in the URL you mentioned. Be advised that using
literally different but effectively identical patterns (e.g., ".*" and "(.*)")
will use double the bandwidth.

In determining duplicate or overlapping requests, the LDM server only looks at
the IP address from which the request originated, the feedtypes of the request,
and the exact syntax of the pattern string.

The thrashing of your clients (I assume they're the ones making direct 
connections
to the LDM servers) puzzles me. Can you send me the relevant log entries that
reveal the problem?

> Oops. Forgot the diagram.
> 
> [cid:image001.png@01CF83EE.8B8E07F0]
> 
> From: Biggerstaff, Brice A9
> Sent: Monday, June 09, 2014 1:59 PM
> To: 'address@hidden'
> Cc: Nguyen, Lee
> Subject: 'Terminated obsolete upstream
> 
> I have run into an issue that appears to fit this 
> http://www.unidata.ucar.edu/blogs/news/entry/ldm_6_11_4_released.  We are 
> using an SSH tunnel to allow external customers to get data from our servers 
> per security policy.  This is the error that I am seeing and it is 
> understandable after seeing the information on the link, as the SSH looks 
> like a NAT'd connection.  Working with one of the customers to try to test 
> the request logic change detailed in the post, I'm still getting the same 
> error.  His clients are currently at LDM 6.11.4 and my servers and clients 
> (the xxx.xxx.xxx.1 and 2) are at 6.11.6
> 
> With some log analysis, I see that my clients are being dropped as well, with 
> some thrashing on the servers as to who gets dropped with one address being 
> dropped every two minutes (each time it connects?) and the other dropped 
> sometimes.  When my customer came in I saw the same basic pattern and when we 
> changed his request string from "^LR*|^LW*|^RS*" (internal patterns coming in 
> under the SPARE feedtype) to one machine using "(^LR*|^LW*|^RS*)" it did not 
> change the error.
> 
> I could kind of understand the original problem with the SSH looking like a 
> NAT, but I don't understand the problem with the two independent clients on 
> my network.  I've never seen that one before.  Does the LDM server in its 
> denial of service defense look at the IP address close enough to determine 
> that it's another address on the same network?
> 
> Before I get too far into hacking a solution, is there any direction you can 
> point me as to how to fix this.  It is one of the last sticking points in a 
> major system architecture upgrade that I am working on.
> 
> Thanks,
> 
> Brice
> 
> Brice Biggerstaff, CISSP
> Johnson Space Center
> Weather Decision Support System
> MIDDS Software Support Lead
> 281-853-3011 (w)
> 713-764-2601 (p)
> address@hidden<mailto:address@hidden>  (alpha pager for text and email)
> 
> Res Confacti Erimus
> "We Get Things Done!"

Regards,
Steve Emmerson

Ticket Details
===================
Ticket ID: BIG-900661
Department: Support LDM
Priority: Normal
Status: Closed