RE: CPF8907 on STRPASTHR over AnyNet

["Burns, Bryan" <burnsbm@xxxxxxxxxxxxxxxxxxxx>]

We had some issues with Anynet sessions timing out due to NAT not responding
to keep alives.  The solution per IBM was to create data areas that lengthen
the time that the keep alive are sent to 18 hours or so.  This solution
worked for us. Here is a copy of support line document regarding this issue:



    Document Number:   29904636
  ____________________________________________________________
  Functional Area:                       Communications-SNA
  SubFunctional Area:               AS/400-to-AS/400 Connectivity
  SubSubFunctional Area:       AnyNet
  ____________________________________________________________
  Product:  Operating System/400 - OS400 COMM BASE/APPN (5769SS1CM); OS400
COMM BASE/APPN (5722SS1CM)
  Release:  V4R1M0; V4R2M0; V4R3M0; V4R4M0; V4R5M0; V5R1M0; V5R2M0

  Classification:       Public Use

  Keywords:            AnyNet, ANYNET, APPCTCP
 ____________________________________________________________
 Document Title:AnyNet Not Supported over Networks Using NAT
 Document Description:
  Per APAR MA18298, AnyNet will most likely fail when used over a network
using Network Address Translation (NAT) in some firewall between the two
AS/400 or iSeries systems.  This is because the MPTN (Multi-Protocol
Transport Network) architecture incorporates the use of Keep-Alive packets
to determine if the connection is still active.  AnyNet uses a combination
Source Port/Destination Port of 397 (MPTN) and another undefined port for
sending TCP data.  The AnyNet Keep-Alive uses UDP (not TCP) and uses port
397 for the source and destination ports.

The following example from a communications trace shows how the source and
destination IP addresses are embedded within the UDP data used by the
AnyNet Keep-Alive packet.  If NAT is being used, it will translate only the
addresses included in the IP header of the frame.  It will not make any
change to the embedded data within the UDP datagram.  Therefore, when the
data is read by the MPTN code, it will not respond to the Keep-Alive packet
because the program is not aware of a connection to that IP address.
Because it does not respond to the packet, the system generating the
Keep-Alive request believes the connection has been terminated and will
initiate the connection to drop.

 

-----Original Message-----
From: Neil Palmer [mailto:NeilP@xxxxxxxxxxx]
Sent: Thursday, July 08, 2004 11:58 AM
To: Midrange Systems Technical Discussion
Subject: Re: CPF8907 on STRPASTHR over AnyNet


Unfortunately I can't offer a solution, only a "me too".  We have AnyNet 
connections configured to many customer systems.  On most it works fine, 
you can STRPASTHR and leave a session connected for hours.  On a few 
customer systems the pass-thru session will end after around 5 minutes 
(whether it's been idle, or even if you are actively keying sometimes). 
We've found that a TELNET session over the same Internet connection will 
stay connected.  WIth a few customers the Telnet sessions were ending, but 
changing either the TCPKEEPALV (on CHGTCPA) or the TIMMRKTIMO (on 
CHGTELNA) would solve the problem.  It seems that AnyNet STRPASTHR 
sessions must use some sort of timeout value from somehwere, but I've 
never had any luck in finding where they get the values from, or how to 
change them.  If you ever do find a solution, please post it to the list.

...Neil




rmweerd@xxxxxxxxx 
Sent by: midrange-l-bounces@xxxxxxxxxxxx
2004/07/06 10:38



To
midrange-l@xxxxxxxxxxxx
cc

Subject
CPF8907 on STRPASTHR over AnyNet


I have a working VPN connection over the internet between two AS/400's 
(one
on OS/400 V4R5M0 and one on V5R2M0). I can sent messages and files between
those AS/400's, I even can STRPASTHR from the one to the other, but after 
5
to 6 minutes I got a CPF8907 (Communication failure) on the source system.
Telnet is, when started, not interrupted, so it's not the real or VPN
connection.


Does anyone has a solution?