Thanks, applied.

On Wed, Sep 11, 2013 at 11:11:17AM -0700, Jarno Rajahalme wrote:
> Acked-by: Jarno Rajahalme <jrajaha...@nicira.com>
> 
> On Sep 11, 2013, at 10:02 AM, Ben Pfaff <b...@nicira.com> wrote:
> 
> > Reported-by: Aws Auger <ovshel...@gmail.com>
> > Signed-off-by: Ben Pfaff <b...@nicira.com>
> > ---
> > FAQ |   50 ++++++++++++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 50 insertions(+)
> > 
> > diff --git a/FAQ b/FAQ
> > index 7181484..20a3e3b 100644
> > --- a/FAQ
> > +++ b/FAQ
> > @@ -1249,6 +1249,56 @@ A: An empty set of actions causes a packet to be 
> > dropped.  You can
> > 
> >        ovs-ofctl add-flow br0 priority=65535,actions=drop
> > 
> > +Q: I added a flow to send packets out the ingress port, like this:
> > +
> > +       ovs-ofctl add-flow br0 in_port=2,actions=2
> > +
> > +   but OVS drops the packets instead.
> > +
> > +A: Yes, OpenFlow requires a switch to ignore attempts to send a packet
> > +   out its ingress port.  The rationale is that dropping these packets
> > +   makes it harder to loop the network.  Sometimes this behavior can
> > +   even be convenient, e.g. it is often the desired behavior in a flow
> > +   that forwards a packet to several ports ("floods" the packet).
> > +
> > +   Sometimes one really needs to send a packet out its ingress port.
> > +   In this case, output to OFPP_IN_PORT, which in ovs-ofctl syntax is
> > +   expressed as just "in_port", e.g.:
> > +
> > +       ovs-ofctl add-flow br0 in_port=2,actions=in_port
> > +
> > +   This also works in some circumstances where the flow doesn't match
> > +   on the input port.  For example, if you know that your switch has
> > +   five ports numbered 2 through 6, then the following will send every
> > +   received packet out every port, even its ingress port:
> > +
> > +       ovs-ofctl add-flow br0 actions=2,3,4,5,6,in_port
> > +
> > +   or, equivalently:
> > +
> > +       ovs-ofctl add-flow br0 actions=all,in_port
> > +
> > +   Sometimes, in complicated flow tables with multiple levels of
> > +   "resubmit" actions, a flow needs to output to a particular port
> > +   that may or may not be the ingress port.  It's difficult to take
> > +   advantage of OFPP_IN_PORT in this situation.  To help, Open vSwitch
> > +   provides, as an OpenFlow extension, the ability to modify the
> > +   in_port field.  Whatever value is currently in the in_port field is
> > +   the port to which outputs will be dropped, as well as the
> > +   destination for OFPP_IN_PORT.  This means that the following will
> > +   reliably output to port 2 or to ports 2 through 6, respectively:
> > +
> > +       ovs-ofctl add-flow br0 in_port=2,actions=load:0->NXM_OF_IN_PORT[],2
> > +       ovs-ofctl add-flow br0 actions=load:0->NXM_OF_IN_PORT[],2,3,4,5,6
> > +
> > +   If the input port is important, then one may save and restore it on
> > +   the stack:
> > +
> > +        ovs-ofctl add-flow br0 actions=push:NXM_OF_IN_PORT[],\
> > +                                       load:0->NXM_OF_IN_PORT[],\
> > +                                       2,3,4,5,6,\
> > +                                       pop:NXM_OF_IN_PORT[]
> > +
> > 
> > Contact 
> > -------
> > -- 
> > 1.7.10.4
> > 
> > _______________________________________________
> > dev mailing list
> > dev@openvswitch.org
> > http://openvswitch.org/mailman/listinfo/dev
> 
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Reply via email to