Big-IP LTM VE load balance configuration
Hi Everyone, I've setup a LTM VE on my VMware Workstation. I got 2 Windows webservers and 2 Windows VM Clients. Below is my setup on LTM VE GUI: Network: Interface 1.1 (untagged)-> Internal: 10.1.3.20/24. Floating IP is 10.1.3.30. Interface 1.2 (untagged)-> External: 10.100.1.20/24. Floating IP is 10.100.1.30. Local Traffic: Nodes: Wins2016-01: 10.1.3.40. Wins2016-02: 10.1.3.41. Pool: F5_Webservers (Green). Round Robin. Members: Wins2016-01 and Wins2016-02. Virtual Servers: Windows2016 (Green). Source address: 0.0.0.0/0 Destination address/mask: 10.100.1.50 Service port 80 Default Pool: F5_Webservers From the Client PC (10.100.1.41) can ping both Webservers 'Wins2016-01' and 'Wins2016-02', I'm also able to ping 10.100.1.50 but can't browse the 10.100.1.50 from IE explorer. Any ideas what I missed here? I really appreciate it! Thanks.
Difficulties getting Websense working with LTM
I am running LTM 11.4.1 HF1 on a 4200v active/standby cluster. I am working to deploy HF5 once management OKs it. Using an evaluation Virtual Edition (VE) unit, I was able to get Websense integrated with LTM OK, using routed config (no SNAT) and transparent proxy using the Websense iApp. The problem is that when I duplicate this config on my production unit, it doesn't work. There is some routing or other problem. I can see traffic from the test client hitting the LTM, but I see no activity on the LTM websense virtual server or pool. A capture of traffic on the LTM VE, of the testing client (the one browsing the web), shows this: 22:55:06.856386 IP (tos 0x0, ttl 91, id 7389, offset 0, flags [DF], proto: TCP (6), length: 52) 10.249.2.106.57043 > 209.53.113.5.http: S, cksum 0xd9d8 (correct), 4072297509:4072297509(0) win 8192 22:55:06.856449 IP (tos 0x0, ttl 90, id 7389, offset 0, flags [DF], proto: TCP (6), length: 52) 10.249.2.106.57043 > 209.53.113.5.http: S, cksum 0xd9d8 (correct), 4072297509:4072297509(0) win 8192 22:55:06.856452 IP (tos 0x0, ttl 89, id 7389, offset 0, flags [DF], proto: TCP (6), length: 52) 10.249.2.106.57043 > 209.53.113.5.http: S, cksum 0xd9d8 (correct), 4072297509:4072297509(0) win 8192 22:55:06.856517 IP (tos 0x0, ttl 88, id 7389, offset 0, flags [DF], proto: TCP (6), length: 52) 10.249.2.106.57043 > 209.53.113.5.http: S, cksum 0xd9d8 (correct), 4072297509:4072297509(0) win 8192 22:55:06.856521 IP (tos 0x0, ttl 87, id 7389, offset 0, flags [DF], proto: TCP (6), length: 52) 10.249.2.106.57043 > 209.53.113.5.http: S, cksum 0xd9d8 (correct), 4072297509:4072297509(0) win 8192 22:55:06.856584 IP (tos 0x0, ttl 86, id 7389, offset 0, flags [DF], proto: TCP (6), length: 52) 10.249.2.106.57043 > 209.53.113.5.http: S, cksum 0xd9d8 (correct), 4072297509:4072297509(0) win 8192 22:55:06.856588 IP (tos 0x0, ttl 85, id 7389, offset 0, flags [DF], proto: TCP (6), length: 52) 10.249.2.106.57043 > 209.53.113.5.http: S, cksum 0xd9d8 (correct), 4072297509:4072297509(0) win 8192 We have a fairly complex production config, but the VE test I ran used bare-bones minimal config so I could establish a known-good config to make LTM-Websense work. Without providing the full config from both the production and VE units, is there any known config or setting that would cause traffic to enter the LTM, but not be picked up by the virtual server. This seems especially relevant because the virtual server listens on all any addresses (0.0.0.0), and all VLANs. I don't expect to easily fix this problem, but I'm at least looking for clues about where to start. I am also working with my local SE on the issue, but thought I'd ask here too.
Predicting the next session from Dynamic ratio weights
I've not had any success finding information on how the sessions are allocated when using a dynamic ratio method. If I have a simple network of 2 nodes with different weights (as calculated from a SNMP DCA monitor) is the allocation of the next incoming session predictable with dynamic ratio balancing? (In testing it appears random whether my next session is assigned to the higher or lower weighted node) Any information would be appreciated.
