On Thu, Feb 25, 2016 at 12:43 PM, Russell Bryant <russ...@ovn.org> wrote: > > > > On Thu, Feb 25, 2016 at 1:12 PM, Han Zhou <zhou...@gmail.com> wrote: >> >> Before this patch, inter-chassis communication between VIFs of same >> lswitch will always go through tunnel, which end up of modeling a >> single physical network with many lswitches and pairs of lports, and >> complexity in CMS like OpenStack neutron to manage the lswitches and >> lports. >> >> With this patch, inter-chassis communication can go through physical >> networks via localnet port with a 1:1 mapping between lswitches and >> physical networks. The pipeline becomes: >> >> Ingress -> Egress (local) -> Ingress (remote) -> Egress >> >> The original tunneling mechanism will still be used if there is no >> localnet port configured on the lswitch. >> >> Signed-off-by: Han Zhou <zhou...@gmail.com> >> Acked-by: Russell Bryant <russ...@ovn.org> > > > I think there may be another problem with this. > > We create flows for doing arp replies for all ports on a logical switch. Once we go to this model, if an entity external to OVN sends an arp request for an IP address assigned to a VM on a provider network, I believe *every* hypervisor is going to generate an arp response due to those flows. > > One way to resolve this would be to determine whether a logical switch has a localnet port before creating these logical flows. If a localnet port exists, add "inport != <the-localnet-port>" to the match for the arp reply flows. > > -- > Russell Bryant
This is a real problem! I will work on the arp reply flow change and come with v7. -- Best regards, Han _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
