Forum Discussion
Limit to the number of Rules for a Local Traffic Policy
Cory I found an excellent link here on devcentral about events and when they are triggered in the TCP flow. See link text
The BIGIP processes many thousand of TCP streams in parallel through the TMM. Effectively each client TCP stream has its own personal iRule space. Each TCP connection has its own instance with its own set of variables which co-exist for the life of that connection. Any events triggered by the TCP connection share that variable scope. So you can set variables in one event early on in the piece and use them later.
Commands are event based. So HTTP::commands can be used in HTTP_REQUEST events but cannot be used in CLIENT_ACCEPTED events. The reason is pretty simple. At the time of CLIENT_ACCEPTED we haven't touched layer 7 traffic yet, we are only on layer 4. So TCP::commands, IP::commands will work fine. When we reach HTTP_REQUEST event, the BIGIP has parsed the header of a single HTTP request and has all the information needed for the HTTP::commands.
Don't get into thinking there is a one to one relationship here either. CLIENT_ACCEPTED will be fired for each client connection, yet there may be multiple HTTP_REQUEST events triggered during the life of that connection. The default standard for HTTP version 1.1 (world standard at present time) is for browsers to keep connections alive on the client side and reuse them.
I hope some of that helps. Read the event order, and imagine that happens for every single TCP connection. It is enlightening.
(Note there are some exceptions to variable scope with the RULE_INIT event)
Help guide the future of your DevCentral Community!
What tools do you use to collaborate? (1min - anonymous)Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com