Service breaks when upgrading from 11.3 to 11.5.1
We have a non-browser based service that works on 11.3 but breaks on 11.5.1. Testing is performed using SoapUI... Here is the request that is sent to both 11.3 and 11.5.1: POST HTTP/1.1 Connection: close Accept-Encoding: gzip,deflate Content-Type: text/xml;charset=UTF-8 SOAPAction: "" Content-Length: 680 Host: x.x.x.x:443 User-Agent: Apache-HttpClient/4.1.1 (java 1.5) http://schemas.xmlsoap.org/soap/envelope/" xmlns:iden="http://xxxx.com/xxxx" xmlns:rxc="http://xxxx.xxxxx.xxxxx.xxxx.com/xxxx/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> xxxxxxxx xxxx Here is a good 11.3 response: HTTP/1.1 200 OK Content-Type: text/xml;charset=UTF-8 Content-Encoding: gzip Connection: close http://schemas.xmlsoap.org/soap/envelope/"> ;http://xxxx.xxxxxxx.xxxxxx.xxxxx.com/xxx/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" /> Here is a bad 11.5.1 response: HTTP/1.1 **202** Accepted Content-Type: text/xml;charset=UTF-8 Content-Length: 0 Connection: close Set-Cookie: bbbbbbbbbbbbbbb=FBPHCLGKAACCJNJOBEEPKHOMIJDCALHJHKAKEALGKLNDHFFCBKAMPAJOGAOACCFIACJDCAPEABPIOLKJCOFOMOLHLBKLMNKLKLBFONHDEFKKNCEIDJHKPNMBHDBDOKDF; HttpOnly; secure I have not modified the string directly above, that's the way it appears in the response. I'm thinking it has something to do with the "gzip" format and how 11.5.1 handles it. Both VIPs are configured identically. HTTP Compression is not enabled, it's a pretty basic VIP config, no special profiles or rules. Has anyone run into this? Any thoughts?
Problems upgrading LTM 11.2.1 to 11.5.1
Hello, We are upgrading F5 from 11.2.1 to 11.5.1 version. All is Ok except some issues. First, I don't have any performance statistic. It shows "No records to display." message. The other problem is that in my device group (we have two F5, active-standby), if I see the devices in the avtive one, the avtive is in the right version (11.5.1), but the standby shows de old version (11.2.1), however, both have the same 11.5.1 version. Do you know why it happends? Thank you very much. Regards.LTM 11.5 L4 VS and SSL Persistence terminates IE8 Connections
After upgrading to 11.5 (from 10.x), a Website stopped working with IE8 - FireFox 24.1.1 was working well. (actually in most of the cases just one HTTP Request passed in a 'keep-alive' connection). While troubleshooting I realized, that this issue is caused by the SSL Persistence Profile which was attached to the Virtual Server. The VS is configured as L4 Service (no SSL Termination). I'm aware, that Version 11.5 does not make use of SSLv3. So I think this is somehow related. Anybody else who see the same behaviour?
TCP Pace Yourself
TCP congestion control strives to optimize network goodput while minimizing packet loss by moderating transmission speed. Unfortunately, the way that congestion control moderates transmission often results in microbursts which can overflow buffers on switches and routers. This packet loss in turn triggers congestion control to moderate transmission speeds by reducing the congestion window; TCP then ramps up and the cycle repeats. This oscillation between under and over utilization of the network, combined with retransmission delays due to packet loss, cause application performance challenges and poor user experience. How does congestion control work? TCP moderates its transmission speed by calculating a target number of packets to keep in flight. This is the congestion window (cwnd). Typically, the congestion window starts out small and is increased each time the remote system acknowledges receipt of the packet. In addition to adjusting the congestion window, TCP compares the congestion window to the number of packets in flight on the network. In the event that the congestion window is greater than the number of packets in flight, the stack will transmit the difference between the two. When do packet bursts occur? Stretch ACKs are acknowledgements that cover 2 or more segments of unacknowledged data. It is possible based on network conditions that a stretch ACK will result in the acknowledgement of all the in-flight packets. When this happens, the TCP stack’s accounting of the number of packets in flight goes to zero and the stack transmits a sudden burst of traffic to bring the in-flight total back up to the calculated congestion window value. The exponential growth phase of TCP can also trigger packet bursts. During the exponential growth phase, the TCP stack doubles the number of packets in flight each roundtrip time. On high bandwidth high delay networks, these packets travel as a tightly packed group. Once they arrive at the receiver, ACKs will be generated in response. Because of the close arrival time of each of the data packets, the ACKs will also travel as a group. When this tight cluster of the returning ACKs arrives back at the sending system, a burst twice as large as the previous one is generated. Rate Pacing to the Rescue To mitigate this bursty behavior, F5 introduced rate pacing to TCP Express in v11.5 of BIG-IP. Rate paci ng analyzes the traffic on a per flow basis to determine the best speed at which to transmit packets. Rate pacing sends packets at the rate of the slowest draining buffer, resulting in a much smother packet transmission as illustrated to the right. By sending data at a steady pace, large bursts of packets are prevented from traversing the network and causing buffer overflows.
