Forum Discussion

AndyC_86542's avatar
AndyC_86542
Icon for Nimbostratus rankNimbostratus
Jan 26, 2009

Strange persist behaviour

I have this little section of code in an iRule that decides which of various pools to send an HTTP request to. I wanted to make sure that requests from a single client go through the same proxy server within squid-proxy-pool.

 

 

set sourceIPAddress [IP::client_addr]

 

pool squid-proxy-pool

 

persist source_addr 7200

 

set pResult [persist lookup source_addr $sourceIPAddress]

 

log local0.debug "ip: $sourceIPAddress - persist result: $pResult"

 

 

I thought that this would do what I wanted and just added the last two lines to debug a separate problem. However, when I look at the logs, I get results like the following (dates removed from timestamps for readability):

 

 

16:30:12 ip: 192.168.20.221 - persist result: squid-proxy-pool 172.22.21.250 80

 

16:30:14 ip: 192.168.20.221 - persist result: squid-proxy-pool 172.22.21.249 80

 

16:30:16 ip: 192.168.20.221 - persist result: squid-proxy-pool 172.22.21.249 80

 

16:30:17 ip: 192.168.20.221 - persist result: squid-proxy-pool 172.22.21.249 80

 

16:30:17 ip: 192.168.20.221 - persist result: squid-proxy-pool 172.22.21.250 80

 

 

Am I completely missing the point with persist or is this really spattering requests all over the pool without regard to the source_addr setting?

 

application delivery
dev
devops
iRules

14 Replies

Sort By
Show More
  • spark_86682's avatar
    spark_86682
    Historic F5 Account
    Feb 11, 2009
    Persistence should just work in conjunction with CMP. There is no command to alter this behavior.

     

     

    Two things jump out at me here. First, you said that you disabled CMP on this virtual but still saw log entries from both tmms. That says to me that that virtual was still running in CMP mode. You might want to try re-enabling CMP globally and re-disabling it on that virtual, and then run "bigstart restart" or perform a reboot and see if the problem recurs. Second, if all you're looking for is vanilla source IP persistence, then I'm not sure why you're using an iRule at all. It might work better if you just configure a persistence profile.

     

     

    All that said, if you're still having a problem with persistence, and disabling CMP fixes the problem, then I would definitely open a case with F5 support.
  • AndyC_86542's avatar
    AndyC_86542
    Icon for Nimbostratus rankNimbostratus
    Feb 17, 2009
    Got this to work finally.

     

     

    F5 support thinks it's down to a known fault where the CMP doesn't get properly updated when you edit the iRule through the GUI (not sure if that means the iRule editor or the config. interaface but I use both).

     

     

    Obviously, the CMP status as displayed in the console didn't match what the F5 was actually doing. By doing a "bigpipe save" in console and a reboot from the front panel, everything seems to right itself (after setting the tmm count back to zero of course).

     

     

    There is apparently a hotfix for 9.4.6 which solves this problem.

     

     

    Cheers All.
  • Jos_52767's avatar
    Jos_52767
    Historic F5 Account
    Feb 17, 2009
    Hi all,

     

     

    I want to clarify two important points in this thread:

     

    - An iRule will always take precedence over persistence set in a profile as it is executed after the profile has been parsed. It is for this reason that if an iRule makes an LB decision persistence should also be handled by the iRule.

     

    - The use of an iRule and / or Persistence is not compatible with CMP, and as such, using any of these should automatically disable CMP for the virtual. For more details review solution SOL7751: https://support.f5.com/kb/en-us/solutions/public/7000/700/sol7751.html

     

     

    SOL7751 also indicates that CMP can be disabled via the command line:

     

    bigpipe virtual cmp

     

     

    This is the workaround for the issue that sorbukar mentions - it ensures that CMP is disabled for the virtual, which will prevent multiple persistence entries between the TMMs. The "b save" command will ensure that the change in CMP status survives a reboot.

     

  • lorvain_176032's avatar
    lorvain_176032
    Icon for Nimbostratus rankNimbostratus
    Jan 21, 2016

    Hi all,

     

    I'am encountering a similar behaviour with a bigIP 1600 11.4.1 HF9.

     

    I have a VIP with CMP disabled but I can see that persistence is performed on multiple tmm:

     

    show ltm persistence persist-records

     

    Sys::Persistent Connections

     

    source-address 90.85.96.216 161.xx.xx.xx:1719 192.168.164.110:any (tmm: 0)

     

    source-address 161.xx.xx.xx 161.xx.xx.xx:1719 192.168.164.113:any (tmm: 0)

     

    source-address 161.xx.xx.xx 161.xx.xx.xx:1719 192.168.164.113:any (tmm: 0)

     

    source-address 90.63.244.203 161.xx.xx.xx:1719 192.168.164.110:any (tmm: 1)

     

    source-address 90.63.244.203 161.xx.xx.xx:1719 192.168.164.110:any (tmm: 0)

     

    source-address 161.105.150.2 161.xx.xx.xx:1719 192.168.164.113:any (tmm: 0)

     

    I not understand why multiple tmm as I disabled them on the VIP. No Irule applied on the VIP just a persistence profile.

     

    Thanks for feedbacks