Limit to the number of Rules for a Local Traffic Policy

Technically no, but you'd be braver than most if you applied more than a small handful. As I'm sure you're aware, iRules are (byte code) compiled when added to a VIP. Multiple iRules are mashed into a single iRule, and any same events are also aggregated into a single event. This is why the order of the iRules in the GUI (11.x) and the priority command are so important. With multiple iRules you have to take into consideration a few potential pitfalls:

1. Race conditions - are you attempting to read a variable in one iRule before it's set in another?

    

2. Logic faults - are you trying to do a redirect in one iRule and insert an HTTP header in another at the same time?

    

If the iRules are discreet and do not interfere with the logic of other iRules, and/or you've been very careful not to allow collisions, you can add as many iRules as you need. But also, given that there's a finite set of possible events, it's not likely (or perhaps wise) to go beyond that.

I would also add that, aside from specific use cases where you want some discreet action to happen in multiple VIPs but don't want to have to copy and maintain that code in multiple iRules, there's a lot to be said for simplicity. Aggregating all of your logic into a single iRule is usually the more maintainable option.

Is there a best practice when routing from one VIP to multiple pools depending on their Path?

Good question, and it would depend I suppose on the specifics. It doesn't look like you're JUST routing based on path, but doing a lot of other things as well.

When your client connects the routing decision on the pool member is made at the start of the connection. Subsequent requests sent down that TCP connection will always go to the same pool member thereafter, regardless of what is written in your iRule. It only uses the pool selection at the start.

When you type that into the browser box and hit enter it is sending the request down the same connection. So it goes to the pool member that has already been selected for this connection. If you waited five minutes it would route correctly as it would be a new connection.

To change this behaviour you need to use a oneconnect profile on your virtual server. This means the pool selection can be evaluated on every single http request.

Thank you Kevin, I have been using the default oneconnect profile that is created by the iApp template. Are there specific settings that need to be modified? It doesn't appear to be working as you describe.

Hi Kevin, Thank you for your reply to how-do-i-make-an-irule-read-each-connectionanswer97423

I am testing this but I think it is going to do the trick.

when CLIENT_ACCEPTED { set cid [clock clicks] }

Thanks to you, I found the documentation I had been searching for.

Writing iRules "iRules are therefore evaluated whenever an event occurs that you have specified in the iRule. For example, if an iRule includes the event declaration CLIENT_ACCEPTED, then the iRule is triggered whenever the BIG-IP system accepts a client connection. The BIG-IP system then follows the directions in the remainder of the iRule to determine the destination of the packet."

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)

In response to the Cory's oneconnect issue:

Cory I strongly suggest you add logging to each branch of your iRule. So you are sure about each branch that is being triggered. It has surprised me on many an occasion that what I thought was happening was quite different from reality and it doest matter how long I have been programming iRules (5 years now). Experience has taught me to use logging extensively when testing. Its pretty simple... just add this where you need it. Then keep an eye on /var/log/ltm.

log local0. "in branch blah"

If the current iRule behaviour is not what you are expecting then use logging to verify the behaviour. If then it is still not what you expect then open a new question here on devcentral with your iRule, its logging results and we can likely help you to find the problem.

Thank you Kevin, I had setup logging during my tests. That is what brought me to the conclusion that the iRule wasn't being executed after the initial request. I'll take a look at this article.

Hi Kevin, I want to mark this question as answered and refer further answers to how-do-i-make-an-irule-read-each-connectionanswer97423

I have found there is a limit to the number of rules allowed in a traffic policy.