Forum Discussion

jsmith7735_1319's avatar
jsmith7735_1319
Icon for Nimbostratus rankNimbostratus
Jan 21, 2014

What 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

  • 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.

     

  • John_Alam_45640's avatar
    John_Alam_45640
    Historic F5 Account

    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.

     

  • James_Deucker_2's avatar
    James_Deucker_2
    Historic F5 Account

    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_3
    

    likely 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 incremented
    

    You'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.