On Tue, Jan 31, 2017 at 2:49 PM, Ben Pfaff wrote:
>
> On Thu, Jan 05, 2017 at 12:33:51AM -0800, Han Zhou wrote:
> > On Wed, Jan 4, 2017 at 3:29 PM, Ben Pfaff wrote:
> > > However, I'm concerned about the general utility here. I usually
think
> > > of proxy ARP as being used for the kinds of appl
On Thu, Jan 05, 2017 at 12:33:51AM -0800, Han Zhou wrote:
> On Wed, Jan 4, 2017 at 3:29 PM, Ben Pfaff wrote:
> > However, I'm concerned about the general utility here. I usually think
> > of proxy ARP as being used for the kinds of applications you see in the
> > wikipedia on proxy ARP: https://e
Hi Ben,
I am aware of the ovn-k8s integration by Guru, but our approach is slightly
different. It is somehow customized to avoid the current scale limit of ovn
cluster, so Guru's work can't be directly used. But I believe it will be a
very good reference for us when replacing kubeproxy by DLB of o
On Mon, Jan 09, 2017 at 04:08:08PM -0800, Han Zhou wrote:
> 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
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
mailto:zhou...@gmail.com>> wrote:
Hi Bruce,
This feature is useful for me. I ha
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
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
On Wed, Jan 4, 2017 at 3:29 PM, Ben Pfaff wrote:
>
> [adding Bruce to leverage his knowledge of networking, if he's willing]
Thanks! It would be great to get some views from networking experts.
>
> It seems like the mechanics of this patch are mostly OK. There is at
> least one inconsistency in
[adding Bruce to leverage his knowledge of networking, if he's willing]
It seems like the mechanics of this patch are mostly OK. There is at
least one inconsistency in ovn-nb.xml, where it says in one place that
the new option is for all port types and in another that it's only for
ports with an
This patch support "arp_proxy" option for logical switch ports. If
a lsp with arp_proxy=true, all the arp request to known ipv4
addresses on the ls will be responded with the arp proxy lsp's MAC
address, except when the arp request come from the arp proxy lsp
itself.
Signed-off-by: Han Zhou
---
10 matches
Mail list logo