Forum Discussion

Ben_Wilson_2412's avatar
Ben_Wilson_2412
Icon for Cirrus rankCirrus
Nov 06, 2013

Bunch of similar iRules

We have a bunch of similar iRules that only differ in a few properties. Rather than create separate rules for each VIP, I'd rather server of couple "VIP environment variables" that can be referenced by the same rules.

 

What would be a reasonable approach?

 

  1. Use data classes for each variable and look them up based on the VIP name (bleh)
  2. Have the first rule set the variables referenced by subsequent rules
  3. Have 1 rule that sets the environment and "calls" the rest of the rules

I'm pretty sure 1 can be done, I'd prefer 2 and 3 could work.

 

Any suggestions or caveats?

 

Thanks! Ben

 

application delivery
devops
iRules

3 Replies

Sort By
  • What_Lies_Bene1's avatar
    What_Lies_Bene1
    Icon for Cirrostratus rankCirrostratus
    Nov 06, 2013

    Personally I rather like 1, it's simple and efficient and the rules don't need to be touched when things change. If you want 2 or 2, how would you set the variables? Note that 3 would only be possible using stored procedures and v11.4.

     

  • RobertColbert's avatar
    RobertColbert
    Icon for Nimbostratus rankNimbostratus
    Nov 06, 2013

    We have been running w/ 1 for pool selection & redirect rules for several years and it works well as long as you cover all use-cases. Since you are talking about rules that only change in a couple variables, you could have a single string list that uses VIP name as the key & your other variables are space delimited.

     

    For 2, it could be done in v9 using global variables but I'm not sure how partitioning or future changes to the LTM OS will make global variables harder to guarantee.

     

  • Kevin_Stewart's avatar
    Kevin_Stewart
    Icon for Employee rankEmployee
    Nov 06, 2013

    Honestly, global variables are rarely ever a best practice. Especially if you're setting global variables that will be used by other iRules and on other VIPS. Too much can go wrong and/or get unnecessarily uncomplicated. As much as you may not like it, a centrally-managed and stable data group might be one of your best options.