Hi, all
Can anybody tell me whether latest version support ipv4 and ipv6 mixed ?
In other words, can I forward ipv6(client->director) to ipv4(director->real server) or vice versa?
I checked codes, it seems don't support this feature, but I need a definite answer.
Thanks.

配置如下：
-A -t 10.157.131.231:80 -s rr
-a -t 10.157.131.231:80 -r 10.157.131.6:80 -w 100 -b
-P -t 10.157.131.231:80 -z 10.157.131.231

vip落在eth1上
inet 10.157.131.232/24 brd 10.157.131.255 scope global eth1
inet 10.157.131.231/32 scope global eth1

realserver如果是和vip同一个网段的 client访问vip不成功 并且lvs ping网关不通 网关arp解析不了

realserver和vip不在同一网段 一切正常

fullnat是不是做了特殊的事情？

我们部署了几台lvs集群，使用fullnat模式，其中有一台lvs的流量统计（ipvsadm --stats）会自动清零：每隔5分钟就清零了，而这几台机器上没有调用--zero来清零流量数据。请问可能是什么原因导致的？

lvs修改的是请求的mac地址。
为什么不是在tcp三次握手的时候，实现client到realserver的确认连接
这样流量就不需要走调度器了
解决了请求多大流量，调度器网卡的瓶颈？

上次听Velocity China 2014 演讲 好像不是v4都快release了吗？

有方法能更快速下线 rs 吗？LVS 使用 DR 模式代理请求到后端 nginx，LVS 对 nginx 有配置 HTTP_GET 方式的健康检查，主动更新 nginx 的健康检查页使 LVS 的检查失败（返回非 200 状态码），这时 LVS 会摘除这台 rs，但是这时存在问题：

1. 如果配置 inhibit_on_failure，新建联的请求不会再转发给这台 rs，但是以前已经建立的连接（可以通过 ipvsadm -Ln 查看 InActConn 的数量），还是会接收请求，导致摘除这个 rs 的过程非常久，1小时？
2. 如果不配置 inhibit_on_failure，LVS 会直接把 rs 从 ipvs 的虚拟服务中删除，导致 client 发过来的包不再被转发给这台 rs，导致 client 端出现大量报错

上面 2 点在线上环境都是不能接受，还有什么办法能平滑快速的下线 RS 吗？

之前有人问在dell r730服务器上编译2.6.32-220的内核启动时出现kernel panic的情况。这里介绍哥办法，迁移到358内核中，r730亲测可用https://jeffrycheng.com/2017/03/31/%E5%9C%A8R730%E4%B8%8A%E5%AE%89%E8%A3%85lvs-fullnat/

Hi,
our team have developed a recurring vulnerability detection tool. This tool mainly uses static analysis methods, and it has a high detection accuracy in our dataset. We have also received positive feedback from other projects before.
we have scanned your LVS and found some vulnerabilities, which were confirmed and fixed by linux do not get patched in this repo. Here are some details as follows:

1. inet_create, inet6_create and inet6_create functions from kernel/.pc/patches.taobao/lvs-toa-rs-export-symbols.patch/net/ipv4/af_inet.c, kernel/.pc/patches.taobao/lvs-toa-rs-export-symbols.patch/net/ipv6/af_inet6.c and kernel/net/ipv6/af_inet6.c respectively, which shares the similarity with CVE-2015-8543 and the patch is torvalds/linux@79462ad
2. pipe_iov_copy_from_user and pipe_iov_copy_to_user functions from kernel/fs/pipe.c , which shares the similarity with CVE-2015-1805 and the patch is torvalds/linux@637b58c
3. __mptctl_ioctl, mptctl_do_reset, mptctl_fw_download, mptctl_getiocinfo, mptctl_gettargetinfo, mptctl_readtest, mptctl_eventquery, mptctl_eventenable, mptctl_eventreport, mptctl_replace_fw, mptctl_mpt_command, mptctl_hp_hostinfo, mptctl_hp_targetinfo, compat_mptfwxfer_ioctl and compat_mpt_command functions from kernel/drivers/message/fusion/mptctl.c, which shares the similarity with CVE-2020-12652 and the patch is torvalds/linux@28d76df
4. sunkbd_interrupt function from kernel/net/ipv4/af_inet.c and kernel/drivers/input/keyboard/sunkbd.c, which shares the similarity with CVE-2020-25669 and the patch is torvalds/linux@77e70d3
5. vgacon_scroll function from kernel/drivers/video/console/vgacon.c, which shares the similarity with CVE-2020-28097 and the patch is torvalds/linux@973c096
6. notify_change function from kernel/fs/attr.c, which shares the similarity with CVE-2015-1350 and the patch is torvalds/linux@030b533
7. isdn_ppp_ioctl, slhc_init, and sl_alloc_bufs functions from kernel/drivers/isdn/i4l/isdn_ppp.c, kernel/drivers/net/slhc.c and kernel/drivers/net/slip.c respectively, which shares the similarity with CVE-2015-7799 and the patch is torvalds/linux@4ab42d7
8. register_disk and __nbd_ioctl functions from kernel/fs/partitions/check.c and kernel/drivers/block/nbd.c respectively, which shares the similarity with CVE-2013-2851 and the patch is torvalds/linux@ffc8b30
9. ext4_ext_split and ext4_ext_split from kernel/fs/ext4/extents.c and kernel/.pc/patches.taobao/ext4-free-allocated-and-pre-allocated-blocks-when-ch.patch/fs/ext4/extents.c respectively, which shares the similarity with CVE-2019-11833 and the patch is torvalds/linux@592acbf
10. snd_seq_client_enqueue_event, kernel_client_enqueue, snd_seq_fifo_event_in, snd_seq_cell_alloc and snd_seq_event_dup functions from kernel/sound/core/seq/seq_clientmgr.c, kernel/sound/core/seq/seq_fifo.c and kernel/sound/core/seq/seq_memory.c respectively, which shares the similarity with CVE-2018-1000004 and the patch is torvalds/linux@7bd8009
11. persistent_prepare_exception and read_exceptions from kernel/drivers/md/dm-snap-persistent.c which shares the similarity to CVE-2013-4299 and the patch is torvalds/linux@e9c6a18
12. ext4_read_inode_bitmap and ext4_read_block_bitmap functions from kernel/fs/ext4/ialloc.c and kernel/fs/ext4/balloc.c respectively, which shares the similarity with CVE-2018-1093 and the patch is torvalds/linux@7dac4a1
13. ext4_mb_add_groupinfo, ext4_mb_add_groupinfo and ext4_mb_add_groupinfo functions from kernel/fs/ext4/mballoc.c, kernel/.pc/patches.taobao/ext4-use-dedicated-slab-caches-for-group_info-structures.patch/fs/ext4/mballoc.c and kernel/.pc/patches.taobao/ext4-Adding-error-check-after-calling-ext4_mb_regular_allocator.patch/fs/ext4/mballoc.c respectively, which shares the similarity with CVE-2018-10876 and the patch is torvalds/linux@8844618
14. __ext4_get_inode_loc, __ext4_get_inode_loc and __ext4_get_inode_loc functions from kernel/fs/ext4/inode.c, kernel/.pc/patches.taobao/ext4-Fix-possible-lost-inode-write-in-no-journal-mode.diff/fs/ext4/inode.c and kernel/.pc/patches.taobao/ext4-Fix-buffer-head-leaks-after-calls-to-ext4_get_inode_loc.diff/fs/ext4/inode.c which shares the similarity with CVE-2018-10882 and the patch is torvalds/linux@c37e9e0
15. mem_cgroup_move_charge_pte_range from the file kernel/mm/memcontrol.c which shares the similarity to CVE-2012-1179 and the patch is torvalds/linux@1a5a990
16. flush_ldt, init_new_context, alloc_ldt, copy_ldt and convert_ip_to_linear functions from kernel/arch/x86/kernel/ldt.c and kernel/arch/x86/kernel/step.c respectively, which shares the similarity with CVE-2015-5157 and the patch is torvalds/linux@37868fe
17. handle_rx_mergeable from kernel/drivers/vhost/net.c shares the similarity to CVE-2014-0077 and the patch is torvalds/linux@d8316f3
18. create_kthread from kernel/kernel/kthread.c, which shares the similarity with CVE-2012-4398 and the patch is torvalds/linux@786235e
19. cypress_open from kernel/drivers/usb/serial/cypress_m8.c, which shares the similarity with CVE-2016-3137 and the patch is torvalds/linux@c55aee1
20. gru_handle_user_call_os and gru_check_context_placement functions from kernel/drivers/misc/sgi-gru/grufault.c and kernel/drivers/misc/sgi-gru/grumain.c respectively, which shares the similarity with CVE-2022-3424 and the patch is torvalds/linux@643a16a
21. rose_start_idletimer from ernel/net/rose/rose_timer.c, which shares the similarity with CVE-2022-2318 and the patch is torvalds/linux@9cc02ed
22. ext4_xattr_ibody_find and ext3_xattr_ibody_find functions from kernel/fs/ext4/xattr.c and kernel/fs/ext3/xattr.c respectively, which shares the similarity with CVE-2023-2513 and the patch is torvalds/linux@67d7d8ad99be
23. fib6_rule_action function from kernel/net/ipv6/fib6_rules.c, which shares the similarity with CVE-2023-3022 and the patch is torvalds/linux@a65120bae4b7
    We have preliminarily verified the correctness of the above list through static analysis. Would you can help to check if this bug is true? If it's true, please try to fix it, or I'd like to open a PR for that if necessary. Thank you for your effort and patience!

http://kb.linuxvirtualserver.org/wiki/IPVS_FULLNAT_and_SYNPROXY

我们使用fullnat模式， 系统centos6.4， 服务器为R620,R720， 网卡GRO,LRO都已关闭， 使用的时候会频繁死机， 系统日志没有异常报错， dmesg也没有太异常， dmesg里的错误已经排除过， 依然会死机。还请帮忙看看是什么问题，谢谢了。

系统crash时的界面如下：

系统dmesg内容如下：
dmesg.txt

找不到找一个目录或文件

如题：TcpExt.ListenDrops 这个指标会出现drop

有如下两个问题需要请教，谢谢。

1. local_address_group 这个参数配置的地址池是所有 virtual_server 共用的么？还是需要每个virtual_server配置一个地址池？

2. ipvsadm -G -t xxxx:80 发现很多laddr 有 CONFLICTS ，请问 这个是地址池不够用，还是所有 virtual_server共用一个地址池的问题？

非常感谢。

Local environment:
ipvsadm v1.31 2019/12/24 (compiled with popt and IPVS v1.2.1)
5.10.0-20-amd64 #1 SMP Debian 5.10.158-2 (2022-12-13)
k8s kube-proxy with ipvs mode

on host above, exec "ipvsadm -L -t virtual_service_addr --stats", no any result returned

keepalived.conf如下：

local_address_group laddr_g1 {
XX.XX.XX.XX
}

virtual_server XX.XX.XX.XX XXXX {
delay_loop 30
lb_algo rr
lb_kind FNAT
protocol UDP
laddr_group_name laddr_g1

    real_server XX.XX.XX.XX XXXX {
            weight 1
    }

}

修改proc参数：
echo 0 > /proc/sys/net/ipv4/vs/defence_udp_drop

ethtool -k eth1

Features for eth1:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: off
large-receive-offload: off
ntuple-filters: off
receive-hashing: on

现象是RS上可以收到LVS转发过来的UDP包，但是checksum出错，RS的内核直接丢弃。

lvs fullnat才搭建起来，访问都正常。但一会之后出现日志：

lvs-master kernel: [ 1507.061626] IPVS: bind local address: no port available

访问不到rs了。
这个可能是什么原因呀？

新采购了一批机器， dell R730， 网卡Broadcom Corporation NetXtreme II BCM57800 1/10 Gigabit Ethernet， cpu intel e5-2630-v3, 编译后启动时显示kernel panic， lvs三个版本都试过， 都是同样的报错。 用原来的centos6.4内核启动后查看dmesg日志， 有部分内容如下：
UNSUPPORTED HARDWARE DEVICE: Intel CPU model
------------[ cut here ]------------
WARNING: at kernel/rh_taint.c:13 mark_hardware_unsupported+0x39/0x40() (Not tainted)
Hardware name: PowerEdge R730
Your hardware is unsupported. Please do not report bugs, panics, oopses, etc., on this hardware.
Modules linked in:
Pid: 0, comm: swapper Not tainted 2.6.32-358.el6.x86_64 #1
Call Trace:
[] ? warn_slowpath_common+0x87/0xc0
[] ? warn_slowpath_fmt_taint+0x3f/0x50
[] ? mark_hardware_unsupported+0x39/0x40
[] ? setup_arch+0xb57/0xb7a
[] ? printk+0x41/0x48
[] ? start_kernel+0xdc/0x430
[] ? x86_64_start_reservations+0x125/0x129
[] ? x86_64_start_kernel+0xfa/0x109
---[ end trace a7919e7f17c0a725 ]---

是不是内核太老了， 无法驱动新的硬件啊
lvs还是220的内核， 随着现在硬件更新越来越快， 马上lvs就不支持了啊

服务内部使用127.0.0.1 访问自己访问不通

编译环境为虚拟机， 配置如下
CPU Intel(R) Core(TM) i3-3120M CPU @ 2.50GHz
Mem 2G
gcc version 4.4.6 20110731 (Red Hat 4.4.6-3) (GCC)
2.6.32-220.el6.x86_64

yum -y install @development-tools fedora-packager kernel-devel rpm-build redhat-rpm-config asciidoc hmaccalc binutils-devel elfutils-libelf-devel newt-devel zlib-devel xmlto python-devel perl-ExtUtils-Embed rpmdev-setuptree

mkdir -p /root/rpmbuild/BUILD/kernel-2.6.32-220.23.1.el6/linux-2.6.32-220.23.1.el6.x86_64
下载 lvs_v2 kernel， 执行如下步骤
make -j8
make modules_install
make install
sh /root/rpmbuild/BUILD/kernel-2.6.32-220.23.1.el6/linux-2.6.32-220.23.1.el6.x86_64/arch/x86/boot/install.sh 2.6.32 arch/x86/boot/bzImage
System.map "/boot"
ERROR: modinfo: could not find module snd_intel8x0
ERROR: modinfo: could not find module snd_ac97_codec
ERROR: modinfo: could not find module ac97_bus
ERROR: modinfo: could not find module snd_seq
ERROR: modinfo: could not find module snd_seq_device
ERROR: modinfo: could not find module snd_pcm
ERROR: modinfo: could not find module snd_timer
ERROR: modinfo: could not find module snd
ERROR: modinfo: could not find module soundcore
ERROR: modinfo: could not find module snd_page_alloc
ERROR: modinfo: could not find module sd_mod
ERROR: modinfo: could not find module crc_t10dif

虚拟机、centos7 mini版，使用的是lvs v2，kernel和keepalived都编译安装成功了，但是编译 ipvsadm 时报错了

报错如下：
gcc -Wall -Wunused -Wstrict-prototypes -g -o ipvsadm ipvsadm.o config_stream.o dynamic_array.o ../keepalived/keepalived/libipvs-2.6/libipvs.a -lpopt -lnl
/usr/bin/ld: cannot find -lnl
collect2: error: ld returned 1 exit status
make: *** [ipvsadm] Error 1

if (IP_VS_FWD_METHOD(cp) != IP_VS_CONN_F_MASQ)
    return 0;

为什么只在nat下bind app？

fullnat下的ftp被动模式 不可用啊

lvs有个hash表，我调大了，也没发现LVS的主要功能有什么明显变化。
很好奇这个表的大小是在什么场景下需要调整的？

麻烦各路高手指点下，谢谢。

ipvsadm -P -t xxxxxx:80 -z 10.4.8.3
手动添加localaddress 没有报错
但是用ipvsadm -G 无法查到相应添加的信息,请问是什么问题呢？谢谢！

lvs 可以尝试嵌入 luajit吗? 这样的话用户的可定制更强？就好像nginx + lua 形成 openresty 框架？

I cloned the ali_lvs v3 beta and it seems the syn cookie check failed consistently, I turned on ipvs debug and added a few debug line as below, debug message:

Jan 9 13:26:04 alilvs kernel: IPVS: ip_vs_rr_schedule(): Scheduling...
Jan 9 13:26:04 alilvs kernel: IPVS: RR: server 192.168.3.2:80 activeconns 0 refcnt 1 weight 1
Jan 9 13:26:04 alilvs kernel: IPVS: Bind-dest TCP c:208.85.211.199:44855 v:192.168.1.169:80 d:192.168.3.2:80 fwd:F s:0 conn->flags:185 conn->refcnt:1 dest->refcnt:2
Jan 9 13:26:04 alilvs kernel: IPVS: Schedule fwd:F c:208.85.211.199:44855 v:192.168.1.169:80 d:192.168.3.2:80 conn->flags:1C5 conn->refcnt:2
Jan 9 13:26:04 alilvs kernel: IPVS: save_xmit_info, netdevice:eth0
Jan 9 13:26:04 alilvs kernel: in syn_proxy_synack_rcv, seq = 3831808964 ack_seq = 2885093891 SA- cp->is_synproxy = 0 cp->state = 3
Jan 9 13:26:04 alilvs kernel: IPVS: eth1(): netdevice:ip_vs_save_xmit_inside_info
Jan 9 13:26:04 alilvs kernel: IPVS: ip_vs_fast_response_xmit: send skb to client!
Jan 9 13:26:04 alilvs kernel: IPVS: save_xmit_info, netdevice:eth0
Jan 9 13:26:04 alilvs kernel: IPVS: ip_vs_fast_xmit: send skb to RS!
Jan 9 13:26:04 alilvs kernel: IPVS: Unbind-dest TCP c:208.85.211.199:44855 v:192.168.1.169:80 d:192.168.3.2:80 fwd:F s:1 conn->flags:5 conn->refcnt:1 dest->refcnt:2
Jan 9 13:26:04 alilvs kernel: IPVS: Unbind-laddr TCP c:208.85.211.199:44855 v:192.168.1.169:80 l:192.168.3.168:5002 d:192.168.3.2:80 fwd:F s:1 conn->flags:5 conn->refcnt:1 local->refcnt:2
Jan 9 13:26:04 alilvs kernel: syn_cookie check res=4294967295 <=======
Jan 9 13:26:04 alilvs kernel: syn_cookie check failed seq=3831808964 <=====
Jan 9 13:26:05 alilvs kernel: syn_cookie check res=4294967295
Jan 9 13:26:05 alilvs kernel: syn_cookie check failed seq=3831808964
Jan 9 13:26:07 alilvs kernel: syn_cookie check res=4294967295
Jan 9 13:26:07 alilvs kernel: syn_cookie check failed seq=3831808964

note the check_tcp_syn_cookie returns 4294967295 and matches if condition in syn_proxy_v4_cookie_check():

    if(res == (__u32)-1) /* count is invalid, jiffies' >> jiffies */
            goto out;

I can reproduce the issue consistently. please let me know what other information I can provide to resolve this issue.

[root@alilvs kernel]# git diff net/netfilter/ipvs/ip_vs_synproxy.c
diff --git a/kernel/net/netfilter/ipvs/ip_vs_synproxy.c b/kernel/net/netfilter/ipvs/ip_vs_synproxy.c
index 3f15ce3..d3796af 100644
--- a/kernel/net/netfilter/ipvs/ip_vs_synproxy.c
+++ b/kernel/net/netfilter/ipvs/ip_vs_synproxy.c
@@ -236,10 +236,15 @@ static int syn_proxy_v4_cookie_check(struct sk_buff *skb, __u32 cookie,
jiffies / (HZ * 60),
COUNTER_TRIES);

•   IP_VS_DBG(6, "syn_cookie check res=%u\n", res);
   if(res == (__u32)-1) /* count is invalid, jiffies' >> jiffies */
           goto out;
  

•   IP_VS_DBG(6, "syn_cookie check res=%u\n", res);
  

  • mssind = (res & IP_VS_SYNPROXY_MSS_MASK) >> IP_VS_SYNPROXY_MSS_BITS;

•   IP_VS_DBG(6, "syn_cookie check mssind=%u\n", mssind);
  

•   IP_VS_DBG(6, "syn_cookie check NUM_MSS=%lu\n", NUM_MSS);
  
   memset(opt, 0, sizeof(struct ip_vs_synproxy_opt));
   if ((mssind < NUM_MSS) && ((res & IP_VS_SYNPROXY_OTHER_MASK) == 0)) {
  

  @@ -250,11 +255,16 @@ static int syn_proxy_v4_cookie_check(struct sk_buff *skb,
  IP_VS_SYNPROXY_TSOK_BIT;
  opt->snd_wscale = (res & IP_VS_SYNPROXY_SND_WSCALE_MASK) >>
  IP_VS_SYNPROXY_SND_WSCALE_BITS;

  •           IP_VS_DBG(6, "syn_cookie check snd_wscale=%u\n", opt->snd_wscale
           if (opt->snd_wscale > 0 &&
    

  •                opt->snd_wscale <= IP_VS_SYNPROXY_WSCALE_MAX)
    

  •                opt->snd_wscale <= IP_VS_SYNPROXY_WSCALE_MAX) {
                   opt->wscale_ok = 1;
    

  •            else if (opt->snd_wscale == 0)
    

  •                   IP_VS_DBG(6, "syn_cookie check wscale_ok=%u\n", opt->wsc
    

  •           }
    

  •            else if (opt->snd_wscale == 0) {
                   opt->wscale_ok = 0;
    

  •                   IP_VS_DBG(6, "syn_cookie check wscale_ok=%u\n", opt->wsc
    

  •           }
           else
                   goto out;
    

client ip: 3.3.3.12
VIP : 3.3.3.9
laddr: 3.3.3.10
rs: 3.3.3.13
在客户端上抓包和后端RS同时抓包发现，当三次握手建立之后，客户端过来一个数据请求包，LVS就把这个链接RESET掉了，后端RS稍微有点不一样，LVS把客户端的数据请求包转发给了RS，RS也回了一个ACK给LVS，但是LVS在收到这个ACK之后就回了一个RESET给RS，请教一下这个大概会是什么导致的，另外，源代码中的哪个文件是处理这种异常链接的，我想想看看源码，LVS在什么时候会发这种RESET包，谢谢了

你好，我们最近在实践fullnat的过程中，发现一个问题。后台服务器是nginx机器都安装好了toa模块，通过nginx的日志我们发现后台服务器有千分之几的概率无法获取到真实客户端ip地址，拿到的是lvs的本地ip。 其他绝大多数情况下是可以拿到客户端真实ip地址的。这个不知道你们有没有遇到过？如果有遇到过请问一下有没有什么解决方法？多谢

Hi

后端RS为Java程序，无法通过TOA获取源地址，获取到是LVS的地址。

我现在通过ipvsadm来进行当前规则的导入与导出时碰到了问题，操作如下：

[root@lvs keepalived]# ipvsadm -l
IP Virtual Server version 1.2.1 (size=4194304)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  10.10.11.77:http rr
  -> 10.10.11.66:http             FullNat 100    0          0
[root@lvs ~]# ipvsadm -S
-A -t 10.10.11.77:http -s rr
-a -t 10.10.11.77:http -r 10.10.11.66:http (null) -w 100
[root@lvs ~]# ipvsadm -S > /tmp/conf
[root@lvs ~]# cat /tmp/conf
-A -t 10.10.11.77:http -s rr
-a -t 10.10.11.77:http -r 10.10.11.66:http (null) -w 100
[root@lvs ~]# ipvsadm -R < /tmp/conf
Service already exists
unexpected argument (null)

这个是不是操作不对引起的？

建了一个Q群便于大家对LVS相关技术交流 群号：545605087

I haven't got v3 beta release working so far, the syncookie issue disappeared, but it always seems that LVS failed to pass the response from server to client, the debugging log as below with my added syncookie debug noise:

Jan 10 20:43:46 alilvs kernel: [ 6379.609084] device eth0 entered promiscuous mode
Jan 10 20:43:56 alilvs kernel: [ 6389.510018] device eth1 entered promiscuous mode
Jan 10 20:44:02 alilvs kernel: [ 6395.506678] syn_cookie check cookie=81872209
Jan 10 20:44:02 alilvs kernel: [ 6395.506681] syn_cookie check vs syn seq=2095846056
Jan 10 20:44:02 alilvs kernel: [ 6395.506684] syn_cookie check count=71684
Jan 10 20:44:02 alilvs kernel: [ 6395.506686] syn_cookie check diff=0
Jan 10 20:44:02 alilvs kernel: [ 6395.506687] syn_cookie check excuted second
hash
Jan 10 20:44:02 alilvs kernel: [ 6395.506690] syn_cookie check res=2125824
Jan 10 20:44:02 alilvs kernel: [ 6395.506692] syn_cookie check mssind=7
Jan 10 20:44:02 alilvs kernel: [ 6395.506694] syn_cookie check NUM_MSS=10
Jan 10 20:44:02 alilvs kernel: [ 6395.506697] IPVS: ip_vs_rr_schedule(): Scheduling...
Jan 10 20:44:02 alilvs kernel: [ 6395.506701] IPVS: RR: server 192.168.3.3:80 activeconns 0 refcnt 1 weight 1
Jan 10 20:44:02 alilvs kernel: [ 6395.506712] IPVS: Bind-dest TCP c:192.168.1.7:43826 v:192.168.1.169:80 d:192.168.3.3:80 fwd:F s:0 conn->flags:185 conn->refcnt:1 dest->refcnt:2
Jan 10 20:44:02 alilvs kernel: [ 6395.506719] IPVS: Schedule fwd:F c:192.168.1.7:43826 v:192.168.1.169:80 d:192.168.3.3:80 conn->flags:81C5 conn->refcnt:2
Jan 10 20:44:02 alilvs kernel: [ 6395.506726] syn_proxy_send_rs_syn netdevice:eth0
Jan 10 20:44:02 alilvs kernel: [ 6395.506729] IPVS: save_xmit_info, skb->dev is NULL.
Jan 10 20:44:02 alilvs kernel: [ 6395.507263] in syn_proxy_synack_rcv, seq = 1230729923 ack_seq = 1294869472 SA- cp->is_synproxy = 32768 cp->state = 2
Jan 10 20:44:02 alilvs kernel: [ 6395.507267] synproxy_save_fast_xmit netdevice:eth1
Jan 10 20:44:02 alilvs kernel: [ 6395.507270] IPVS: save_xmit_info, netdevice:eth0
Jan 10 20:44:02 alilvs kernel: [ 6395.507273] tcp_dnat_handler: tcph->ack_seq 1312875283 => 1230729924, delta = 82145359
Jan 10 20:44:02 alilvs kernel: [ 6395.507276] IPVS: ip_vs_fast_xmit: send skb to RS!
Jan 10 20:44:02 alilvs kernel: [ 6395.507284] IPVS: save_xmit_info, netdevice:eth0
Jan 10 20:44:02 alilvs kernel: [ 6395.507287] tcp_dnat_handler: tcph->ack_seq 1312875283 => 1230729924, delta = 82145359
Jan 10 20:44:02 alilvs kernel: [ 6395.507289] IPVS: ip_vs_fast_xmit: send skb to RS!
Jan 10 20:44:02 alilvs kernel: [ 6395.507718] in syn_proxy_synack_rcv, seq = 1230729924 ack_seq = 1294869637 -A- cp->is_synproxy = 32768 cp->state = 1
Jan 10 20:44:02 alilvs kernel: [ 6395.507722] IPVS: eth1(): netdevice:ip_vs_save_xmit_inside_info
Jan 10 20:44:02 alilvs kernel: [ 6395.507726] tcp_snat_handler: tcph->seq 1230729924 => 1312875283, delta = 82145359
Jan 10 20:44:02 alilvs kernel: [ 6395.507729] IPVS: ip_vs_fast_response_xmit: send skb to client!
Jan 10 20:44:02 alilvs kernel: [ 6395.508013] IPVS: Unbind-dest TCP c:192.168.1.7:43826 v:192.168.1.169:80 d:192.168.3.3:80 fwd:F s:1 conn->flags:8005 conn->refcnt:1 dest->refcnt:2
Jan 10 20:44:02 alilvs kernel: [ 6395.508021] IPVS: Unbind-laddr TCP c:192.168.1.7:43826 v:192.168.1.169:80 l:192.168.3.168:5015 d:192.168.3.3:80 fwd:F s:1 conn->flags:8005 conn->refcnt:1 local->refcnt:2

I initially thought this might be caused by the ip_vs_fast_response_xmit in v3 release, but even disabling fast_response_xmit has no effect