Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology
Answers

TCP Connection Failed After Adding New Members

TCP Connection Failed After Adding New Members. We have an HTTPS VIP that targets a pool. The VIP is open to the internet and the SSL cert is on the LTM. Formerly the pool had 2 members within the same compartment as the LTM. We recently added 2 new members to the pool. The new members are actually in a different compartment. The traffic has to go out our compartment's firewall and into the other compartment's firewall. (The other compartment is physically located just across the hall.) When we have these two new members activated, our monitoring tools are reporting "TCP connection failed" errors on 5 to 10% of the connections. We also received at least one complaint from customers about receiving intermittent connection errors. As soon as we deactivate the new members, the TCP issues go away. I am thinking we need to tweak the tcp profile but I am open to any suggestions. We are currently using the default tcp profile. The LTM is currently running 11.4.1 hf8. Thanks!

0
Rate this Question

Answers to this Question

placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

What is the latency between F5 and the old/new pool members ? Normally, you can use WAN profile for the client side and LAN profile for the server side. If the latency is too high, you can try and use the WAN profile on both client and server side as a check.

If you disable the old pool members, are all connections successful ? I am wondering if your network set up may require SNAT by any chance.

0
Comments on this Answer
Comment made 27-Mar-2018 by Polarglock 1

Thanks for the reply. I have asked the F5 admin to see if he can get me the latency between members. My access is limited to read-only via the admin page and we have a leveraged team that handles the hands on changes.

If we disable the old pool members, we are getting successful traffic. Our testing all appeared okay until our monitors showed "TCP connection" errors. We appeared to be getting successful traffic going to both the new and old members during our testing scenarios. The issues were identified while taking live traffic. The monitors are Alertsite monitors with agents throughout the US.

We do SNAT the traffic going over to the other compartment. The new members get the NATs but the old do not.

Thanks!

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

If I understand correctly, you have a virtual server with a client ssl profile (ssl cert on the F5) with a pool including 2 pool members on a separate vlan that's directly connected to the F5, but different the virtual server's vlan. Traffic flows from the internet to the ssl virtual server who then distributes traffic between the two servers on the vlan behind the F5. If you add servers to the pool that are not on a directly connected vlan behind the F5 with a return route through the F5's floating IP, you will have several situations, the main one being asymmetric routing. If that is the case you will probably need to do several things. The first one can be to activate SNAT Automap. This will require you to allow access through your firewalls from the F5's egress floating IP address to the pool members. This will also change the source IP address you'll see on your pool members from the client's IP address to the egress floating IP addresses of the F5s.

By asymmetric routing I mean the following: Client connects to the F5's virtual and establishes an ssl session F5 forwards traffic to selected pool member leaving the client's source address intact Pool member on the new separate vlan receives the request from the client and sends response back directly to client Client gets an error as it gets a response that's not encrypted and from a different IP address he sent the request to

For the connections to work correctly the requests and responses need to flow through the F5's ssl virtual server.

0
Comments on this Answer
Comment made 27-Mar-2018 by Polarglock 1

Thanks for the reply! Yes, you are correct about the flow. The two new members in the other compartment do get SNATed. The old members in the same compartment do not. We do get successful traffic to all 4 members however it appears to be an intermittent issue occurring only when the new members have been activated. We don't see the failures within our environment. We only see the failures coming from the Alertsite monitors with agents external to our environment. We also received complaints from clients.

Thanks!

0