SLBD config problem
-
Running 1.2-BETA-1-TESTING-SNAPSHOT-06-06-2007 ON WRAP
I've configured a inbound load balanced pool with 2 servers that I know are good and have configured the Load Balancer Virtual Server IP which is the same IP as the CARP VIP.
I'm concerned about the followings logs that seem to show that all machines are falling out of the pool and its switching to sitedown. It also doesn't seem to keep SSL connections in state.
I've made sure I've got "Sticky Connections" switched ON too.
07-16-2007 20:02:35 Kernel.Critical 192.168.1.51 Jul 16 19:58:26 kernel: tcp_signature_compute: SADB lookup failed for 192.168.1.26 07-16-2007 20:02:32 User.Notice 192.168.1.51 Jul 16 19:58:23 check_reload_status: reloading filter 07-16-2007 20:02:30 Auth.Info 192.168.1.51 Jul 16 19:58:05 last message repeated 14 times 07-16-2007 20:02:21 Local1.Error 192.168.1.51 Jul 16 19:58:13 slbd[89850]: Service EXFEC_25 changed status, reloading filter policy 07-16-2007 20:02:21 Local1.Error 192.168.1.51 Jul 16 19:58:13 slbd[89850]: TCP poll succeeded for 192.168.1.21:25, marking service UP 07-16-2007 20:02:16 Local1.Error 192.168.1.51 Jul 16 19:58:08 slbd[89850]: Service EXFEC_25 changed status, reloading filter policy 07-16-2007 20:02:16 Local1.Error 192.168.1.51 Jul 16 19:58:08 slbd[89850]: TCP poll failed for 192.168.1.21:25, marking service DOWN 07-16-2007 20:02:16 Local1.Error 192.168.1.51 Jul 16 19:58:08 slbd[89850]: TCP poll failed to start to 192.168.1.21:25 in default (Operation now in progress) 07-16-2007 20:02:08 User.Notice 192.168.1.51 Jul 16 19:58:00 check_reload_status: reloading filter 07-16-2007 20:02:01 Local1.Error 192.168.1.51 Jul 16 19:57:53 slbd[89850]: Service EXFEC_25 changed status, reloading filter policy 07-16-2007 20:02:01 Local1.Error 192.168.1.51 Jul 16 19:57:53 slbd[89850]: TCP poll succeeded for 192.168.1.20:25, marking service UP 07-16-2007 20:02:01 Local1.Error 192.168.1.51 Jul 16 19:57:53 slbd[89850]: Service EXFEC_110 changed status, reloading filter policy 07-16-2007 20:02:01 Local1.Error 192.168.1.51 Jul 16 19:57:53 slbd[89850]: TCP poll succeeded for 192.168.1.21:110, marking service UP 07-16-2007 20:02:01 Local1.Error 192.168.1.51 Jul 16 19:57:53 slbd[89850]: TCP poll succeeded for 192.168.1.20:110, marking service UP 07-16-2007 20:02:00 Local1.Error 192.168.1.51 Jul 16 19:57:52 slbd[89850]: Switching to sitedown for VIP 213.129.91.196:110 07-16-2007 20:01:56 Local1.Error 192.168.1.51 Jul 16 19:57:48 slbd[89850]: Service EXFEC_25 changed status, reloading filter policy 07-16-2007 20:01:56 Local1.Error 192.168.1.51 Jul 16 19:57:48 slbd[89850]: TCP poll failed for 192.168.1.20:25, marking service DOWN 07-16-2007 20:01:56 Local1.Error 192.168.1.51 Jul 16 19:57:48 slbd[89850]: TCP poll failed to start to 192.168.1.20:25 in default (Operation now in progress) 07-16-2007 20:01:56 Local1.Error 192.168.1.51 Jul 16 19:57:48 slbd[89850]: Service EXFEC_110 changed status, reloading filter policy 07-16-2007 20:01:56 Local1.Error 192.168.1.51 Jul 16 19:57:48 slbd[89850]: TCP poll failed for 192.168.1.21:110, marking service DOWN 07-16-2007 20:01:56 Local1.Error 192.168.1.51 Jul 16 19:57:48 slbd[89850]: TCP poll failed to start to 192.168.1.21:110 in default (Operation now in progress) 07-16-2007 20:01:56 Local1.Error 192.168.1.51 Jul 16 19:57:48 slbd[89850]: TCP poll failed for 192.168.1.20:110, marking service DOWN 07-16-2007 20:01:56 Local1.Error 192.168.1.51 Jul 16 19:57:48 slbd[89850]: TCP poll failed to start to 192.168.1.20:110 in default (Operation now in progress) 07-16-2007 20:01:48 Kernel.Critical 192.168.1.51 Jul 16 19:57:39 kernel: tcp_signature_compute: SADB lookup failed for 192.168.1.26 07-16-2007 20:01:46 User.Notice 192.168.1.51 Jul 16 19:57:38 check_reload_status: reloading filter
-
Is anyone else using inbound load balancing with multinode pfsense?
Sticky Connections don't seem to be working here.
A reboot seems to have fixed this.
-
I can't get sticky connections to work with 1.2-RC3 . I have 2 pfsense boxes in failover configuration, and the > connections don't sticky. My 2 pfsense boxes are plugged into a switch that has 2 HSRP connections from the > provider.
Turns out that sticky-address is working just fine. I mis-interpreted the meaning of sticky-address, which means that as long as a TCP connection is active (not broken down properly) the server will stick.
I was hoping to have some sort of persistent time-limited server in the pool that would last for an hour.Sorry about the confusion.