Re: extracting TCP option info
"Greg Howett" <[email protected]> Fri, 11 Sep 2009 00:30:32 +0100
| Newsgroups | gmane.comp.programming.load-balancing.general |
|---|---|
| Message-ID | <[email protected]> |
Hi all, Sometime ago we developed a free ISAPI filter for Microsoft IIS servers to read the x_forward_for value from our load balancer ( or any one elses) and record it as the source IP in the IIS Log files. Please swe link below as it may be usefull for someone. http://forum.jetnexus.com/forum_topics.asp?FID=5 kind regards Greg On 10 Sep 2009, at 23:01, "Tony Hosseiny" <[email protected]> wrote: > We have some intermediary devices that take the incoming source IP > address and insert it as an option into the TCP header and perform > NATing before forwarding it. > > Now we want to be able to extract that IP address from the TCP > Header options and insert it into the header destined to the server. > > I hope it is clearer now, > thanks, > tony > > From: Ed Toro <[email protected]> > To: Load Balancing Mailing List <[email protected]> > Sent: Thursday, September 10, 2009 10:29:54 PM > Subject: Re: [load balancing] extracting TCP option info > > The TCP options field is user defined. It usually has zeros in it > and some firewalls will zero it out regardless of what is there > because it can be used as a hidden control channel for badware. What > type of client is using this? > > Tony Hosseiny wrote: > > 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 <[email protected]> > > *To:* Load Balancing Mailing List <[email protected]> > > *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 comp > etitors 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 an > d 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 shel > l scripts in order to validate the availability and performance of t > he server application you were providing HA for. This was unparalle > led capability at the time (and still beyond some implementations)—b > ut naturally allowed customers (myself included at the time) to do s > ome really, really bad things to ourselves, our networks and our kit > . iRules are really no different. We have provided a fully extensib > le and flexible capability to change the very nature of application > delivery that can meet the unforeseen needs of tomorrow, not just to > day; that means a lot of ability to break things today. What was th > at 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 iCo > ntrol. Write your iRule and test it for yourself to see how it impa > cts YOUR application. If the impact is significant, submit it to De > vCentral and see if someone can provide you some ideas how to optimi > ze 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 c > onnection 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 <http://www.f5.com/>* > > > > > > > > *From:* [email protected] [mailto:[email protected]] *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 conn > ection before it can run for another. I would consider this very mu > lti-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 sh > owing 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 r > eal server are on the same subnet. This eliminates the common probl > em of a server hitting its own VIP and then that other server respon > ding 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 ad > ding this iRule to a virtual server, you are doing one IP address co > mparison 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:* [email protected] [mailto:[email protected]] *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 bala > ncing”, the execution delay (not the cpu/memory usage) due to script > s 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 ca > lling a script. Each hook means delay and resource usage and loading > the scripting engine to the memory. > > > > > > Regards, > > > > *Erhan DOLAK* > > > > > > *From:* [email protected] [mailto:[email protected]] *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:* [email protected] [mailto:[email protected]] *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 > > [email protected] > > 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 > > > > _______________________________________________ > lb-l mailing list > [email protected] > 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 > > _______________________________________________ > lb-l mailing list > [email protected] > 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 _______________________________________________ lb-l mailing list [email protected] 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