ADT connection

It is a common side effect for a Cloverleaf interface to show UP when a connection is abruptly dropped.

Being this is an outbound ADT feed you can help it along.

One way I’ve been able to partially help an interface like this along is via TPS procs that keep track of the number of resends and sends out an alert and cycles the thread at various resend thresholds.

By setting the alert on resend count this becomes a very proactive alert.

However, the new versions of cloverleaf will have to be configured the old way of using recover 33 to use this becuase the automatic persistant resend eliminates this type of alert the way we currently use it.

Here is a URL to help you get something in place to limp along a bit better while working on determine the cause of the abrubt disconnects.

<a href="https://usspvlclovertch2.infor.com/viewtopic.php?t=1862&#8243; class=”bbcode_url”>https://usspvlclovertch2.infor.com/viewtopic.php?t=1862

There are other issues discussed all over clovertech about TCP/IP keep alive settings I suggests you serch for and read.

I too have experienced more issues with interfaces that go thru VPN or thru enterprise firewalls.

I just noticed that you said your interface drops after one minute which is too short and too often for my resend alerts to be of use.

You are going to need to search for the TCP/IP keep alive post and see if those help any.

I did a quick search on the word keepalive and here is one URL to get you started in that direction:

<a href="https://usspvlclovertch2.infor.com/viewtopic.php?t=2687&highlight=keepalive&#8221; class=”bbcode_url”>https://usspvlclovertch2.infor.com/viewtopic.php?t=2687&highlight=keepalive

Which lead me to search for tcp_keepidle and her are some of those:

<a href="https://usspvlclovertch2.infor.com/viewtopic.php?t=4618&highlight=tcpkeepidle&#8221; class=”bbcode_url”>https://usspvlclovertch2.infor.com/viewtopic.php?t=4618&highlight=tcpkeepidle

<a href="https://usspvlclovertch2.infor.com/viewtopic.php?t=734&highlight=tcpkeepidle&#8221; class=”bbcode_url”>https://usspvlclovertch2.infor.com/viewtopic.php?t=734&highlight=tcpkeepidle

<a href="https://usspvlclovertch2.infor.com/viewtopic.php?t=4259&highlight=tcpkeepidle&#8221; class=”bbcode_url”>https://usspvlclovertch2.infor.com/viewtopic.php?t=4259&highlight=tcpkeepidle

plus many more if you do the search and need to look thru more of them, good luck.

One of the above URLs also shows another approach of sending a predetermined dummy ADT message to assure the interface stays up, but once again one minute disconnects might be a bit too short for round about workarounds to be effective.

You may know this, the TCP/IP keepalive settings I’m talking about aren’t within cloverleaf, they are OS settings.

I agree the Cloverleaf settings aren’t likely to be the issue.

Greetings,

Another thought here:  99% of the time it is not a Cloverleaf problem.

We have requested that our Network Admin support group configure a “sniffer” on the IP and port and trap all traffic via this hole in our firewall for troublesome VPN TCP/IP connected interfaces.  We have no timeouts configured at the firewall; however, at times, the remotes (vendor) for whatever reason decide to start up a new connection (we are server here) and so we implement a multi-connect (CIS 5.6 +) as a band-aid to “fix” Cloverleaf.  For our outbound VPN sometimes we have to implement a queue depth alert and auto-cycle the Cloverleaf thread to re-establish a connection.  Then there is the multiple servers (vendor side) that swap among themselves and the established “connection” is not passed among them always.  The vendor confessed after our Network guys shoved the dump under their nose and then the vendor had to fix their side.  Cloverleaf always showed UP but the server at the vendor side kept the connection alive though it swapped to another companion server to do the work.

Short response:  see if you can place a “sniffer” on the connection to get the details on what is goind on.

Good luck, good hunting!