Re: pf address pools
So, do you think it might be better to use ipfilter than pf on OpenBSD in that case ? And the next question is, is it useful to have a wide spread (more than on IP subnet) servers to do load-balancing on ? After all, that is a feature, the BigIP supports and I know that atleast www.heisse.de is using this, to implement complete redundancy by location seperated servers. But for most users, that should be enough. @Daniel Hartmeyer : is auto-detection of down hosts implemented in the load-balancing code in pf ? By the way : my company is nearly 100% convinced to kick our Nokia / CheckPoint and to take a OpenBSD/pf box to replace, due to several problems with our ISP and their understanding of Management and Support. - Original Message - From: Darren Reed [EMAIL PROTECTED] To: Jedi/Sector One [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, November 29, 2002 9:53 AM Subject: Re: pf address pools In some mail from Jedi/Sector One, sie said: On Thu, Nov 28, 2002 at 11:59:37PM +, Ryan McBride wrote: rdr on $ext_if from any to $public_ip port 80 - \ 192.168.0.4/30 source-hash As a side note, source-hash (a feature called 'sticky balancing' on some hardware load balancers) is very useful for web servers with PHP because: - by default, PHP save sessions in local files. - to speed up things, it's also possible to use shared memory. - poorly written PHP scripts (those that customers like to install) like to create temporary files in /tmp. Without sticky balancing, a typical syndrom is that users have to re-authenticate several times while browsing a web site. Well I don't think the above is a good implementation of sticky load balancing because it confines your destination IP addresses to be a single subnet mask range. I did sticky redirection for IPFilter last month, I think, and that implementation does not have this problem. More importantly, the stickiness can be mixed with any other redirection options. If routers use the above for stickiness then said routers suck, IMHO. Darren
Re: pf address pools
sorry, www.heise.de, not www.heisse.de ! - Original Message - From: Stefan Sonnenberg-Carstens [EMAIL PROTECTED] To: Darren Reed [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, November 29, 2002 10:21 AM Subject: Re: pf address pools So, do you think it might be better to use ipfilter than pf on OpenBSD in that case ? And the next question is, is it useful to have a wide spread (more than on IP subnet) servers to do load-balancing on ? After all, that is a feature, the BigIP supports and I know that atleast www.heisse.de is using this, to implement complete redundancy by location seperated servers. But for most users, that should be enough. @Daniel Hartmeyer : is auto-detection of down hosts implemented in the load-balancing code in pf ? By the way : my company is nearly 100% convinced to kick our Nokia / CheckPoint and to take a OpenBSD/pf box to replace, due to several problems with our ISP and their understanding of Management and Support. - Original Message - From: Darren Reed [EMAIL PROTECTED] To: Jedi/Sector One [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, November 29, 2002 9:53 AM Subject: Re: pf address pools In some mail from Jedi/Sector One, sie said: On Thu, Nov 28, 2002 at 11:59:37PM +, Ryan McBride wrote: rdr on $ext_if from any to $public_ip port 80 - \ 192.168.0.4/30 source-hash As a side note, source-hash (a feature called 'sticky balancing' on some hardware load balancers) is very useful for web servers with PHP because: - by default, PHP save sessions in local files. - to speed up things, it's also possible to use shared memory. - poorly written PHP scripts (those that customers like to install) like to create temporary files in /tmp. Without sticky balancing, a typical syndrom is that users have to re-authenticate several times while browsing a web site. Well I don't think the above is a good implementation of sticky load balancing because it confines your destination IP addresses to be a single subnet mask range. I did sticky redirection for IPFilter last month, I think, and that implementation does not have this problem. More importantly, the stickiness can be mixed with any other redirection options. If routers use the above for stickiness then said routers suck, IMHO. Darren
Re: pf address pools
[ wild cross-posting reduced to pf list ] On Fri, Nov 29, 2002 at 10:21:22AM +0100, Stefan Sonnenberg-Carstens wrote: @Daniel Hartmeyer : is auto-detection of down hosts implemented in the load-balancing code in pf ? No, that will be done by a userland daemon. As mentioned before, people want different ways to check the server (ping, TCP connect, HTTP requests, etc.) and configure the daemon in various ways (how often to check for what conditions, how to priorize the servers, etc.) There's no reason to put that in the kernel. Daniel
Re: pf address pools
Ok, I remember round-robin DNS, but if you ever had the need to change entries for DNS servers, and you then see what T-Online, AOL and other ISP's do with your time settings, you begin to ask if this really works, despite the fact, that you normally to some sort of caching for the DNS queries, and there is no guaranty, that your ISP DNS will ask a second time. That is the reason why my company still sticks on BigIP. - Original Message - From: Dries Schellekens [EMAIL PROTECTED] To: Stefan Sonnenberg-Carstens [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, November 29, 2002 1:40 PM Subject: Re: pf address pools On Fri, 29 Nov 2002, Stefan Sonnenberg-Carstens wrote: So, do you think it might be better to use ipfilter than pf on OpenBSD in that case ? This feature (round-robin sticky) is not in ipfilter 3.4.30 (released this week), so it's only available in ipfilter 4.0 alpha. To implement sticky balancing across multiple subnets you have to remember which address was used for which client source address. The cost of this is memory and time to search through it. Calculating a hash is much easier, but you don't have the flexiblity of redirecting across multiple subnets. And the next question is, is it useful to have a wide spread (more than on IP subnet) servers to do load-balancing on ? After all, that is a feature, the BigIP supports and I know that atleast www.heisse.de is using this, to implement complete redundancy by location seperated servers. Then where would you put your load balancing machine? Round-robin DNS is much easier to acomplish this. I think most other solutions want to servers in the same subnet. For instance if you want to do Virtual Server via Direct Routing (linux virtual server project calls it this way), the servers need to be on the same subnet: http://www.linuxvirtualserver.org/VS-DRouting.html BTW this technique is much better than a Virtual Server via NAT, because only the request needs to pass through the load balancer, while the reply does not. - Original Message - From: Darren Reed [EMAIL PROTECTED] To: Jedi/Sector One [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, November 29, 2002 9:53 AM Subject: Re: pf address pools In some mail from Jedi/Sector One, sie said: On Thu, Nov 28, 2002 at 11:59:37PM +, Ryan McBride wrote: rdr on $ext_if from any to $public_ip port 80 - \ 192.168.0.4/30 source-hash As a side note, source-hash (a feature called 'sticky balancing' on some hardware load balancers) is very useful for web servers with PHP because: - by default, PHP save sessions in local files. - to speed up things, it's also possible to use shared memory. - poorly written PHP scripts (those that customers like to install) like to create temporary files in /tmp. Without sticky balancing, a typical syndrom is that users have to re-authenticate several times while browsing a web site. Well I don't think the above is a good implementation of sticky load balancing because it confines your destination IP addresses to be a single subnet mask range. I did sticky redirection for IPFilter last month, I think, and that implementation does not have this problem. More importantly, the stickiness can be mixed with any other redirection options. If routers use the above for stickiness then said routers suck, IMHO. Darren Dries -- Dries Schellekens email: [EMAIL PROTECTED]