Hello, On Thu, 26 Oct 2017, Ye Yin wrote: > Hi, Julian, > > We have test and confirmed successful about your suggestion. Thanks very much. Very good, thanks! I just acked it. Not sure who will get it, DaveM (net tree) or Simon (ipvs tree). > And I have submited a patch , please see > https://www.mail-archive.com/netdev@xxxxxxxxxxxxxxx/msg196160.html > > Regards, > Ye > > On Thu, Oct 26, 2017 at 3:01 AM, Julian Anastasov <ja@xxxxxx> wrote: > > > > Hello, > > > > On Wed, 25 Oct 2017, Ye Yin wrote: > > > >> Hi, all, > >> > >> We run ipvs at host and container in the same host at the same time, > >> and ipvs at host will transport network traffic to ipvs in the > >> container. Then some problem happended to us, the detail is as > >> follows: > >> > >> > >> ________________ _____________ > >> | ___|___ |container1 | > >> | host bridge |_vethA_|----|192.168.1.232 | > >> |192.168.1.193/26 | |____________| > >> | ___|___ _____________ > >> | |_vethB_|----|container2 | > >> |________________| |192.168.1.233 | > >> |_____________| > >> > >> container1 and container2 connected each other by bridge on the host, > >> which is the gateway of the two containers. Run ipvs on the host with > >> VIP 172.17.169.208. > >> > >> host: > >> $ ipvsadm -l -n > >> IP Virtual Server version 1.2.1 (size=4096) > >> Prot LocalAddress:Port Scheduler Flags > >> -> RemoteAddress:Port Forward Weight ActiveConn InActConn > >> TCP 172.17.169.208:80 rr > >> -> 192.168.1.233:80 Masq 1 0 0 > >> > >> container2: > >> $ ipvsadm -l -n > >> IP Virtual Server version 1.2.1 (size=4096) > >> Prot LocalAddress:Port Scheduler Flags > >> -> RemoteAddress:Port Forward Weight ActiveConn InActConn > >> TCP 192.168.1.233:80 rr > >> -> 14.17.xx.yyy:80 Masq 0 0 0 > >> > >> telnet from container1 to container2: > >> > >> access by ipvs at host will failed: > >> > >> $ telnet 172.17.169.208 80 > >> Trying 172.17.169.208... > >> telnet: connect to address 172.17.169.208: Connection refused > >> > >> direct access ipvs in container will success: > >> $ telnet 192.168.1.233 80 > >> Trying 192.168.1.233... > >> Connected to 192.168.1.233. > >> Escape character is '^]'. > >> ^] > >> telnet quit > >> Connection closed. > >> > >> > >> I think it's the ipvs_property flag make ipvs in container return > >> NF_ACCEPT for network traffic, which make traffic go up to tcp layer. > >> Please see ip_vs_in. > >> > >> We should clear this flag when SKB's netns has changed, Any idea? > > > > Good idea. Are you able to test after adding such line to > > net/core/skbuff.c:skb_scrub_packet()?: > > > > skb->ipvs_property = 0; > > > > Just after nf_reset_trace(skb); > > > > On success we should provide a patch instead that adds > > some ipvs_property_reset(skb) func in include/linux/skbuff.h that > > depends on the IS_ENABLED(CONFIG_IP_VS), just like it is done > > for nf_reset(). > > > > Regards > > > > -- > > Julian Anastasov <ja@xxxxxx> > Regards -- Julian Anastasov <ja@xxxxxx> -- To unsubscribe from this list: send the line "unsubscribe lvs-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
