[load balancing] extracting TCP option info

good day all, we have been struggling with IRule to extract some info that is embedded in the TCP Option header and have it as "X-Forwarded for" in the http header destined to the server. does anyone know if F5 gears can do this at all? we are evaluating some ADCs and it seems that Netscaler can do it but not F5!! has anyone done anything similar to this? tony ________________________________ From: Kenneth Salchow <k.salchow [izzat] f5.com> To: Load Balancing Mailing List <lb-l [izzat] vegan.net> Sent: Thursday, September 10, 2009 5:51:18 PM Subject: Re: [load balancing] Quick questions about f5's iRules If you want marketing speak—you need me, not Kirk. ;-) Seriously, you folks have hit upon some of the most basic frustrations that we at F5 have had concerning iRules since their release—particularly with the v9.0 upgrade. Marketing FUD from competitors has obfuscated a couple of points that Kirk makes; like, the events are always firing and the iRules engine is always running. Competitors like to put us in bake-offs and paid-for testing with “a simple iRule” that they never share in the results and then comment on how our performance suffers “simply by turning iRules on”. This is ludicrous, but to people who haven’t worked with our gear and iRules specifically—the numbers say it all. I think I’ve said it on this list a thousand times—we have a long history at F5 of giving our customers plenty of rope with which to hang themselves. It started with Extended Content Verification (ECV) checks over a decade ago that allowed you to execute full shell scripts in order to validate the availability and performance of the server application you were providing HA for. This was unparalleled capability at the time (and still beyond some implementations)—but naturally allowed customers (myself included at the time) to do some really, really bad things to ourselves, our networks and our kit. iRules are really no different. We have provided a fully extensible and flexible capability to change the very nature of application delivery that can meet the unforeseen needs of tomorrow, not just today; that means a lot of ability to break things today. What was that line from Spiderman: with great power comes great responsibility?? ;-) So—don’t take my word for it. Don’t take Kirk’s word for it (although take his word on this over mine any day). Go to http://devcentral.f5.com/ and talk to the people there who make a living doing iRules and iControl. Write your iRule and test it for yourself to see how it impacts YOUR application. If the impact is significant, submit it to DevCentral and see if someone can provide you some ideas how to optimize it—or maybe even do what you’re trying to do a completely different way. I know it would be nice if we could just say—yeah, it will hit you by 10 milliseconds—but it’s just not that simple. Even if a single iRule doesn’t have a massive impact, if you run it on every connection and handle Gbps traffic volumes—it will add up. Great discussion though—and I wish you the best of luck achieving your solution. KJ (Ken) Salchow, Jr.| Manager, Technical Marketing D 651.423.1133 M 612.868.1258 P 206.272.5555 F 206.272.5555 www.f5.com From:lb-l-bounces [izzat] vegan.net [mailto:lb-l-bounces [izzat] vegan.net] On Behalf Of Kirk Bauer Sent: Thursday, September 10, 2009 9:16 AM To: Load Balancing Mailing List Subject: Re: [load balancing] Quick questions about f5's iRules (all of the below is my personal opinion and not any official F5 stance) Of course you are correct, F5 does not and can not guarantee any performance level with iRules in use. It completely depends on what the rule does. As various other replies have mentioned, we do our best to make the iRule engine very efficient, we provide timing abilities to help you tune your iRules, and DevCentral provides a wealth of resources to help you tune iRules for greater efficiency. However, if you want to write an iRule that runs a series of complex mathematical operations on every character in a 512K web page, you can do it, and it will be resource-intensive. Now, for the rest of your questions, I have to mention that I have not seen the source code for any F5 products so I can’t provide you any answers with 100% certainty, but in my understanding: 1) iRules are pre-compiled so we get by with very little overhead apart from the actual commands the iRule runs 2) The iRule engine is always loaded: so going from 0 iRules to 1 simple iRule has minimal impact. 3) All of the events already “fire”, even if no iRules are attached, so again adding a simple iRule has minimal impact. 4) Each connection runs iRules in its own context. So if you have 10,000 active connections, you have up to 10,000 parallel executions of iRules. The rule doesn’t have to complete on one connection before it can run for another. I would consider this very multi-threaded. 5) None of our built-in features are done with iRules, however over the years a number of iRules have been turned into built-in features. I don’t think we have any performance numbers showing how much performance increased, but presumably it did increase a little. You make a good point about L7 versus L4 iRules. In my experience, L4 iRules tend to be very basic and hence extremely fast and efficient. For example, this popular iRule is called “Selective SNAT” which basically will enable SNAT only if the client and the real server are on the same subnet. This eliminates the common problem of a server hitting its own VIP and then that other server responding directly to the first server and bypassing the load balancer. if { [IP::addr [IP::remote_addr] equals [LB::server addr]/16] } { snat automap } The IP::addr command is a built-in command that already does IP/subnet comparisons very efficiently. The IP::remote_addr and LB::server_addr are just hooks into data that is already sitting in memory regarding the connection. The “snat automap” is a built-in command to change ourselves to SNAT mode. So, effectively, by adding this iRule to a virtual server, you are doing one IP address comparison that you would not have done if you just always turned SNAT on. If you think of all of the other calculations that are performed to perform a load balancing decision, this should be a very small percentage in general. From:lb-l-bounces [izzat] vegan.net [mailto:lb-l-bounces [izzat] vegan.net] On Behalf Of Erhan Dolak Sent: Thursday, September 10, 2009 5:49 AM To: 'Load Balancing Mailing List' Subject: Re: [load balancing] Quick questions about f5's iRules Good Day Kirk, I know that most of the vendors does not commit or guaranty the performance or give any performance figures when scripts are used and surprised about your comments. Performance has two dependencies, developer brightness and how the platform handles and executes the code. You may control the second one only to commit best performance J From development perspective, it may be very nice if you could give more detail about how this irules scripts are running on the platform without breaking your company privacy rules. is there any compilation task to convert the script to machine code before executing to achieve the efficiency you described. Also is it possible to create multithread irules scripts or run it in multithread mode? and last question, is there any irules used inside F5 by default to accomplish some basic features defined in the datasheet of the product, so that we can compare the compiled code and irules performance. I always thought that scripting is the weakest link of this kind of platforms and any web application. For “web application load balancing”, the execution delay (not the cpu/memory usage) due to scripts can be understandable and can be seen as part of the web app code but for TCP/UDP load balancing I always prefer to have functions are available in the product in enterprise level solution instead of calling a script. Each hook means delay and resource usage and loading the scripting engine to the memory. Regards, Erhan DOLAK From:lb-l-bounces [izzat] vegan.net [mailto:lb-l-bounces [izzat] vegan.net] On Behalf Of Kirk Bauer Sent: Tuesday, September 08, 2009 8:58 PM To: Load Balancing Mailing List Subject: Re: [load balancing] Quick questions about f5's iRules 1) iRules are event-driven which means you can attach iRule code to various events that already occur in the BIG-IP system. The standard full-proxy mode already fires all of these events, whether or not iRules are being used. So there is no immediate performance impact just by attaching an iRule to a virtual server: in other words, the BIG-IP or the specific virtual sererv will not change modes and become less efficient just because iRules are being used. However, there will be some CPU time required to run the actual iRule code. This is very efficient, and for most iRules (which tend to be fairly trivial) the performance impact is negligible. However, you can do just about anything you want in an iRule, so it is possible to significantly affect performance by creating a very intensive iRule. 2) There are no published tests because each iRule is different. However, BIG-IP includes some great timing functionality so you can determine how much CPU time your iRules utilize, and so you can optimize your iRule by making changes and observing the effects. From:lb-l-bounces [izzat] vegan.net [mailto:lb-l-bounces [izzat] vegan.net] On Behalf Of Joo Yong-Seok Sent: Tuesday, September 08, 2009 10:46 AM To: Load Balancing Mailing List Subject: [load balancing] Quick questions about f5's iRules Hello Load-balancing Gurus, I have simple questions about f5's iRules. Please share your experience if you have anything :-) 1) f5's iRule can impact their L4/L7 performance? it means if we're turning on the options, there is any performance degradation or improvement?(maybe upt to iRule script) 2) If there is any official marketing data in regards of iRule test, where can I get? (like Tolly group report). Thanks in advance. Best regards, - yongseok

_______________________________________________
lb-l mailing list
lb-l@vegan.net
http://vegan.net/mailman/listinfo/lb-l
Searchable Archive: http://vegan.net/lb/archive
http://lbdigest.com Load Balancing Digest
http://lbwiki.com Load Balancing Wiki
Received on Thu Sep 10 14:40:23 2009