Forum Discussion
Massimo_64080
Nimbostratus
NimbostratusSimple Round Robin configuration
Hopefully this is the right bucket for this. What I am trying to do is fairly simple but apparently I am not having too much luck.
Scenario:
Subnet 192.168.100.0/24 (default gateway 192.168.100.150) with a couple of web server: 192.168.100.161 / 162
On the same subnet I have configured the "internal" leg of the BIG IP (VE) device: 192.168.100.151
Configuration:
I have configured a virtual IP (192.168.100.160) that points with the Round Robin algorithm to the two web srvs (161 / 162). I have used all the defaults and I have created the config multiple times both using the out-of-the-box "generic HTTP" template as well as creating the pool of srv and assigning that pool to a virtual IP that I have created manually.
Objective:
Being able to connect from an external machine (either on the same subnet or on another subnet) to the IP 192.168.100.160 and being balanced to 161 and 162 alternatively refreshing the browser.
I noted however that the when I browse 160 i land on one of the two servers and despite the refresh I continue to be addressed to the same host (i.e. no round robin). That made me think there was some level of stickiness in the default cfg. However when I shutdown the server I am balanced to the browser continue to show the (static) web page of the server I turned off. This makes me think there may be also some level of caching for static content (I am using a very basic html static page).
So my question is: is there anything that needs to be tweaked to configure the BIGIP so that it balances refreshing the browser on the same client (no stickiness) and even more importantly that redirects me to the other server when the one I am balanced to goes down (no caching)?
Thanks.
- JRahm
Admin
Welcome, Massimo. Sitting in the airport and just set this up on my laptop. Assuming you are sending one request at a time, this isn't abnormal, it'll send it to the "first" server every time. If you use a tool like apachebench, you'll see round robin kick in:
ab -n 50 http://172.16.101.85/
[blockquote]
[root@ephesus:Active] config b pool dpool
POOL dpool LB METHOD round robin MIN/CUR ACTIVE MEMBERS 0/2
| (cur, max, limit, tot) = (0, 3, 0, 51)
| (pkts,bits) in = (317, 266328), out = (286, 230368)
+-> POOL MEMBER dpool/172.16.101.99:rtcm-sc104 active,up
| | session enabled priority 0 ratio 1
| | (cur, max, limit, tot) = (0, 2, 0, 26)
| | (pkts,bits) in = (192, 195728), out = (161, 143168)
| | requests (total) = 58
+-> POOL MEMBER dpool/172.16.101.99:zephyr-srv active,up
| session enabled priority 0 ratio 1
| (cur, max, limit, tot) = (0, 1, 0, 25)
| (pkts,bits) in = (125, 70600), out = (125, 87200)
| requests (total) = 25
[/blockquote] - JRahmhere's my VE config for this setup:
[root@ephesus:Active] config b pool dpool list pool dpool { monitor all tcp members { 172.16.101.99:rtcm-sc104 {} 172.16.101.99:zephyr-srv {} } } [root@ephesus:Active] config b virtual dvip list virtual dvip { snat automap pool dpool destination 172.16.101.85:http ip protocol tcp profiles { http {} tcp {} } } 
Skuba_85554Being able to connect from an external machine (either on the same subnet or on another subnet) to the IP 192.168.100.160 and being balanced to 161 and 162 alternatively refreshing the browser.unfortunately this isn't a direct answer to your question, but i would say that having the client, the virtual server, and the web servers on the same subnet may cause you problems when testing. when the traffic hits the back end server it's not going to route back out through big ip as the client and the server are on the same subnet (i.e. communication will be over layer 2 rather than layer 3)
that's my understanding anyway! hope it helps a little
Massimo_64080Thanks Jason. I think I nailed down the caching problem. I am not 100% sure but it appears it was a mix of browser settings and "persistent" policy settings for the LB. They were both related to cookies issues. Now it appears that when a server is down (or taken offline from the pool) now the browser gets redirected to the "surviving" one.
I am still wondering about being able to refresh the browser and circle between the two web servers within that session (I can swear I have seen this happening in other demos) EVEN THOUGH the ap idea was excellent and it may give a much better real-life tasting of what happens when you have thousands of connections! You can then monitor the statistics of the node to show how the connections have been balanced! Thanks!
Massimo.- Massimo_64080Posted By Skuba on 06/10/2011 03:06 AM
Being able to connect from an external machine (either on the same subnet or on another subnet) to the IP 192.168.100.160 and being balanced to 161 and 162 alternatively refreshing the browser.unfortunately this isn't a direct answer to your question, but i would say that having the client, the virtual server, and the web servers on the same subnet may cause you problems when testing. when the traffic hits the back end server it's not going to route back out through big ip as the client and the server are on the same subnet (i.e. communication will be over layer 2 rather than layer 3)
that's my understanding anyway! hope it helps a little
Thanks Skuba. Yes I believe this is the default policy (although I understand BIGIP can be configured to be the middleman in the communication back to the client). What would be the problem you foresee in a L2 communication vs L3?Anyhow because of this I have started to test solely from a client that is behind the router on a different subnet. Right now I have created a static route on the client to reach the 192.168.100.160 virtual server although my ultimate goal will be to NAT the 160 address into an address on the client subnet. Expect a new discussion on that as I anticipate other problems :-D
Thanks!
Massimo.
nitassEmployee
>I am still wondering about being able to refresh the browser and circle between the two web servers within that session.
i think oneconnect may be applicable.
Content Switching
When a OneConnect profile is enabled for an HTTP virtual server, and an HTTP client sends multiple requests within a single connection, the BIG-IP system is able to process each HTTP request individually. The BIG-IP system sends the HTTP requests to different destination servers as determined by the load balancing method. Without a OneConnect profile enabled for the virtual server, the BIG-IP system performs load-balancing only once for each TCP connection.
sol7208: Overview of the OneConnect profile
http://support.f5.com/kb/en-us/solutions/public/7000/200/sol7208.html- Massimo_64080Nitass, that sounds exactly what I was looking for. While I am pretty happy now with the load generator Jason pointed me to I wan to give this a try to.
Hopefully without breaking everything else!
Thanks a lot.
Massimo.
