Forum Discussion
NimbostratusStrange persist behaviour
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?
14 Replies
- 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_86542Got 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.- 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_176032Hi 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
