On Sat, Jul 23, 2016 at 01:18:01PM -0700, Darrell Ball wrote: > This patch enables source node replication in OVN for receive from Vxlan > tunnels. OVN only supports source node replication mode. > > OVN only supports source_node replication and previously vtep interaction, > which used service node replication by default for > multicast/broadcast/unknown unicast traffic worked by happenstance. > Because of limited vxlan encapsulation metadata, received packets were > resubmitted to find the egress port(s). This is not correct for multicast, > broadcast and unknown unicast traffic as traffic will get resent on the tunnel > mesh. ovn-controller is changed not to send traffic received from vxlan > tunnels out the tunnel mesh again. Traffic received from vxlan tunnels is > now only sent locally as intended. > > To support keeping state for receipt from a vxlan tunnel a MFF logical > register is allocated for general scratchpad purposes and one bit is used for > receipt from vxlan context. > > As part of this change ovn-controller-vtep is hard-coded to set the > replication > mode of each logical switch to source node as OVN will only support source > node replication. > > Signed-off-by: Darrell Ball <dlu...@gmail.com>
This seems like a useful advance. Thank you. ovn-architecture(7) has a section titled "Architectural Physical Life Cycle of a Packet" that describes how table 32 on hypervisors works. Please update this to describe the special handling of packets that arrive from VXLAN tunnels. Please also update ovn-architecture(7) to mention the new flag bit. Yes, I know that you want to break this document apart but I want to treat that issue separately. Thanks, Ben. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
