Forum Discussion
NimbostratusWhat is this Irule doing?
I have a VIP that is using this irule and one issue that the application owners are complaining about is that the server listening on port 88 is hitting max connections. Unfortunately I don't work on F5's daily so I'm not sure how to resolve this but I think we may have to rewrite the irule. Any help would be greatly appreciated.
when RULE_INIT {
set ::c 0
}
when HTTP_REQUEST { event enable
switch $::c {
0 {
HTTP::redirect "http://server1.test.com:88/test.html"
incr ::c event disable
}
1 {
HTTP::redirect "http://server2.test.com:87/test.html"
incr ::c event disable
}
2 {
HTTP::redirect "http://server3.test.com:86/test.html"
set ::c 0 event disable
}
}
}
3 Replies
Cory_50405Noctilucent
Unless I'm missing something, the iRule will direct all traffic to the port 88 server. Neither of the other two servers will be assigned traffic from this iRule.
The "incr ::c" command ensures that subsequent HTTP requests will go to port 87 and then 86, either within same connection or across multiple connections. Then after it hits port 86 the ::c variable is reset to 0 and it all starts again.
In other words, this irule sends HTTP requests in a round robin fashion between ports 88, 87, and 86.
One problem is that this irule disables CMP on the virtual because it uses a non-static global variable.
It's attempting to round-robin TCP connections to different VIPs on different ports.
Assume the VIPs are (VS_one/VS_two/VS_three could in fact be direct servers instead of VIPs)
VS_front:80 -> this_irule VS_one:88 -> pool_for_server_1 VS_two:87 -> pool_for_server_2 VS_three:86 -> pool_for_server_3likely intention:
user_A hits VS_front and gets redirected to VS_one. counter "::c" gets incremented user_B hits VS_front and gets redirected to VS_two. counter "::c" gets incremented user_C hits VS_front and gets redirected to VS_three. counter "::c" set to 0 user_D hits VS_front and gets redirected to VS_one. counter "::c" gets incrementedYou're best off moving to a single VS loadbalancing the backend of three servers in a single pool with persistence on (probably cookie), and least connections load balancing method.
In modern BIG-IP v11.4 you can set a connection limit and queueing on the VS, connection limits on the pool members, and all sorts of other sugar to manage this cleanly. AVR would give you visibility into how well things are getting balanced.
