Last Modified: Apr 23, 2024
Affected Product(s):
BIG-IP TMOS
Known Affected Versions:
13.1.1, 13.1.1.2, 13.1.1.3, 13.1.1.4, 13.1.1.5, 13.1.3, 13.1.3.1, 13.1.3.2, 13.1.3.3, 13.1.3.4, 13.1.3.5, 13.1.3.6, 13.1.4, 13.1.4.1, 13.1.5, 13.1.5.1
Opened: Jun 01, 2020 Severity: 4-Minor
Ratio member is a connection-based load balancing algorithm. The statistics this load balancing algorithm uses will be updated when a connection is connected/disconnected. When SIP/MBLB calls flow containing BYE and the 'Terminate on BYE' option is enabled, a new connection will be created with every SIP call. That is why the ratio member seems to work in such cases. If 'Terminate on BYE' is disabled, or it is enabled but the call is not closed with a BYE, then all pool member traffic will be directed to the same server because the SIP traffic is multiplexed over the same connection.
All of the SIP traffic is directed to a single server, or the actual ratio is not maintained correctly depending on the actual calls/configuration
-- Pool configured with the load balancing method set to Ratio-Member. -- Pool is assigned to a virtual server configured with SIP and MBLB. -- Multiple SIP calls are multiplexed over same connection. -- SIP Profile option 'Terminate on BYE' is disabled or 'Terminate on Bye' is enabled but the call is not closed with BYE
FIRST WORKAROUND: Create duplicate pool members using the same server. For example if you have two servers, server A and B, and you want a ratio of 2:3, configure multiple pool members to achieve the desired ratio: A:5060 A:5061 B:5060 B:5061 B:5062 Impact of workaround: You must also disable port translation for the virtual server, and you must configure round robin load balancing. Also, the ratio is not preserved if one of the pool members goes down. SECOND WORKAROUND: If you are unable to use multiple ports on the same server, you could also use multiple IP addresses. The following pool configuration also achieves a 2:3 ratio between server A and server B: ? A1:5060 A2:5060 B1:5060 B2:5060 B3:5060 Impact of workaround: you must also configure round robin load balancing. Also, the ratio is not preserved if one of the pool members goes down. THIRD WORKAROUND: Implement a ratio algorithm in an iRule. After checking to see if the message is of type INVITE, select a pool member based on a computed algorithm in the iRule. For example you can declare an array of pool member ip:port, then loop through them. A pool member can be selected via: pool <pool name> member <ip> <port> Impact of workaround: The iRule should also check the pool member status to ensure it is up. LB::status can be used to check status of pool member
None