Han, Thanks - that makes sense to me. I can’t claim that this is a hugely general feature, but your use case seems legit to me (with the caveat that I’m no k8s expert).
Bruce On Jan 9, 2017, at 4:08 PM, Han Zhou <zhou...@gmail.com<mailto:zhou...@gmail.com>> wrote: Hi Bruce, This feature is useful for me. I had the concern because the use case for me is intermediate. It is for k8s integration. In k8s there is a kubeproxy running on each host to do service-ip NATting, and I am using OVS (programmed by OVN) to connect host network namespace to containers (and also connection between containers on the same host). When an NATted end-point of a service-ip happen to be on the same host (and of course, same L2, since we use bridged mode), then the return traffic would be forwarded directly to the source without going through the kubeproxy. With this ARP-proxy patch, the interface to the host network namespace is specified as ARP proxy port, and traffic between containers will go through the host for NATting. This is an intermediate solution because a better way to do it is to utilize the load-balancing feature of OVN to replace kubeproxy completely, and the problem won't exist at all. It just takes more effort to integrate and we are not there yet. Hope this clarifies my use case. But I'd like to hear if this feature would useful in any other circumstances. Thanks, Han On Mon, Jan 9, 2017 at 2:57 PM, Bruce Davie <bda...@vmware.com<mailto:bda...@vmware.com>> wrote: > > Han, > Your comment gave me pause: > > I have similar concerns about how useful it is. > > Whereas the current proxy ARP function in OVN has a pretty clear motivation & > tightly defined use case (to avoid needless broadcast of ARP requests across > the overlay when the logical router’s IP and MAC are known) it seems like > even you don’t really have a clear use case in mind for this additional > functionality. Can you try to lay our more clearly why you think this is a > useful enough addition to OVN to warrant the extra complexity? > > Thanks > Bruce > _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
