On Mon, May 27, 2019 at 12:52:24PM +0530, [email protected] wrote: > If suppose the virtual_ip is configured to 10.0.0.10 on a virtual logical > port 'sw0-vip' > and the virtual_parents are set to - [sw0-p1, sw0-p2] then below logical > flows are added in the > lsp_in_arp_rsp logical switch pipeline > > - table=11(ls_in_arp_rsp), priority=100, > match=(inport == "sw0-p1" && ((arp.op == 1 && arp.spa == 10.0.0.10 && > arp.tpa == 10.0.0.10) || > (arp.op == 2 && arp.spa == 10.0.0.10))), > action=(bind_vport("sw0-vip", inport); next;) > - table=11(ls_in_arp_rsp), priority=100, > match=(inport == "sw0-p2" && ((arp.op == 1 && arp.spa == 10.0.0.10 && > arp.tpa == 10.0.0.10) || > (arp.op == 2 && arp.spa == 10.0.0.10))), > action=(bind_vport("sw0-vip", inport); next;) > > The action bind_vport will claim the logical port - sw0-vip on the chassis > where this action > is executed. Since the port - sw0-vip is claimed by a chassis, the > dnat_and_snat rule for > the VIP will be handled by the compute node.
The behavior here is a little bit different from what I ordinarily expect in OVN. Usually, the flow table that ovn-northd outputs depends only on the logical network topology and configuration. With this change, the flow table also depends on state, and ovn-northd needs to update it if that state changes. A design that I would perceive as more in the spirit of the current design would be one that always puts bind_vport on all of the chassis. That would require some work in ovn-controller so that it doesn't process a continuous stream of packets in the common case, but it would fit the current design better. Let me know if I misunderstand. Thanks, Ben. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
