Forum Discussion

rachitbiyani_21's avatar
rachitbiyani_21
Icon for Nimbostratus rankNimbostratus
Aug 13, 2015
Solved

Equivalent iRules have different behavior

Hello,

 

I have configured the following iRule on a Virtual Edition BigIP F5:

 

when CLIENT_ACCEPTED {snat [clientside {IP::local_addr}]}

 

and it works as expected - It translates the source IP address of an incoming packet to the IP address of the virtual server.

 

However, if I configure the following equivalent iRule:

 

when CLIENT_ACCEPTED {set VirtualIP[clientside {IP::local_addr}] {snat $VirtualIP}}

 

I don't see the source address translation any more. The only difference between these two rules is that the second one is using a variable and has a level of indirection.

 

Any ideas on why this could be occurring? I am using TMSH to enter the configuration. I am escaping the '$' character with a backslash, so that the iRule is fed in properly to the system.

 

I would appreciate any insights on this.

 

Thanks, Rachit

 

APM
application delivery
deployment
design
devops
iRules
LTM
security
  • Vernon_97235's avatar
    Vernon_97235
    Aug 13, 2015

    It loads correctly for me (when using 

    tmsh edit ltm rule foo
    and pasting into 
    vi
    under 11.6.0). I suspect this may be a character insertion issue. If, for example, you paste in Windows-style newlines at the end (which will naturally be invisible to you), the iRule parser will not interpret the newlines in the way you expect. Indeed, based on the error, it appears to be compressing the two statements together. Incidentally, the space after the variable name is required.

7 Replies

Sort By
  • Joe_Pruitt's avatar
    Joe_Pruitt
    Aug 13, 2015

    Enclosing the snat command in curly braces causes it to not execute and be treated as a literal. Try this

     

    when CLIENT_ACCEPTED {
  set VirtualIP [clientside {IP::local_addr}]
  snat $VirtualIP
}

    What is the need for storing the value sent to the snat command inside a variable? That takes up memory space and if you aren't using it in other areas of the iRule (logging, etc), then you are better off just going with your original code

     

    when CLIENT_ACCEPTED {
  snat [clientside {IP::local_addr}]
}

    -Joe

     

  • Vernon_97235's avatar
    Vernon_97235
    Historic F5 Account
    Aug 13, 2015

    It loads correctly for me (when using 

    tmsh edit ltm rule foo
    and pasting into 
    vi
    under 11.6.0). I suspect this may be a character insertion issue. If, for example, you paste in Windows-style newlines at the end (which will naturally be invisible to you), the iRule parser will not interpret the newlines in the way you expect. Indeed, based on the error, it appears to be compressing the two statements together. Incidentally, the space after the variable name is required.

    • rachitbiyani_21's avatar
      rachitbiyani_21
      Icon for Nimbostratus rankNimbostratus
      Aug 13, 2015
      Hello Vernon, Thank you so much for your suggestion. After editing the rule in vim, it worked exactly as expected. And it did require the space between the variable name and square bracket. (as you had mentioned) Thanks again for pointing out the editor issue - wouldn't have occurred to me otherwise. - Rachit
  • VernonWells's avatar
    VernonWells
    Icon for Employee rankEmployee
    Aug 13, 2015

    It loads correctly for me (when using 

    tmsh edit ltm rule foo
    and pasting into 
    vi
    under 11.6.0). I suspect this may be a character insertion issue. If, for example, you paste in Windows-style newlines at the end (which will naturally be invisible to you), the iRule parser will not interpret the newlines in the way you expect. Indeed, based on the error, it appears to be compressing the two statements together. Incidentally, the space after the variable name is required.

    • rachitbiyani_21's avatar
      rachitbiyani_21
      Icon for Nimbostratus rankNimbostratus
      Aug 13, 2015
      Hello Vernon, Thank you so much for your suggestion. After editing the rule in vim, it worked exactly as expected. And it did require the space between the variable name and square bracket. (as you had mentioned) Thanks again for pointing out the editor issue - wouldn't have occurred to me otherwise. - Rachit