|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Joseph Mack NA3T wrote:
>> According to the HOWTO text, it seems you misunderstood the
>> purpose of my patch a little bit: I don't provide a new
>> schedular, but a new director.
>
>
> Currently the definition of a scheduler that I'm using is code that
> changes the routing tables in the director to load balance the
> incoming packets. Your code fits this definition. Am I missing
> something?
>
Okay, you're right. The definition of schedular I was using is the
definition used in the source-code: The schedular is the function that
provided the scheduling behaviour: RR, WRR, WLC, etc.
>> One of the remaining problems for multipath routing under Linux
>> is the lack of flexibility on the scheduling of these multiple
>> defaultroutes. The normal multipath routing only provides a
>> weight factor, but no further setup parameters.
>
>
> How did you get the director to accept packets for 0.0.0.0/0 as
> local?
>
> http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.routing_to_VIP-less_director.html#routing_and_delivery
>
>
>
I don't force the director to accept them as local packets! I modified
the kernel to send forwarded traffic into LVS.
Thus I force the director to accept them as forwarded packets! This is
the purpose of the "LVS" iptables target. This will be a solution for
your problem as described in the HOWTO at the above link. No need for
other fancy tricks, just match the traffic in iptables and use "-j
LVS" as the target. (See below for a modification to the text of the
HOWTO on Routing_to_VIP-less_director)
>> For this problem the patches introduce a new director, called
>> LVS/Reinject.
>
>
> Do you want your code in the HOWTO to be called "Reinject" rather
> than say "multigateway"?
>
The code consists of two parts: A director called "Reinject" and a
iptables target called "LVS". For the HOWTO I would suggest:
"Multipath routing through LVS". This because the kernel term for
multiple internet connections is called multipath routing.
> Joe
Addition to text:
http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.routing_to_VIP-less_director.html#routing_and_delivery
Another solution for this problem could be the use of the patch by
Ludo Stellingwerff, which modifies the LVS entry path. This patch
provides an iptables target called "LVS" which calls the entry
function of LVS. Thus you can match the traffic to the VIP on the
FORWARD hook of iptables:
#iptables -A FORWARD -t mangle -d <VIP> -m state --state NEW -j MARK
- --set-mark 1
#iptables -A FORWARD -t mangle -m mark --mark 1 -j LVS
This last line mimics the behaviour of packets going to the director
directly, it will call the LVS functions as if the packet was on the
local-delivery path.
Greetings,
Ludo.
- --
Ludo Stellingwerff
V&S B.V. The Netherlands
ProTactive firewall solution.
Tel: +31 172 416116
Fax: +31 172 416124
site: www.protactive.nl
demo: http://www.protactive.nl:81/netview.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFDOAg9OF3sCpZ+AJgRAol4AKCJb5gX+xNnbV64cfT8XgjRHSiregCdHjdW
XMRq94GbmdUJneJw7XZ2BYg=
=uUd4
-----END PGP SIGNATURE-----
|
