Maximum number of TCP connections to LTM - is there a limit?
Hello, I am wondering if there is any system level restriction on the maximum number of TCP connections that can be opened to an LTM version 10.2.4 and 11.5.2. Is the limit determined by the system memory or are there any other constraints?
BigIP exhibiting TCP zero Window behavior and closing connection
We have a VIP on our BigIP that sees a lot of connections. The TCP profile applied to the VIP is TCP Progressive with no Nagle. What we are seeing is after a very small amount of data the Window size on the F5 Self IP to Server connection is going to zero. The back-end server is able to maintain its buffer levels. The intention of applying a progressive profile was to take care of varying conditions and connections. We saw over 600 TCP Zero Window instance from the F5 to the server. all being sent by the F5. I am not sure what tweaks to the TCP profile i need to do to solve this problem.iRule to close an established connection
I have tcp (not http) based service where client connections are permanent. By that I mean that once a connection to a pool member gets established its stays there 24x7. The pool has 2 pool members configured with priority group. The first pool member has priority 2 and the second one priority 1, with a Less than '1' value for Priority Group Activation. The pool also has the setting of 'Reject' for 'Action On Service Down'. That takes care of any scenario where a pool member is marked down by health monitors. Whenever a highest priority pool is marked down by health monitors all established connections to that pool members get closed automatically. The client applications immediately try to reconnect and get established connections to the second pool member with the lower priority. So far, everything is exactly what we want to accomplish. The challenge comes when the higher priority pool member is marked up/available once again. We're looking for an automatic way to close the already established connections to the lower priority pool member as soon as the higher priority pool member becomes available. Is there a way to do so? Not sure what event I should use for an already established connection. First ones that came to mind were LB_SELECTED and CLIENT_ACCEPTED. So far, I've tried the following options without any results: when LB_SELECTED { if { [LB::status pool poolname member 10.0.0.1 80 ] equals "up" and [IP::addr [LB::server addr] equals 10.0.0.2] } { reject } } when LB_SELECTED { if { [LB::status pool poolname member 10.0.0.1 80 ] equals "up" and [IP::addr [LB::server addr] equals 10.0.0.2] } { LB::reselect pool poolname member 10.0.0.1 } }Huge number of TCP 3WHS rejected (bad ACK), chksum incorrect
Hi guys, Hope you can help me with this, for me, complete mystery. I'm getting lots of following: Wireshark text export from F5 tcpdump: 4815 17:27:58.597830 CLIENT_IP F5_VS_IP TCP 162 36562 → 443 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=681665250 TSecr=0 WS=128 4816 17:27:58.597846 F5_VS_IP CLIENT_IP TCP 193 443 → 36562 [SYN,ACK] Seq=0 Ack=1 Win=4380 Len=0 MSS=1460 TSval=751619333 TSecr=681665250 SACK_PERM=1 4817 17:27:58.660439 CLIENT_IP F5_VS_IP TCP 185 36562 → 443 [ACK] Seq=1 Ack=1 Win=29200 Len=0 TSval=681665313 TSecr=751619333 4818 17:27:58.730179 CLIENT_IP F5_VS_IP TLSv1.2 380 Client Hello 4819 17:27:58.730201 F5_VS_IP CLIENT_IP TLSv1.2 4529 Server Hello 4820 17:27:58.792837 CLIENT_IP F5_VS_IP TCP 185 36562 → 443 [ACK] Seq=196 Ack=4345 Win=37648 Len=0 TSval=681665445 TSecr=751619465 4821 17:27:58.792854 F5_VS_IP CLIENT_IP TLSv1.2 706 Certificate, Server Hello Done 4822 17:27:58.855416 CLIENT_IP F5_VS_IP TCP 185 36562 → 443 [ACK] Seq=196 Ack=4866 Win=40544 Len=0 TSval=681665508 TSecr=751619528 4823 17:27:58.857719 CLIENT_IP F5_VS_IP TLSv1.2 543 Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message 4824 17:27:58.857731 F5_VS_IP CLIENT_IP TCP 185 443 → 36562 [ACK] Seq=4866 Ack=554 Win=4933 Len=0 TSval=751619593 TSecr=681665510 4825 17:27:58.859778 F5_VS_IP CLIENT_IP TLSv1.2 276 Change Cipher Spec, Encrypted Handshake Message 4826 17:27:58.923739 CLIENT_IP F5_VS_IP TLSv1.2 670 Application Data 4827 17:27:58.923793 F5_VS_IP CLIENT_IP TCP 185 443 → 36562 [ACK] Seq=4957 Ack=1039 Win=5418 Len=0 TSval=751619659 TSecr=681665576 4828 17:27:58.923981 F5_FLOAT_IP SERVER_IP TCP 193 1360 → 8080 [SYN] Seq=0 Win=4380 Len=0 MSS=1460 TSval=751619659 TSecr=0 SACK_PERM=1 4829 17:27:59.923626 F5_FLOAT_IP SERVER_IP TCP 193 [TCP Retransmission] 1360 → 8080 [SYN] Seq=0 Win=4380 Len=0 MSS=1460 TSval=751620659 TSecr=0 SACK_PERM=1 4830 17:27:59.923874 SERVER_IP F5_FLOAT_IP TCP 173 [TCP ACKed unseen segment] 8080 → 1360 [ACK] Seq=1 Ack=993763571 Win=29845 Len=0 4831 17:27:59.923882 F5_FLOAT_IP SERVER_IP TCP 209 1360 → 8080 [RST] Seq=993763571 Win=0 Len=0 4832 17:28:00.923733 F5_FLOAT_IP SERVER_IP TCP 193 [TCP Retransmission] 1360 → 8080 [SYN] Seq=0 Win=4380 Len=0 MSS=1460 TSval=751621659 TSecr=0 SACK_PERM=1 4833 17:28:01.923650 F5_FLOAT_IP SERVER_IP TCP 181 [TCP Retransmission] 1360 → 8080 [SYN] Seq=0 Win=4380 Len=0 MSS=1460 SACK_PERM=1 4834 17:28:01.923822 SERVER_IP F5_FLOAT_IP TCP 173 [TCP ACKed unseen segment] 8080 → 1360 [ACK] Seq=2408178215 Ack=1538671403 Win=30282 Len=0 4835 17:28:01.923845 F5_FLOAT_IP SERVER_IP TCP 209 1360 → 8080 [RST] Seq=1538671403 Win=0 Len=0 4836 17:28:02.923550 F5_VS_IP CLIENT_IP TCP 204 443 → 36562 [RST,ACK] Seq=4957 Ack=1039 Win=0 Len=0 4837 17:28:02.923561 F5_FLOAT_IP SERVER_IP TCP 204 [TCP ACKed unseen segment] 1360 → 8080 [RST, ACK] Seq=1 Ack=591246314 Win=0 Len=0 F5 tcpdump sees following (this is for different case): F5_FLOAT_IP.27216 > SERVER_IP.8080: Flags [R], cksum 0x95b2 (incorrect -> 0x0a17), seq 3911139265, win 0, length 0 out slot1/tmm10 lis=/Common/https_production flowtype=128 flowid=5618A9EEBE00 peerid=56189FD35F00 conflags=4000024 inslot=2 inport=9 haunit=1 priority=3 rst_cause="[0x2b07e6a:2314] TCP 3WHS rejected (bad ACK)" peerremote=00000000:00000000:X:X peerlocal=00000000:00000000:X:X remoteport=59656 localport=443 proto=6 vlan=4093 It is hitting constantly, and quite a lot. As per "K13223" this represent "The BIG-IP system failed to establish a TCP connection with the host (client or server) due to a failure during the TCP 3-way handshake process." In my case it is communication between F5 and server pool (all nodes affected). There is no firewall between F5 and server pool(s). It is happening with both AutoMap and SNAT. Are there any guides/cases how to debug this issue further? Mine test shows that it's not connected with client type (browser, curl, ...) or URL (same URL works in 99 percent of cases, that 1% is what's bothering me). Thank you!
LTM :: Zero Window Server Side :: TCP Profiles
We have a virtual server setup for our receiving mail system, and it has been configured as-is for quite some time (measured in years). Never before has an issue arisen, but recently a particular client has been having problems sending attachments to us (and as far as we are aware, ONLY that client). What they claim to see is that the connection is terminated. Normal email works fine. Small file attachments work fine. However when they send us attachments that are Mb in size, the connection will not be successful. On our side, we see the window size slowly creep down until it hits zero. The BIG-IP probes the mail system, the mail system acks the probe, but keeps the window size at zero. It does this until the zero window timeout is reached on the BIG-IP and the connection is terminated by the BIG-IP (TCP RST). This is what the window decrease looks like on the client side (tcp.stream eq 3 and ip.src eq [the mail system]): This is what the window decrease looks like on the server side (tcp.stream eq 2 and ip.src eq [the VIP]): Client side end of the connection: Server side end of the connection: My impression initially was that this is not a BIG-IP problem... but when we remove the BIG-IP from the path, the connection works fine regardless of attachment size. Again, works fine for everyone else as far as we know regardless of if the BIG-IP is in the path... which is perplexing. Things I've tried: * Switching-out TCP profiles (lan optimized, wan optimized, client and server matching and different in combinations of the above). Now on mptcp-mobile-optimized with defaults. * Moving TLS off of the F5 * Resetting TLS profile to defaults * Different mail systems (of same type/configuration) Current configuration: * VIP on port 25 * TCP profile with mptcp-mobile-optimized w/defaults * SSL Profile (defaults w/cert, optional SSL, allowed cipher suites) * SMTPS Profile (allows TLS) * Pool w/single mail system * iRule w/VIP bounceback * Source IP Persistence VIP bounceback iRule: when LB_SELECTED { if {[IP::addr "[IP::client_addr]/24" equals "[LB::server addr]/24"]} { snat automap } else { snat none } } Any ideas/thoughts/suggestions all welcome. Thanks for taking the time.
HTTP Post across Mutiple TCP Segment
When attempting to send HTTP post request across multiple TCP segments the request fails. We receive a response that HTTP Body is missing from the server. . But if i send the same HTTP post request across multiple TCP segments directly to the server it works perfectly (without F5). Moreover a different HTTP request to the same server in a single TCP segment iworks fine. I am using no Irule ,simple http profile is applied . Any help would be appreciated
LTM default behavior on long lived tcp connection when server went down
Hi all, We are planning to use F5 LTM to enhance the availability of the overall solution. In our application, the client uses long-lived TCP connection to connect to the server and once the connection is established the client will send multiple asynchronous requests using the same connection (unlike HTTP protocol). This connection will not be closed unless the server or the client decides to terminate. Now, let's put F5 LTM between the client and the server. The plan is to have multiple application server nodes behind LTM to enhance the availability. My question is.. When the client is communicating with the server via LTM, and then TCP connection between the LTM and the server application gets disconnected (due to server application process crashed, network between LTM and server disconnected, the whole application server box shuts down, etc), will LTM detect this connection failure and automatically disconnect the connection between the LTM and the client? In other words, when this happens will client notice there is a connection failure and it needs to try to re-establish the connection? I assume this question is not specific for long-lived TCP connection only, but also to other protocol (such as HTTP). Has anyone checked what happens to the browser if the web server suddenly goes down when the request from the browser is being processed (the connection between browser-LTM-webserver is still established)? Will the browser get 'connection reset' error too?
HTTP profile & SSL profiles not playing nice.
So I am attempting to set up a VS that is HTTPS (443) listening and HTTPS (443) pool members. I use a standard VS. Here is where it gets interesting. If I DO NOT use an HTTP profile the HTTPS/SSL connection get proxied to the pool server just fine. If I add an HTTP profile and a certificate based Client SSL profile with standard Server SSL profile the connection does not work. However, if I changes the Client & Server SSL profiles to Proxy the SSL it works again. I appears that having the F5 be the "man in the middle" is not being accepted by the back end pool member. I am not sure why this would be the case, but I have run myself into the ground messing with profiles and having the server admins changing setting on the servers. I am at a loss as to why this would happen. Does anyone have any insight? What more info do you need? (I am limited as to what I will be able to provide)
