[ovs-dev] [patch_v3 1/2] ovn: Fix receive from vxlan inovn-controller.

[Darrell Ball]

On Tue, Jul 5, 2016 at 7:39 PM, Ryan Moats <rmoats at us.ibm.com> wrote:

> "dev" <dev-bounces at openvswitch.org> wrote on 06/26/2016 08:34:01 PM:
>
> > From: Darrell Ball <dlu998 at gmail.com>
> > To: dlu998 at gmail.com, dev at openvswitch.com
> > Date: 06/26/2016 08:34 PM
> > Subject: [ovs-dev] [patch_v3 1/2] ovn: Fix receive from vxlan in
> > ovn-controller.
> > Sent by: "dev" <dev-bounces at openvswitch.org>
> >
> > 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 <dlu998 at gmail.com>
> > ---
>
> It looks like the changes from this last weekend means the hunk of the
> patch for physical_run in physical.c doesn't apply cleanly...
>

Thanks; it was on my todo list.


>
> Ryan
>
>
>
>