Any questions? Post'em

Hi Mike,

 

 

my customer also Global F5 customer

 

The customer has Redundant pair LTM 6400 and we put on the some other customer datacenter, we use simple irule for host based load balancing and enabled compression.

 

We saw 350-400 mbits throughput on peak time and Cpu usage was %60. So i want to sell Bigip to the datacener admin but he ask me everytime if we use irule we will have cpu problem (guy is alteon expert) his existing topology alteon load balance + Redline and he is happy.

 

 

i see same question on customers site if we use iRule what will be CPU usage.

 

 

Not: i have some spesification for L4,L7 ,compression,SSL and Throughput.

 

can we see same performance when we use all feature at same time

 

 

if you help me i will be very happy

 

 

if you want you can send me email directly

 

 

regards

 

 

zafer

Hi Sweta,

 

 

The different load balancing algorithms are detailed in the LTM configuration guide on AskF5.com. If you take a look at the doc for your version and have questions, reply here.

 

 

Aaron

hi i am into support for web services in weblogic server, i want to know the differences between using load balncing algorithms(round-robin,random,weight-based) and using server affinity load balancing algorithms?

 

also differences between using HttpClusterServlet proxy and hardware load balancer(BIGIP)?

 

from,

 

sweta

Thanks Roger, we updated your suggestion to our network team, what we found out they did changes for MTU at Cisco router level and it didn't worked either. The one thing we found out after careful analysis of ethereal trace, that difference of SSL record length at BigIP (16k) and POS (9k) is not a problem at all, as the record length never hit 9k at any time. Any way we are implementing an alternative solution kind of dirty work to download small chunks many times, which is a performance issue, but can be operational. Appreciate if you or anybody have any other suggestions.

 

 

Leaving this problem unsolved, kind of sad and unchallenging....but given time frame and customer satisfaction we have to live with that.

 

 

Thanks Roger, we'll try your suggestion. Mean while can you pls. clarify few things for me, to enable me to explain the changes to our network team clearly.

 

 

- Is enabling Proxy MSS option is in TCP Profile options (what is virtual that you are suggesting)? Can you pls. elaborate on this?

 

 

- Can we fix the size of MSS at application server (we use IPlanet), so that we don't get into the problem with BigIp splitting the packets.

 

 

Mike,

 

 

We have contacted Big IP, we send our ethereal trace logs to them, but we are not getting accurate info/solution from them. Mean while we are spinning other threads to resolve this problem.

 

 

We have tried "proxy buffer high" to 4096, it didn't worked. But the problem looks like something to do with SSL packet size at BigIP (16k) and POS device(9k) only. According to Ethereal trace we found that

 

 

- Could able to transfer large chunk of data from POS device to server with out using SSL (just over http port 80), but failed to download the data when we use SSL.

 

 

- When we looked at ethereal trace we found “SSLV3 unreassembled packet”, then after some time it says "[TCP window Full]Encrypted Alert" after the initial handshakings.

 

 

- BigIP says we can not limit the size of SSL to 9k on our BigIP.

 

 

- We tried sending small chunk of data (around 5k) every time with little delay in between, kind of pagination, but we didn’t see any difference.

 

 

Is there any suggestions you can throw, kind of we are stuck in our production.

 

 

Well there was no difference even reading more than 500 bytes every time. We'll try with "proxy buffer" settings and we also try to get some help from BigIP support. Thanks for your suggestions Mike.

It's likely what you're seeing with the varying size of the reads are SSL record boundaries. Reading 500 bytes at a time is quite small. I suspect this is a really slow client machine or distant network connection? Another possibility would be that BIG-IP supports more ciphers than the server itself, so perhaps the communications between the client and BIG-IP is using a different cipher compared to the communications when testing client to server directly.

 

 

BTW, you might try changing the proxy buffer to a smaller value like 4k. This is just a shot in the dark, though. A tool like ssldump can read packet captures taken from BIG-IP and help to interpret SSL behaviors. If you use a common cipher (like RC4-MD5), you can use ssldump together with your SSL private key to actually decrypt the SSL connection and see the data, and more important, see if what (if any) SSL alerts are occurring.

 

 

I'm sorry I can't be more help. This sounds like an odd situation. :) If you can capture a tcpdump of a successful connection and a failed connection, I'm sure that would really help the support team to figure things out. If there is an example of good and bad behavior, then it's just a matter of figuring out what's different between the two to then solve the problem. :)

 

 

Good luck!

 

 

Mike Lowell

Thanks a lot for your detail explanation Mike.

 

 

We already changed the value of 'send buffer' to 4k and 8k and we also changed the value for "recv window", it didn't worked. One interesting thing we have observed is read pattern in case of successful response and partial response. When we get complete response it reads 500 bytes every time except the last one, which reads what ever remaining bytes. In case of partial response it also reads 500 bytes, but in between it reads 175 or 400 bytes, kind of little irregular read pattern and looks like the data is getting obstructed some where in BigIP, as it could able to read only 175 or 400 bytes instead of 500 bytes what we are trying to read every time. Does it give any hint to you? As we are communicating over SSL, is there any specific profile for SSL need to be tweaked for this problem. We don't suspect the server problem, as we could able to read same response from internet explorer and a java client program. We'll also try to contact BigIp support, however any suggestion from you is really great to us. Please let us know if you have any ideas? Thanks again Mike.

 

 

You mention TCP/HTTP, so I'm guessing this is XML being transported over HTTP. If that's the case, then no BIG-IP tweaking should be required for normal clients/servers.

 

 

Unless you ask BIG-IP to do otherwise, it'll treat XML responses just like image responses or web pages or zip files, or anything else. 60KB isn't even that big. :)

 

 

With regards to the magic size, I suspect this has something to do with the client or server. The closest magic number on BIG-IP is 32768, which is the maximum size of HTTP headers we'll accept by default (this is configurable on the HTTP profile).

 

 

Your comment about SSL packet size (actually SSL record size) is likely the key. BIG-IP will attempt to send large SSL records because it's normally in the best interests of all that are involved (it's faster for both BIG-IP and receiving devices to deal with fewer large SSL records than many small records).

 

 

Whether BIG-IP is going to use large records or small records depends on the speed of the clients and servers (how quickly we're getting data from the server and how quickly the client can receive it from us).

 

 

It's very normal to see multiple SSL record sizes used throughout a single transaction. With that in mind, if the client really cannot accept 16KB SSL records, then it seems reasonable to think that the 19KB magic number could actually be a combination of a 1 or few small records (1KB-4KB) and perhaps followed by a 16KB record which doesn't work.

 

 

It would be very unusual for a device to not support 16KB records, but if that really is the case perhaps the problem could be worked around by limiting BIG-IP's TCP 'send buffer' parameter on the TCP profile, or perhaps reducing the 'proxy buffer high' to something small like 4096. This is just a guess, I don't have an easy way to test this.

 

 

Given your situation, I encourage you to contact the F5 Networks support team to work through the issue.

 

 

Good luck!

 

 

Mike Lowell