Mailing List Archive

Hello,

On Wed, 14 Feb 2001, Henrik Nordstrom wrote:

> Hi.
>
> Here is a small patch to make LVS keep the MARK, and have return traffic
> inherit the mark.
>
> We use this for routing purposes on a multihomed LVS server, to have
> return traffic routed back the same way as from where it was received.
> What we do is that we set the mark in the iptables mangle chain
> depending on source interface, and in the routing table use this mark to
> have return traffic routed back in the same (opposite) direction.
>
> The patch also moves the priority of LVS INPUT hook back to infront of
> iptables filter hook, this to be able to filter the traffic not picked
> up by LVS but matchin it's service definitions. We are not
> (yet) interested of filtering traffic to the virtual servers, but very
> interested in filtering what traffic reaches the Linux LVS-box itself.

"We are not interested ..." :)))

1. ip_vs_in2 is too small:

- packet defragmentation code is missing
- who uses NFC_ALTERED ?
- protocol header length is not checked
- related ICMP is not handled

2. Some parts of the code is commented. Is this a part from the
proposal?

3. LOCAL_IN priority change is not acceptable: this ignores some
useful features.

Give us an example (with dummy addresses) for setup that require
such fwmark assignments.

> Regards
> Henrik Nordstrom
> SafeCore Technologies


Regards

--
Julian Anastasov <ja@ssi.bg>

Julian Anastasov wrote:

> Hello,
>
> On Wed, 14 Feb 2001, Henrik Nordstrom wrote:
>
> > Hi.
> >
> > Here is a small patch to make LVS keep the MARK, and have return traffic
> > inherit the mark.
> >
> > We use this for routing purposes on a multihomed LVS server, to have
> > return traffic routed back the same way as from where it was received.
> > What we do is that we set the mark in the iptables mangle chain
> > depending on source interface, and in the routing table use this mark to
> > have return traffic routed back in the same (opposite) direction.
> >
> > The patch also moves the priority of LVS INPUT hook back to infront of
> > iptables filter hook, this to be able to filter the traffic not picked
> > up by LVS but matchin it's service definitions. We are not
> > (yet) interested of filtering traffic to the virtual servers, but very
> > interested in filtering what traffic reaches the Linux LVS-box itself.
>
> "We are not interested ..." :)))

And you think I care :)

> 1. ip_vs_in2 is too small:
>
> - packet defragmentation code is missing
> - who uses NFC_ALTERED ?

Netfilter. The packet is accepted by the hook but altered (mark changed).

> - protocol header length is not checked
> - related ICMP is not handled

Oops. Thanks for the feedback. Will fix these.

> 2. Some parts of the code is commented. Is this a part from the
> proposal?

This because there is a collision between the fwmark based farms and this
code. We are not using fwmark based farms so I choose to ignore those for
now.

> 3. LOCAL_IN priority change is not acceptable: this ignores some
> useful features.

I did not expect you to accept this. It is a short term solution for us,
until other measurements have been made to integrate iptables rules and ipvs
to not require a overly complex iptables ruleset in order to accept
IPVS traffic.

> Give us an example (with dummy addresses) for setup that require
> such fwmark assignments.

For a start you need a LVS setup with more than one real interface receiving
client traffic for this to be of any use. Some clients (due to routing
outside the LVS server) comes in on one interface, other clients on another
interface. In this setup you might not want to have a equally complex routing
table on the actual LVS server itself.

--
Henrik Nordstrom
SafeCore Technologies

Hi,

> And you think I care :)

:)

> > 2. Some parts of the code is commented. Is this a part from the
> > proposal?
>
> This because there is a collision between the fwmark based farms and this
> code. We are not using fwmark based farms so I choose to ignore those for
> now.

But for my setup the fwmark is crucial, you cannot just ignore it.

> I did not expect you to accept this. It is a short term solution for us,
> until other measurements have been made to integrate iptables rules and ipvs
> to not require a overly complex iptables ruleset in order to accept
> IPVS traffic.

I don't think this is the case, see my comment below.

> For a start you need a LVS setup with more than one real interface receiving
> client traffic for this to be of any use. Some clients (due to routing
> outside the LVS server) comes in on one interface, other clients on another
> interface. In this setup you might not want to have a equally complex routing
> table on the actual LVS server itself.

I've been doing this for 2 years now, I don't know what complex routing
you mean. Maybe I completely misunderstand you. Is it possible that you
have a setup where different clients comming from different CIPs are
requiring the same LVS-service template, they however come in on different
NIC's or is it that you have multiple LVS-service templates used to load-
balance different client server zone through different interfaces?

Thank you for clarification,
Roberto Nibali, ratz

--
mailto: `echo NrOatSz@tPacA.cMh | sed 's/[NOSPAM]//g'`

Hello,

On Thu, 15 Feb 2001, Henrik Nordstrom wrote:

> > 1. ip_vs_in2 is too small:
> >
> > - packet defragmentation code is missing
> > - who uses NFC_ALTERED ?
>
> Netfilter. The packet is accepted by the hook but altered (mark changed).

It is set to many places but nobody uses it :) Anyway.

> > - protocol header length is not checked
> > - related ICMP is not handled
>
> Oops. Thanks for the feedback. Will fix these.
>
> > 2. Some parts of the code is commented. Is this a part from the
> > proposal?
>
> This because there is a collision between the fwmark based farms and this
> code. We are not using fwmark based farms so I choose to ignore those for
> now.

Not in 0.2.3. You already can use fwmark only for routing (as in
your patch) without touching this code. Some CPU cycles, just like the
other users will spend some cycles in walking ip_vs_in2 without using
it :)

> > 3. LOCAL_IN priority change is not acceptable: this ignores some
> > useful features.
>
> I did not expect you to accept this. It is a short term solution for us,
> until other measurements have been made to integrate iptables rules and ipvs
> to not require a overly complex iptables ruleset in order to accept
> IPVS traffic.

I'm thinking on how we can make LVS more customizable. It looks
like more features will appear that can't be implemented in users space
but that hurt other LVS and non-LVS users. Sometimes the performance is
meaningful. And it is acceptable to look for existing connections (in
any connection tracking implementation) in the pre routing (as in your
patch). The problem comes when connections are created in this chain.
This is one of the things I don't like in Netfilter but this is my
opinion.

> > Give us an example (with dummy addresses) for setup that require
> > such fwmark assignments.
>
> For a start you need a LVS setup with more than one real interface receiving
> client traffic for this to be of any use. Some clients (due to routing
> outside the LVS server) comes in on one interface, other clients on another
> interface. In this setup you might not want to have a equally complex routing
> table on the actual LVS server itself.

Agreed. It seems an optional hook registering will be a good
idea for LVS. Not sure how simple it can be done, with module options?
How LVS will be tuned when it is compiled in the kernel. Because all
useful features implemented together can collide or at least can drop
the performance in some cases. We know that the LVS/NAT performance
is critical for some users.

> --
> Henrik Nordstrom
> SafeCore Technologies


Regards

--
Julian Anastasov <ja@ssi.bg>

Roberto Nibali wrote:

> I've been doing this for 2 years now, I don't know what complex routing
> you mean. Maybe I completely misunderstand you. Is it possible that you
> have a setup where different clients comming from different CIPs are
> requiring the same LVS-service template, they however come in on different
> NIC's or is it that you have multiple LVS-service templates used to load-
> balance different client server zone through different interfaces?

Correct.

All clients are connecting to the same LVS definitions (a bunch of them), but
coming from different directions for which having a routing table would be quite
complex.

--
Henrik Nordstrom
SafeCore Technologies

Julian Anastasov wrote:

> Agreed. It seems an optional hook registering will be a good
> idea for LVS. Not sure how simple it can be done, with module options?
> How LVS will be tuned when it is compiled in the kernel. Because all
> useful features implemented together can collide or at least can drop
> the performance in some cases. We know that the LVS/NAT performance
> is critical for some users.

I think the natural way for a thing like this is to make a separate module that
installs the hook.

--
Henrik Nordstrom
SafeCore

Julian Anastasov wrote:

> Not in 0.2.3. You already can use fwmark only for routing (as in
> your patch) without touching this code. Some CPU cycles, just like the
> other users will spend some cycles in walking ip_vs_in2 without using
> it :)

Yes, you can use fwmark for routing, but not really in the manner this patch
enables.

This patch is for routing of the return traffic from the real server in the
direction from where the initial packet that started the session was received.

It might however be the case that the collision no longer is there. The patch
started it's life as a patch to Netfilter IPVS 0.0.5.

> I'm thinking on how we can make LVS more customizable. It looks
> like more features will appear that can't be implemented in users space
> but that hurt other LVS and non-LVS users. Sometimes the performance is
> meaningful. And it is acceptable to look for existing connections (in
> any connection tracking implementation) in the pre routing (as in your
> patch). The problem comes when connections are created in this chain.
> This is one of the things I don't like in Netfilter but this is my
> opinion.

Regarding iptables / ipvs I currently "only" have three main issues.

a) As the "INPUT" traffic bypasses most normal routes, the iptables conntrack
will get quite confused by return traffic..
b) Sessions will be tracked twice. Both by iptables conntrack and by IPVS.
c) There is no obvious choice if IPVS LOCAL_IN sould be placed before or after
iptables filter hook. Having it after enables the use of many fancy iptables
options, but instead requires one to have rules in iptables for allowing ipvs
traffic, and any mismatches (either in rulesets or IPVS operation) will cause the
packets to actually hit the IP interface of the LVS server which in most cases is
not what was intended.

--
Henrik Nordstrom
SafeCore Technologies

Hi,

I still cannot get a clear picture what your code is for. Would you
please give an example of how to use it.

Thanks,

Wensong


On Wed, 14 Feb 2001, Henrik Nordstrom wrote:

> Hi.
>
> Here is a small patch to make LVS keep the MARK, and have return traffic
> inherit the mark.
>
> We use this for routing purposes on a multihomed LVS server, to have
> return traffic routed back the same way as from where it was received.
> What we do is that we set the mark in the iptables mangle chain
> depending on source interface, and in the routing table use this mark to
> have return traffic routed back in the same (opposite) direction.
>
> The patch also moves the priority of LVS INPUT hook back to infront of
> iptables filter hook, this to be able to filter the traffic not picked
> up by LVS but matchin it's service definitions. We are not
> (yet) interested of filtering traffic to the virtual servers, but very
> interested in filtering what traffic reaches the Linux LVS-box itself.
>
> Regards
> Henrik Nordstrom
> SafeCore Technologies
>

Henrik Nordstrom wrote:
>
> Roberto Nibali wrote:
>
> > I've been doing this for 2 years now, I don't know what complex routing
> > you mean. Maybe I completely misunderstand you. Is it possible that you
> > have a setup where different clients comming from different CIPs are
> > requiring the same LVS-service template, they however come in on different
> > NIC's or is it that you have multiple LVS-service templates used to load-
> > balance different client server zone through different interfaces?
>
> Correct.
>
> All clients are connecting to the same LVS definitions (a bunch of them), but
> coming from different directions for which having a routing table would be quite
> complex.

Ok, I understand and I have to say that I've never set up such a
system. But how about using the DR-method? You'd have on single
DGW and would not have any issues with routing. Is this an option
for you? Well, your patch seems to work for you, so go for it, I'm
just wondering what the advantages of such a network design can be.

Best regards,
Roberto Nibali, ratz

--
mailto: `echo NrOatSz@tPacA.cMh | sed 's/[NOSPAM]//g'`

Hello,

On Thu, 15 Feb 2001, Henrik Nordstrom wrote:

> Julian Anastasov wrote:
>
> > Not in 0.2.3. You already can use fwmark only for routing (as in
> > your patch) without touching this code. Some CPU cycles, just like the
> > other users will spend some cycles in walking ip_vs_in2 without using
> > it :)
>
> Yes, you can use fwmark for routing, but not really in the manner this patch
> enables.
>
> This patch is for routing of the return traffic from the real server in the
> direction from where the initial packet that started the session was received.

Yes. My thought was that 0.2.3 already assumes that fwmark
can be used for routing-only purposes, i.e. not always for fwmark-based
LVS service.

> It might however be the case that the collision no longer is there. The patch
> started it's life as a patch to Netfilter IPVS 0.0.5.

Yep, in 0.2.3 there will be only one dummy service lookup when
you use fwmark for routing. 0.0.5 will just ignore the client requests.

> > I'm thinking on how we can make LVS more customizable. It looks
> > like more features will appear that can't be implemented in users space
> > but that hurt other LVS and non-LVS users. Sometimes the performance is
> > meaningful. And it is acceptable to look for existing connections (in
> > any connection tracking implementation) in the pre routing (as in your
> > patch). The problem comes when connections are created in this chain.
> > This is one of the things I don't like in Netfilter but this is my
> > opinion.
>
> Regarding iptables / ipvs I currently "only" have three main issues.
>
> a) As the "INPUT" traffic bypasses most normal routes, the iptables conntrack
> will get quite confused by return traffic..

Is it really confused in 0.2.3? Before 0.2.x we had big problems
with the netfilter conntracking. But now we use special fwmark value
to exit from the next chains and to call okfn.

> b) Sessions will be tracked twice. Both by iptables conntrack and by IPVS.

Yes, for every forwarding method. We must find a way to stop
the connection tracking for the "external" interface where we create
connections. For the in->out traffic we are before netfilter
conntracking (not in pre_routing). May be lookups can be added in the
pre_routing for existing connections (for the both directions) but
may be that can cost very much. In Netfilter there is no double lookups.
If we add some hooks in the pre routing we have to make such
double lookups because the packets simply can be dropped (for many
reasons) before they reach LOCAL_IN. We don't hook the skb primitives
like netfilter and all games before LOCAL_IN are avoided. In your
patch the hook in pre routing is safe but you see that currently
the 2nd LVS connection lookup can't be avoided.

So, in 0.2.x the things should work but with little performance
drop when LVS is used with netfilter together. The other thing you must
not forget when you tune your patch is that LVS can work without any
netfilter modules, i.e. by using the hooks only - the fastest way.

> c) There is no obvious choice if IPVS LOCAL_IN sould be placed before or after
> iptables filter hook. Having it after enables the use of many fancy iptables
> options, but instead requires one to have rules in iptables for allowing ipvs
> traffic, and any mismatches (either in rulesets or IPVS operation) will cause the
> packets to actually hit the IP interface of the LVS server which in most cases is
> not what was intended.

Yes, some applications have extra needs for open ports (ftp).
But normally all other ports are closed. Of course, mistakes are not
allowed but relying only on the routing for security is not a good
solution. Sometimes firewall settings are required in the input chain,
usually for LVS-DR setups with one NIC and with many subnets. If the
uplink router guards the cluster the LVS/NAT setup can be with 0
INPUT fw rules, may be just like in your setup. But this can't be a
general feature in LVS, to stay before the filter because LVS does
not traverse the FORWARD fw chain like the Netfilter requires it :)
The LVS place for firewalling is INPUT just like in the Linux 2.2
days :)

> --
> Henrik Nordstrom
> SafeCore Technologies


Regards

--
Julian Anastasov <ja@ssi.bg>

DR is not an realistic option for us, there can be any kind of real servers involved,
with other administrators.

--
Henrik Nordstrom
SafeCore Technologies


Roberto Nibali wrote:

> Ok, I understand and I have to say that I've never set up such a
> system. But how about using the DR-method? You'd have on single
> DGW and would not have any issues with routing. Is this an option
> for you? Well, your patch seems to work for you, so go for it, I'm
> just wondering what the advantages of such a network design can be.
>
> Best regards,
> Roberto Nibali, ratz

Hi,

> DR is not an realistic option for us, there can be any kind of real servers involved,

This is absolutely not a problem ... (unless you try it with Plan9 or Amoeba)

> with other administrators.

...this however can be a problem.

BTW, stupid question: If your incoming requests come through different
interfaces,
do they all leave through the same one and go to the realservers? Sketch:

____________ ____________ ____________
| | | | | |
| client 1 | | client2 | | client 3 |
|____________| |____________| |____________|
| | |
| | |
(router) (router) (router)
| | |
+-----------+ | +---------+
___|_____|_____|____
| |
| director (VIP) |
|____________________|
|
|
|
------------------------------------
| | |
| | |
RIP1, VIP RIP2, VIP RIP3, VIP
____________ ____________ ____________
| | | | | |
|real-server1| |real-server2| |real-server3|
|____________| |____________| |____________|


If the setup looks like this, you can still do some kind of VS-DR approach
without having to deal with the arp-problem. I used this setup together with
HP/UX 10.20 and 11 boxes.

Regards,
Roberto Nibali, ratz

--
mailto: `echo NrOatSz@tPacA.cMh | sed 's/[NOSPAM]//g'`

Hi,

I know F5 load balancer have this feature, they call it as last hop.
This feature can be use for multihome ISP setup without running complex
routing like BGP. It also can use this feature for load balance the firewall
(incoming and outgoing traffic). I believe this is a good feature a load
balancer should have.

Regards
Guan Boon

-----Original Message-----
From: Wensong Zhang [mailto:wensong@gnuchina.org]
Sent: Thursday, February 15, 2001 8:55 PM
To: lvs-users@LinuxVirtualServer.org
Subject: Re: LVS with mark tracking




Hi,

I still cannot get a clear picture what your code is for. Would you
please give an example of how to use it.

Thanks,

Wensong


On Wed, 14 Feb 2001, Henrik Nordstrom wrote:

> Hi.
>
> Here is a small patch to make LVS keep the MARK, and have return traffic
> inherit the mark.
>
> We use this for routing purposes on a multihomed LVS server, to have
> return traffic routed back the same way as from where it was received.
> What we do is that we set the mark in the iptables mangle chain
> depending on source interface, and in the routing table use this mark to
> have return traffic routed back in the same (opposite) direction.
>
> The patch also moves the priority of LVS INPUT hook back to infront of
> iptables filter hook, this to be able to filter the traffic not picked
> up by LVS but matchin it's service definitions. We are not
> (yet) interested of filtering traffic to the virtual servers, but very
> interested in filtering what traffic reaches the Linux LVS-box itself.
>
> Regards
> Henrik Nordstrom
> SafeCore Technologies
>


_______________________________________________
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

-----Original Message-----
From: Roberto Nibali [mailto:ratz@tac.ch]
Sent: Friday, February 16, 2001 12:11 AM
To: lvs-users@LinuxVirtualServer.org
Subject: Re: LVS with mark tracking


Hi,

> DR is not an realistic option for us, there can be any kind of real
servers involved,

This is absolutely not a problem ... (unless you try it with Plan9 or
Amoeba)

> with other administrators.

...this however can be a problem.

BTW, stupid question: If your incoming requests come through different
interfaces,
do they all leave through the same one and go to the realservers? Sketch:

The problem for multihoming
Many companies require for high availability by using links to more than one
ISP. The ISP market is not as mature as other countries and we find that
each ISP is either unwilling or unable to provide proper BGP support. This
places and overhead on the content provider or hosting site to use multiple
address spaces, one registered address space per ISP.

The solution
One solution to this problem would be to create a dummy VIP for each ISP
connection. To the dummy VIP address a member is added that would be
unavailable should the link or ISP be unavailable. The availability of the
member could be checked using a simple ping. Should the member be
unavailable then the VIP will also be unavailable since it has only one
member. To ensure that the director sends ping checks to the correct ISP
connection a static host route should be added to the director routing table
to force the check through the correct ISP connection and thus the correct
interface address.
Now that we have a mechanism to determining the availability, from the
Internet, of each registered address space we can tie the dummy VIP port and
real VIP port together using DNS. DNS is configured to use a VIP only if the
real port and the dummy VIP port are both available.It means that DNS should
be intelligent health check the vip. Should either VIP port be unavailable
then the real VIP address will not be returned to the client.

____________ ____________ ____________
| | | | | |
| ISP1 | | ISP2 | | ISP3 |
|____________| |____________| |____________|
| | |
| | |
(router) (router) (router)
| | |
+-----------+ | +---------+
___|_____|_____|____
| |
| director (VIP) |
|____________________|
|
|
|
------------------------------------
| | |
| | |

____________ ____________ ____________
| | | | | |
|real-server1| |real-server2| |real-server3|
|____________| |____________| |____________|


If the setup looks like this, you can still do some kind of VS-DR approach
without having to deal with the arp-problem. I used this setup together with
HP/UX 10.20 and 11 boxes.

Regards,
Roberto Nibali, ratz

--
mailto: `echo NrOatSz@tPacA.cMh | sed 's/[NOSPAM]//g'`

_______________________________________________
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

I was wondering if this was possible with lvs - and now it appears it is!
Great!!

There is a great deal of general description below though :(. Is there a
simple tutorial that describes _exactly_ how to do this, or would someone be
willing to write one?

Perhaps it should be a section in the howto?

Regards,

Ivan
----- Original Message -----
From: "Tan, Guan Boon" <guan.boon.tan@intel.com>
To: <lvs-users@LinuxVirtualServer.org>
Sent: Thursday, February 15, 2001 8:05 PM
Subject: RE: LVS with mark tracking



> The problem for multihoming
> Many companies require for high availability by using links to more than
one
> ISP. The ISP market is not as mature as other countries and we find that
> each ISP is either unwilling or unable to provide proper BGP support. This
> places and overhead on the content provider or hosting site to use
multiple
> address spaces, one registered address space per ISP.
>
> The solution
> One solution to this problem would be to create a dummy VIP for each ISP
> connection. To the dummy VIP address a member is added that would be
> unavailable should the link or ISP be unavailable. The availability of the
> member could be checked using a simple ping. Should the member be
> unavailable then the VIP will also be unavailable since it has only one
> member. To ensure that the director sends ping checks to the correct ISP
> connection a static host route should be added to the director routing
table
> to force the check through the correct ISP connection and thus the correct
> interface address.
> Now that we have a mechanism to determining the availability, from the
> Internet, of each registered address space we can tie the dummy VIP port
and
> real VIP port together using DNS. DNS is configured to use a VIP only if
the
> real port and the dummy VIP port are both available.It means that DNS
should
> be intelligent health check the vip. Should either VIP port be unavailable
> then the real VIP address will not be returned to the client.
> _______________________________________________
> 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
>

> The problem for multihoming
> Many companies require for high availability by using links to more than one
> ISP. The ISP market is not as mature as other countries and we find that
> each ISP is either unwilling or unable to provide proper BGP support. This
> places and overhead on the content provider or hosting site to use multiple
> address spaces, one registered address space per ISP.

Ok, seen that over here too.

> The solution
> One solution to this problem would be to create a dummy VIP for each ISP
> connection. To the dummy VIP address a member is added that would be
> unavailable should the link or ISP be unavailable. The availability of the
> member could be checked using a simple ping. Should the member be

Ping is IMHO not reliable enough and do you really want to enable
ICMP echo_request and reply to/from your LVS-box?

> unavailable then the VIP will also be unavailable since it has only one
> member. To ensure that the director sends ping checks to the correct ISP
> connection a static host route should be added to the director routing table
> to force the check through the correct ISP connection and thus the correct
> interface address.

Oups, I'm a but confused, tell me, did the sketch below reflect
your setup correctly or did it?

> Now that we have a mechanism to determining the availability, from the
> Internet, of each registered address space we can tie the dummy VIP port and
> real VIP port together using DNS. DNS is configured to use a VIP only if the
> real port and the dummy VIP port are both available.It means that DNS should

You mean template based healthchecking and dynamic DNS reconfiguration?

> be intelligent health check the vip. Should either VIP port be unavailable
> then the real VIP address will not be returned to the client.

I really start thinking, that I got you're setup wrong. Please tell me
if the sketch does show your desired network setup.

> ____________ ____________ ____________
> | | | | | |
> | ISP1 | | ISP2 | | ISP3 |
> |____________| |____________| |____________|
> | | |
> | | |
> (router) (router) (router)
> | | |
> +-----------+ | +---------+
> ___|_____|_____|____
> | |
> | director (VIP) |
> |____________________|
> |
> |
> |
> ------------------------------------
> | | |
> | | |
>
> ____________ ____________ ____________
> | | | | | |
> |real-server1| |real-server2| |real-server3|
> |____________| |____________| |____________|

Regards,
Roberto Nibali, ratz

--
mailto: `echo NrOatSz@tPacA.cMh | sed 's/[NOSPAM]//g'`

Hi,

This is just a desired network setup. I haven't setup this
successful yet. The network diagram should be like this. Anyone who setup
this successfully ?

Regards
Guan Boon

-----Original Message-----
From: Roberto Nibali [mailto:ratz@tac.ch]
Sent: Sunday, February 18, 2001 6:18 PM
To: lvs-users@LinuxVirtualServer.org
Subject: Re: LVS with mark tracking


> The problem for multihoming
> Many companies require for high availability by using links to more than
one
> ISP. The ISP market is not as mature as other countries and we find that
> each ISP is either unwilling or unable to provide proper BGP support. This
> places and overhead on the content provider or hosting site to use
multiple
> address spaces, one registered address space per ISP.

Ok, seen that over here too.

> The solution
> One solution to this problem would be to create a dummy VIP for each ISP
> connection. To the dummy VIP address a member is added that would be
> unavailable should the link or ISP be unavailable. The availability of the
> member could be checked using a simple ping. Should the member be

Ping is IMHO not reliable enough and do you really want to enable
ICMP echo_request and reply to/from your LVS-box?

> unavailable then the VIP will also be unavailable since it has only one
> member. To ensure that the director sends ping checks to the correct ISP
> connection a static host route should be added to the director routing
table
> to force the check through the correct ISP connection and thus the correct
> interface address.

Oups, I'm a but confused, tell me, did the sketch below reflect
your setup correctly or did it?

> Now that we have a mechanism to determining the availability, from the
> Internet, of each registered address space we can tie the dummy VIP port
and
> real VIP port together using DNS. DNS is configured to use a VIP only if
the
> real port and the dummy VIP port are both available.It means that DNS
should

You mean template based healthchecking and dynamic DNS reconfiguration?

> be intelligent health check the vip. Should either VIP port be unavailable
> then the real VIP address will not be returned to the client.

I really start thinking, that I got you're setup wrong. Please tell me
if the sketch does show your desired network setup.

> ____________ ____________ ____________
> | | | | | |
> | ISP1 | | ISP2 | | ISP3 |
> |____________| |____________| |____________|
> | | |
> | | |
> (router) (router) (router)
> | | |
> +-----------+ | +---------+
> ___|_____|_____|____
> | |
> | director (VIP) |
> |____________________|
> |
> |
> |
> ------------------------------------
> | | |
> | | |
>
> ____________ ____________ ____________
> | | | | | |
> |real-server1| |real-server2| |real-server3|
> |____________| |____________| |____________|

Regards,
Roberto Nibali, ratz

--
mailto: `echo NrOatSz@tPacA.cMh | sed 's/[NOSPAM]//g'`

_______________________________________________
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

"Tan, Guan Boon" wrote:
>
> Hi,
>
> This is just a desired network setup. I haven't setup this
> successful yet. The network diagram should be like this. Anyone who setup
> this successfully ?

Aha, now I see what you meant with BGP. You have to run this kind of
network setup. What happens if link on from provider 1 goes down? All
clients that made a DNS request and got it from the primary DNS will
have it in the cache now and until that one expires it could take you
up to one day of downtime. Do I get this correct? Could you explain
how you tried to set LVS up for your network?

Regards,
Roberto Nibali, ratz

--
mailto: `echo NrOatSz@tPacA.cMh | sed 's/[NOSPAM]//g'`