[ovs-discuss] [PATCH] ofproto/ofproto-dpif.c don't forward ofp_port == ctx->flow.in_port

Nicholas Bastin nick.bastin at gmail.com
Wed Feb 8 06:46:49 UTC 2012

On Wed, Feb 8, 2012 at 01:29, Ethan Jackson <ethan at nicira.com> wrote:
> We already do these checks in ofproto-dpif at the callers of
> compose_output_action() see the xlate_output_action__() function.  The
> issue you're running into is that we skip this check for and explicit
> OFPP_LOCAL output.  I'm not sure if this is an oversight or by design,
> someone more familiar with the specification will have to chime in.

I could believe that it was by design for OFPP_LOCAL in OVS, but it's
hard to read the spec in any way other than that it is forbidden.
Like many things about the 1.0 spec there's a certain lack of explicit
clarity, and the only mention is really in the C structure comments:

Pg. 18:

OFPP_IN_PORT	= 0xfff8,
     /* Send the packet out the input port. This virtual port must be
explicitly used in order to send back out of the input port */

(Pg. 6 describes IN_PORT without restating the second sentence above)

I don't see a lot of latitude there for making exceptions.  That being
said, if there wasn't a spec (or one were inclined to argue that the
comments in the struct figures weren't binding) I could live with
either forwarding back out the in_port when explicitly stated (but not
for things like OFPP_FLOOD or ALL, of course), or rejecting the
flowmod with BAD_ACTION, but accepting the flowmod and dropping the
packet seems very much like the wrong thing to do.


More information about the discuss mailing list