Forum Discussion

Todd_02_140890's avatar
Todd_02_140890
Icon for Nimbostratus rankNimbostratus
Jul 19, 2017

Adding new Rule breaks my LTM Policy.

Adding a new rule to my LTM Forwarding Policy, breaks the Policy.

 

We are running 11.5.x (I know its old) but when I add a new rule to my forwarding policy, it breaks the policy and routes all traffic to the default pool associated with the VIP. The only way I know to fix this is by dissociating the LTM Policy with the VIP, then re-associating the policy, and hitting the URL again in my browser. Once I do this, everything works fine, but I can't keep doing this because it takes everything offline while I do the workaround.

 

Has anyone seen this issue and or know if its fixed in a later release of the TMOS? I've downloaded 13.x, but need the networking team to re-validate the license file in order to activate 13.x.

 

Thanks in advance.

 

4 Replies

  • Can you please post more details? I'm no genius at policies myself, but I do believe it would help us help you.

     

    /Patrik

     

  • Sure,

     

    So I have a "forwarding" policy setup on my VIP to forward requests to pools. Each service I have for the policy, has its own rule on where to go when the URI pattern matches. When I add a new rule for a new service, I try to hit it externally, and it always sends it back to the "default pool" for my VIP. When I dissociate the ltm policy from the VIP, then re-associate it, it works fine. Unfortunately this is a no go since doing this "fix" breaks everyone temporarily when moving the LTM Policy back and forth.

     

    The only thing I havent tried is reordering the rules before trying to hit the service to see if that fixes the issue.

     

  • If policies works the same way as iRules they would not be updated for existing sessions. When you disassociate the rule from the virtual server it might break the existing sessions and force clients to create new ones.

    You could test this theory by updating the policy and try to test the rule in private mode on your browser, or try a different browser altogether.

    If the theory is confirmed you can kill the connections manually instead of removing/re-adding the policy by running:

    tmsh del sys connection cs-server-addr  cs-server-port 

    This is much faster than what you do today.

    /Patrik

  • I wonder if this might be related to a bug affecting 11.5.0:

     

    K15961: Local traffic policy actions may not load correctly during a configuration load https://support.f5.com/csp/article/K15961

     

    Applies to: 11.5.1, 11.5.0 Fixed in:

     

    11.5.0 HF1 11.5.1 HF5 11.6.0 and higher