Hi,
I am sorry that I made bugs in ipvs 0.9.3. Thank Jiluan for reminding
me. The known bugs are fixed in ipvs 0.9.3. The tar ball is available
at:
http://www.LinuxVirtualServer.org/ipvs-0.9.4-2.2.13.tar.gz
Virtual Server patch for Linux 2.2 - Version 0.9.4 - November 10, 1999
Changes:
* Julian fixed the fatal return bug of ip_vs_leave()
Since some code of last version ipvs is changed, ip_vs_leave
should return -2 instead of -3 if no virtual service is
found.
* Added the IPSKB_REDIRECTED flag
The skb is set with the IPSKB_REDIRECTED and IPSKB_MASQUERADED
flag, so that the system can detect infinite loop of TUNNELED/
DROUTED packets in the ip_local_deliver caused by misconfiguration.
For example, user might configure the following:
ipvsadm -a -t VIP:http -r <non-local IP address> -i
ifconfig <an interface> <the IP address above> up
then packets for VIP:http is tunneled to its own interface, which
will causes infinite loop.
* Fixed the bug that freed skb may be used to masq_set_state
In the original ip_fw_demasquerade function, masq_set_state was
called after ip_vs_forward, and ip_vs_forward may free the skb,
so masq_set_state may operate the already freed skb. The current
solution is just to simply do masq_set_state before ip_vs_forward.
No matter whether the packet is forwarded successfully or not,
the masq state will be updated. Although it brokes the original
sematics, it won't lead to serious errors. We look forward to
fixing it under the Rusty's netfilter framework both for correctness
and modularization. :-)
Many thanks must go to Julian for his very cute comments to the
ipvs 0.9.3 code. He also raised a question, could we simply use
ip_route_output to skip IPv4 forwarding and firewall to tunnel/
droute packets for a little bit performance, or should we be
back to ip_route_input for correctness? I am still thinking about
it.
Thanks,
Wensong
----------------------------------------------------------------------
LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
To unsubscribe, e-mail: lvs-users-unsubscribe@xxxxxxxxxxxxxxxxxxxxxx
For additional commands, e-mail: lvs-users-help@xxxxxxxxxxxxxxxxxxxxxx
|