alibaba / alibaba/LVS

v3 beta fail to pass server response skb to client

Open
#6 2 comments 0 reactions 0 assignees View on GitHub
Dominant language
C
Stars
2k
Forks
679
PR merge metrics
No merged PRs in 30d

Description

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

Contributor guide

No contributing guide indexed for this repository

Research direction

Start by reproducing the v3 beta failure and tracing the response path shown in the kernel log, especially ip_vs_fast_response_xmit and the SYNPROXY handlers. Compare behavior with fast_response_xmit disabled and determine why the server response does not reach the client. Done means the response is reliably forwarded to the client without breaking the connection.

Written by the indexing model from the issue text.

Assessment

Tech stack
c, linux
Domain
networking, operating-systems
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.