Re: lb-l Digest, Vol 32, Issue 14

Folks-

I thought that I would let you know that if you have a Coyote Point Systems
"si" or "GX" Equalizers lying around, it to can "insert client IP" address
into an HTTP 'X-Forwarded-For' header. All that needs to be done is to check
a box in the GUI for the HTTP or HTTPS cluster that you define. The
Equalizer can also add a custom HTTP header/value to an HTTP or HTTPS packet
as well. No fuss, no scripts, and easy to use. This does require the 8.5.0
version of the software though. 

Then there is always "spoofing" where the Equalizer passes the client IP
address as the source IP in the packet to the server.


James Scriba
Systems Sales Engineer
1-408-291-2237

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
[email protected]
Sent: Friday, September 11, 2009 1:00 AM
To: [email protected]
Subject: lb-l Digest, Vol 32, Issue 14

Send lb-l mailing list submissions to
	[email protected]

To subscribe or unsubscribe via the World Wide Web, visit
	http://vegan.net/mailman/listinfo/lb-l
or, via email, send a message with subject or body 'help' to
	[email protected]

You can reach the person managing the list at
	[email protected]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of lb-l digest..."


Today's Topics:

   1. Re: extracting TCP option info (Erhan Dolak)


----------------------------------------------------------------------

Message: 1
Date: Fri, 11 Sep 2009 10:59:29 +0300
From: "Erhan Dolak" <[email protected]>
Subject: Re: [load balancing] extracting TCP option info
To: "'Load Balancing Mailing List'" <[email protected]>
Message-ID: <00bb01ca32b5$cade0de0$609a29a0$@com>
Content-Type: text/plain; charset="utf-8"

Yes but not enough.

 

they will use some ISAPI filter  (or in IIS7 you dont need to use third
party plugin to extract that information,let me give the link so that in the
future it may help someone :
http://learn.iis.net/page.aspx/579/advanced-logging-for-iis-70---custom-logg
ing/ ) 

 

But, first they need to transfer the value from TCP option to the HTTP
header so that that web server can get the Client_IP from the header. Good
to know that Netscaler can do it, it means that its possible in terms of
performance and technology.

 


Erhan DOLAK



 

From: [email protected] [mailto:[email protected]] On Behalf Of
Greg Howett
Sent: Friday, September 11, 2009 2:31 AM
To: Load Balancing Mailing List
Cc: Load Balancing Mailing List
Subject: Re: [load balancing] extracting TCP option info

 

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 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 <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 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:* [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 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:* [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

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://vegan.net/pipermail/lb-l/attachments/20090911/f9956287/attachment.ht
ml>

------------------------------

_______________________________________________
lb-l mailing list
[email protected]
http://vegan.net/mailman/listinfo/lb-l


End of lb-l Digest, Vol 32, Issue 14
************************************

_______________________________________________
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