Forum Discussion

SanjayP's avatar
SanjayP
Icon for Nacreous rankNacreous
Oct 30, 2014

priority group not working

having priority group issue, where low priority group members are also receiving traffic though high priority group members are available. Please advise. Below is the VIP config

 

ltm virtual XXXXXX { destination 10.14.128.202:xprint-server fallback-persistence Beltdwc_srcaddr http-class { ULPRD_XXXX_HC ULPRD_XXXX_Crys_Rep_Doc_HC } ip-protocol tcp mask 255.255.255.255 persist { GroupXXXX_Cookie { default yes } } pool ULPRD_XXXXX_Rep_crys_doc_Pool profiles { http { } oneconnect { } stream { } tcp { } } rules { ULPRRewrite } snat automap vlans-disabled }

 

5 Replies

  • OK. Can you post the Pool configuration please, as that's where this feature is configured. Also, do you have any connection limits configured?

     

  • There is no limit for connections. This VS has 2 pools. based on incoming URI it redirect to the pool. Below is the config for pool. priority group not working for both pool

    Pool1

    ltm pool ULPRD_Invoker_Pool {
    load-balancing-mode least-connections-member
    members {
        10.20.153.164:trivnet2 {
            address 10.20.153.164
            priority-group 3
            session monitor-enabled
            state up
        }
        10.20.153.164:8202 {
            address 10.20.153.164
            priority-group 3
            session monitor-enabled
            state up
        }
        10.20.153.164:8203 {
            address 10.20.153.164
            priority-group 3
            session user-disabled
            state up
        }
        10.20.153.164:lm-perfworks {
            address 10.20.153.164
            priority-group 3
            session monitor-enabled
            state down
        }
        10.20.89.167:trivnet2 {
            address 10.20.89.167
            priority-group 1
            session user-disabled
            state user-down
        }
        10.20.89.167:8202 {
            address 10.20.89.167
            priority-group 1
            session user-disabled
            state up
        }
        10.20.89.167:8203 {
            address 10.20.89.167
            priority-group 1
            session user-disabled
            state up
        }
        10.20.89.167:lm-perfworks {
            address 10.20.89.167
            priority-group 1
            session monitor-enabled
            state down
        }
    }
    min-active-members 2
    monitor tcp
    

    }

    Pool2

    ltm pool ULPRD_XXXX_Rep_crys_doc_Pool {
    members {
        10.20.153.164:xprint-server {
            address 10.20.153.164
            priority-group 5
            session monitor-enabled
            state up
        }
        10.20.89.167:xprint-server {
            address 10.20.89.167
            priority-group 3
            session user-disabled
            state user-down
        }
    }
    min-active-members 1
    monitor tcp
    

    }

  • If the lower priority group was previously activated, traffic would continue to flow due to persistence even when higher priority group members become available.

     

  • nathe's avatar
    nathe
    Icon for Cirrocumulus rankCirrocumulus

    spalan,

     

    Two things to add with Priority Group. I believe existing open TCP connections will be maintained on the lower priority pool member, even if the higher priority ones are back in play. Also, persistence will override this selection to so you need to ensure there is no Cookie on a client and/or source addr persistence entry.

     

    Hope this helps a bit,

     

    N

     

  • Thanks Nathan for the response. But lower priority pool was never active. Even I tried removing persistence profile and also deleted the connection entry. But still issue persists. I had to made members forced offline to direct traffic to high priority memeber