Hi Ben, On 21 August 2018 at 04:41, Ben Pfaff <b...@ovn.org> wrote:
> > Since the tutorial recommends ovs-sandbox, ports will always be down due > to > > the use of the netdev-dummy datapath which skips the linux network stack. > > This is fine though as we can use "ovs-appctl > netdev-dummy/set-admin-state > > up" > > to force the ports to come up and this will keep faucet happy. > > Hmm. I wonder whether there should be a different default for dummy > ports. I don't know a good reason to force users to "up" them by hand. > Do you have a preference? > I think the right thing to do for netdev_dummy is to default to "up" on dummy ports and the user can admin them down with the ovs-appctl command if they want. > > I am still seeing some issues where even when the ports are up the > > ofproto/trace -generate commands don't seem to be triggering packet_ins > > towards faucet so learning isn't happening. > > Do you have an example? I'd be pleased to investigate. > I finally tracked this down to this commit: https://github.com/openvswitch/ovs/commit/d39ec23de38464ee35b3098b9f6c5f06d5191015 So I think if we send to controller and pass the packet along the OpenFlow pipeline OVS will optimise away the send to controller (slow path) action. I see there is a "debug_slow" action that can be used to restore the old behaviour but this seems a little icky for us to implement in faucet. I also note someone already reported this issue here: https://github.com/openvswitch/ovs-issues/issues/145 Brad
_______________________________________________ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss