OneConnect Transformations reuse from same source IP address and port number?

Yes, I believe that it will reuse the same server-side connection. I don't know what you mean by the delay of the connection with 2MSL? What is that?

The connection from the same IP address and port number is ignored for a 2MSL time.

 

Refer to

 

http://johnleach.co.uk/words/archives/2006/03/08/212/

 

 

I think that this problem doesn't occur, if an existing server-side connection is recycled.

 

(I do not want to use OneConnect for reasons of security. )

 

 

Keepalive connections aren't "recycled" per se, they are kept open & re-used: The connection is maintained open unless idle timeout or max requests is reached. Once the idle timeout or max requests force the server to close the connection, normal close mechanics apply & connection may go into TIME-WAIT for 2MSL, preventing connections to the same IP:port tuple. (YMMV depending on any stack optimizations for faster socket re-use.)

 

 

OneConnect transforms just change non-keepalive connection requests on the client side to keepalive connections on the serverside. So with OneConnect transformations enabled but OneConnect not, I'm fairly certain that the net effect is really null, or perhaps even negative for your servers: If a client initiates a non-keepalive connection, the client will never re-use that client-side connection, but the server may hold that connection open until the client side connection closes or the default serverside keeplive timeout expires.

 

 

Even with OneConnect enabled, access by the same clientside IP:port are not guaranteed to use the same serverside connection -- that connection may already be in use by another clientside flow. Setting the OneConnect mask to host (32 bit) is the best way to maximize that possibility.

 

 

HTH

 

/deb

There is Reverse Proxy on the client side of BIG-IP, and it has translated source IP address by PAT. When Reverse Proxy reuses the same port number too early, the delay of the connection due to 2MSL is occurred.

 

 

Does not be occurred the delay, when the connection of the server side is keep-alive as OneConnect Transformations enabled (without OneConnect Profile)?

 

 

 

 

I don't think that will help, since the problem is on the client side, not the server side.

 

 

OneConnect and OneConnect transformations are both intended to manage the serverside connection, and as far as I know won't change any behaviour affecting the clientside flow.

 

 

It might be worth opening a Support case to see if there is a way to reduce the MSL value LTM uses.

 

 

/deb

I think that the problem is not occurred on the client side, when Time Wait Recycle of the TCP profile is enabled.

 

 

It is a story in the design, and I do not have the problem now.

 

 

Thanks.

Excellent, good to know.

 

 

Looks like the "Time Wait Recycle" setting in the TCP profile allows LTM to ignore TIME_WAIT state & establish a new connection if a new SYN is seen.

 

 

You can also shorten MSL to hasten the natural close mechanics instead of ignoring them by shortening the "Time Wait" setting to 500ms, which is a more realistic value in todays networks than 2 seconds.

 

 

/deb