F5 FastL4 but need HTTP header insert

It is quite possible that the F5 BIG-IP box is trying to compress already-compressed data; I'm almost positive that it doesn't uncompress responses at all. The typical operation if compression is enabled is that the BIG-IP will not forward the Accept-Encoding header if the BIG-IP is taking responsibility for compressing content so that the server will not send compressed content; there is a compression profile option to override this (usually desirable) behavior.

 

 

If you care less about compression on the client side of the WAN, then you should disable it completely on the appropriate VIP(s) on the BIG-IP, and leave the compression to the remote load balancers; that would also send fewer bytes across the WAN link.

 

 

If you can't get packet traces, then you might want to look at iRules (particularly the HTTP_REQUEST_SEND and HTTP_RESPONSE events) to log the headers that the BIG-IP box is sending and receiving. If the BIG-IP is inappropriately compressing only some responses, then you might be able to tweak that behavior, either via compression profile options or additional iRules.

 

 

The real problem is that "just passing traffic" is fundamentally incompatible with "needing to insert HTTP headers". To insert a header, you need to know where to insert it, so you need to parse the HTTP data. Then, if you just pass the traffic, you also have to handle retransmissions, not to mention out-of-order packets. In short, "need to insert HTTP headers" really translates to "need to buffer and parse data and not just forward it".

 

 

If you only need to insert headers on the client requests, and not change server responses at all, then you might consider an nPath (aka Direct Server Return) configuration, though this may require changing your SNAT/NAT configuration.

 

 

I'm a little surprised that FastHTTP wasn't working for you, though, as it comes closest to "fastL4 + header insert", but you didn't mention how it didn't work. If it also showed the same bad latency, then that would almost certainly point to misconfiguration or other problems outside the BIG-IP. That said, FastHTTP is optimized for ideal conditions, which you may not find in your network.

 

 

Finally, F5 also sells products for optimizing HTTP across WAN links; you may want to look into those.

If you care less about compression on the client side of the WAN, then you should disable it completely on the appropriate VIP(s) on the BIG-IP, and leave the compression to the remote load balancers; that would also send fewer bytes across the WAN link.

 

 

This indeed what we did; it is probably what is occuring now; and may explain some of the speedup when compression is off.

 

 

On the other hand, I am sorry to say, we verified that the content is uncompressed, even if we ask for it with the "compress disable" option. I have no idea if it is compressed on the backhaul from the origin load balancers.

 

 

I'm a little surprised that FastHTTP wasn't working for you, though, as it comes closest to "fastL4 + header insert", but you didn't mention how it didn't work. If it also showed the same bad latency, then that would almost certainly point to misconfiguration or other problems outside the BIG-IP. That said, FastHTTP is optimized for ideal conditions, which you may not find in your network.

 

 

I was looking through my notes and emails and trying to get some more details. Unfortunately, my recollection is a bit sketchy. At best, I remember that it did not seem to perform as well, but that could be lack of experience at the time (first time setting it up back then).

 

 

What would be perfect for this scenario is to get an example configuration that I could try; I have access to some testing VIPs and can provide a lot more information if I have a starting point.

 

 

Could someone post a code snippet for FastHTTP that might work with header inserts of client IP?

we verified that the content is uncompressed, even if we ask for it with the "compress disable" option.

 

 

 

That's progress, at least. You should enable compression on the origin load balancers (on the other side of the WAN link) and see if that helps.

 

 

Since you don't know where the problem is, and you can create test VIPs, then I would suggest starting with a vanilla fastL4 VIP, and actually have your test client send the request with the header already in it. That way you turn the BIG-IP into as transparent a box as possible. From there, you can narrow things down.

That's progress, at least. You should enable compression on the origin load balancers (on the other side of the WAN link) and see if that helps.

 

 

The original load balancers do have compression turned on if the client requests it; the F5 appears to disable this or block it (just a guess; with compression disabled, the content is always clear text, even when requested with headers).

 

 

It appears that FastL4 is not any "better" than using http-wan-optimised and is worse because we cannot do the header insert for the client IP. Using FastHTTP is frustrating because it looks like we cannot use Irules or oneconnect (oneconnect saves us .2 - .3 seconds across the Atlantic).

 

 

Barring any further ideas, we are going to turn on compression anyway because we feel that compression is the correct setting, even if it causes some machine-measurable slowness.

The original load balancers do have compression turned on if the client requests it; the F5 appears to disable this or block it (just a guess; with compression disabled, the content is always clear text, even when requested with headers).

 

 

 

I've just reverified that the BIG-IP will not remove the Accept-Encoding headers on an HTTP vip with "compress disable"; they pass through to the server unchanged in my setup. Do you have any iRules that might be removing or altering them? Again, if you setup a test vip, you can see log the headers sent in the HTTP_REQUEST_SEND event to see if they are making it through the BIG-IP.

 

 

It appears that FastL4 is not any "better" than using http-wan-optimised and is worse because we cannot do the header insert for the client IP. Using FastHTTP is frustrating because it looks like we cannot use Irules or oneconnect (oneconnect saves us .2 - .3 seconds across the Atlantic).

 

 

 

If you're not seeing any better performance with fastL4, then FastHTTP will also not improve performance. That said, FastHTTP does support OneConnect (indeed, it's mandatory and built-in; no separate OneConnect profile is needed) and has limited iRule support. Also, FastHTTP cannot be configured with compression on the BIG-IP (meaning that uncompressed server responses will not be compressed; any responses that the BIG-IP receives that are already compressed will be forwarded to the client still compressed, just like with the standard HTTP profile).

 

 

I hope this helps.