Mailing List Archive

This is the same sort of set up that I would like to do. One computer
with two net cards one public one private. The computer does the NAT and
the LVS. I don't care what implementation I have to use. This seems like
the most logical way to do the LVS setup with NAT. Has no one else tried
it this way???

--
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
| Douglas F. Elznic |
| <dfelznic (at) syr.edu> |
| |
| O r g |
| e. Anize.org |
| z i n |
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~

"K.W." <kathiw@erols.com> writes:
> can I run my ipchains firewall and LVS (piranha in this case) on the
> same box? It would seem that I cannot, since ipchains can't understand
> virtual interfaces such as eth0:1, etc.

It works fine for me. I've not tried to use ipchains with alias
interfaces, but I do use aliased IP addresses in my incoming rulesets,
and it works exactly as I would expect it to.

Brian.

Hello,

On Mon, 19 Feb 2001, K.W. wrote:

> Hi,
>
> After a disappointing experience with iptables, which I can't get to do
> load-balancing at this point, I am turning to ipchains and LVS to
> firewall and load balance two web servers.
>
> I'm sorry if this is such a basic question, but I have not seen the
> answer in the LVS archives, and did not receive an answer from the
> ipchains list: can I run my ipchains firewall and LVS (piranha in this
> case) on the same box? It would seem that I cannot, since ipchains can't
> understand virtual interfaces such as eth0:1, etc.

I'm not sure whether piranha already supports kernel 2.4, I
have to check it. ipchains does not understand interfaces aliase even
in Linux 2.2. Any setup that uses such aliases can be implemented
without using them. I don't know for routing restrictions that
require using aliases.

> I have a full ipchains firewall script, which works (includes port
> forwarding), and a stripped-down ipchains script just for LVS, and they
> each work fine separately. When I merge them, I can't reach even just
> the firewall box. As I mentioned, I suspect this is because of the
> virtual interfaces required by LVS.

LVS does not require any (virtual) interfaces. LVS never
checks the devices nor any aliases. I'm not sure what is the port
forwarding support in ipchains too. Is that the support provided
from ipmasqadm: the portfw and mfw modules? If yes, they are not
implemented (yet). And this support is not related to ipchains
at all. Some good features are still not ported from Linux 2.2 to
2.4 including all these autofw useful things. But you can use LVS
in the places where use ipmasqadm portfw/mfw but not for the autofw
tricks. LVS can perfectly do the portfw job and even to extend it
after the NAT support: there are DR and TUN methods too.

> If running both services on one box is impossible, do I need two boxes
> with two NICs each? Seems like an awful lot of translation will be going
> on, which could impede performance.

Yep, the transition can be complex but for load balancing with
firewall support I don't see problems. May be you will have some
problems with the ipchains -j MASQ support but I'm not sure. And
the firewall rules are simple to move to iptables commands.

> Any help and/or ideas are much appreciated. I will be happy to provide
> more details if necessary.

Yes, without the details everything is theory.

> thanks,
>
> Kathi Whalen


Regards

--
Julian Anastasov <ja@ssi.bg>

On Mon, Feb 19, 2001 at 10:30:12PM +0500, Douglas F. Elznic wrote:
> This is the same sort of set up that I would like to do. One computer
> with two net cards one public one private. The computer does the NAT and
> the LVS. I don't care what implementation I have to use. This seems like
> the most logical way to do the LVS setup with NAT. Has no one else tried
> it this way???

Here at work, me and Denis Petit set up a 4-PC cluster with this configuration
: 2 are the real servers, running Apache, and 2 are redundant distributors.
Each distributor uses LVS, Heartbeat, ldirectord and does the masquerading
using ipchains. Everything works perfectly so far. :-)

The only tricks we found are that the classical directory hierarchy
differences between RedHat and Debian, and the need to add a IP migration for
the local side, as we used the NAT method.


Best regards,


--
Thierry Mallard | GnuPG key on pgp.ai.mit.edu
http://IDEALX.com | key 0xA3D021CB
http://thierry.mallard.com |

That is the same thing that I am trying to accomplish.

"Douglas F. Elznic" wrote:

> This is the same sort of set up that I would like to do. One computer
> with two net cards one public one private. The computer does the NAT and
> the LVS. I don't care what implementation I have to use. This seems like
> the most logical way to do the LVS setup with NAT. Has no one else tried
> it this way???
>
> --
> ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
> | Douglas F. Elznic |
> | <dfelznic (at) syr.edu> |
> | |
> | O r g |
> | e. Anize.org |
> | z i n |
> ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
>
> _______________________________________________
> LinuxVirtualServer.org mailing list - lvs-users@LinuxVirtualServer.org
> Send requests to lvs-users-request@LinuxVirtualServer.org
> or go to http://www.in-addr.de/mailman/listinfo/lvs-users

Douglas "F." Elznic <dfelznic@syr.edu> writes:
> One computer with two net cards one public one private. The computer
> does the NAT and the LVS. I don't care what implementation I have to
> use. This seems like the most logical way to do the LVS setup with
> NAT. Has no one else tried it this way???

As I've already said, this is exactly what I do[1], and it works just
fine. But please don't ask me Redhat related questions, as I've set it
up with just the basic tools (lvs and linux-ha), and I don't know
anything about nanny, pulse, or whatever else the various companies are
doing on top of it.

Brian Edmonds, Web Operations Lead
Antarcti.ca Systems Incorporated

[1] On a somewhat larger scale. We have two LVS/NAT routers, on
separate physical switches from our provider, both with two internal
interfaces[2], and all real servers have two interfaces. All to help
eliminate single points of failure while still using cheap hardware.
Any network card, switch port, or entire switch or router goes out and
the cluster continues to function.

[2] The routers have four internal interfaces actually, for future
expansion if required. :)

> [1] On a somewhat larger scale. We have two LVS/NAT routers, on
> separate physical switches from our provider, both with two internal
> interfaces[2], and all real servers have two interfaces.

can you elaborate a little on this?

are you running HA on this (two external interfaces each?) or simply
relying on the extra paths?

do your two external interfaces have different IPs? if not, how do you
fail people over?

Bart Locanthi <bart@sabl.com> writes:
>> [1] On a somewhat larger scale. We have two LVS/NAT routers, on
>> separate physical switches from our provider, both with two internal
>> interfaces[2], and all real servers have two interfaces.
> are you running HA on this (two external interfaces each?) or simply
> relying on the extra paths?

That was two *internal* interfaces. The two routers obviously have
different IP addresses externally. We're running heartbeat for the
virtual IP addresses so that they will move between the routers as
required, as well as for the internal default router addresses so that
internal machines can always get out as well.

The internal servers are running a little script which monitors the
reachability of the default router, and if it fails switches over to the
other interface. I'll attach it on the end, as it's pretty simple.

Brian.

----- snip -----
#!/bin/bash

PATH=/sbin:$PATH

if route -n | egrep -q '^0\.0\.0\.0'; then
date
echo 'Default route exists, aborting.'
echo
exit 1
fi

date
subnet=1
echo "Setting default route to 10.2.${subnet}.254."
route add default gw 10.2.${subnet}.254
failures=0
echo

while true; do
sleep 5
if ping -c 1 -w 2 10.2.${subnet}.254 >/dev/null 2>&1; then
failures=0
else
failures=`expr $failures + 1`
fi
if [ $failures -lt 3 ]; then continue; fi

date
echo "Default route failure detected."
route del default gw 10.2.${subnet}.254
subnet=`expr $subnet + 1`
if [ $subnet -gt 2 ]; then subnet=1; fi
echo "Setting default route to 10.2.${subnet}.254."
route add default gw 10.2.${subnet}.254
failures=0
echo
done

# EOF

>I have a full ipchains firewall script, which works (includes port
>forwarding), and a stripped-down ipchains script just for LVS, and they
>each work fine separately. When I merge them, I can't reach even just
>the firewall box. As I mentioned, I suspect this is because of the
>virtual interfaces required by LVS.
>

I ran into a problem like this when adding firewall rules to my LVS ipchains
script. The problem I had was due to the order of the rules.

Remember that once a packet matches a rule in a chain it is kicked out of
the chain--it doesn't matter if it is an ACCEPT or REJECT rule(packets may
never get to your FWMARK rules, for example, if they do not come before your
ACCEPT and REJECT tests).

I am using virtual interfaces as well (eg, eth1:1) but, as Julian points
out, I had no reason to apply ipchains rules to a specific virtual interface
(even with an ipchains script that is several hundred lines long!)

--L

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

"Lorn Kay" <lorn_kay@hotmail.com> writes:
> Remember that once a packet matches a rule in a chain it is kicked out
> of the chain--it doesn't matter if it is an ACCEPT or REJECT
> rule(packets may never get to your FWMARK rules, for example, if they
> do not come before your ACCEPT and REJECT tests).

Huh? FWMARK rules? I've never seen those. Last I looked a fwmark is
added with a -m flag on an ACCEPT rule -- at least it certainly works
that way on my LVS routers. (Ok, you could probably mark a REJECT or
DENY rule, but it would be pretty pointless.)

Brian.

FWMARKing does not have to be a part of an ACCEPT rule.

If you have a default DENY policy and then say:

/sbin/ipchains -A input -d $VIP -j ACCEPT
/sbin/ipchains -A input -d $VIP 80 -p tcp -m 3
/sbin/ipchains -A input -d $VIP 443 -p tcp -m 3

To maintain persistence between port 80 and 443 for https, for example, the
packets will match on the ACCEPT rule, get kicked out of the input chain
tests, and never get marked.

--L

>From: Brian Edmonds <bedmonds@antarcti.ca>
>Reply-To: lvs-users@LinuxVirtualServer.org
>To: lvs-users@LinuxVirtualServer.org
>Subject: Re: can LVS be run ON the firewall box?
>Date: Fri, 23 Feb 2001 08:05:26 -0800 (PST)
>
>"Lorn Kay" <lorn_kay@hotmail.com> writes:
> > Remember that once a packet matches a rule in a chain it is kicked out
> > of the chain--it doesn't matter if it is an ACCEPT or REJECT
> > rule(packets may never get to your FWMARK rules, for example, if they
> > do not come before your ACCEPT and REJECT tests).
>
>Huh? FWMARK rules? I've never seen those. Last I looked a fwmark is
>added with a -m flag on an ACCEPT rule -- at least it certainly works
>that way on my LVS routers. (Ok, you could probably mark a REJECT or
>DENY rule, but it would be pretty pointless.)
>
>Brian.
>
>_______________________________________________
>LinuxVirtualServer.org mailing list - lvs-users@LinuxVirtualServer.org
>Send requests to lvs-users-request@LinuxVirtualServer.org
>or go to http://www.in-addr.de/mailman/listinfo/lvs-users

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com