[ovs-discuss] ovs-ofctl - learn - no way to provide actions=resubmit in the learnt rule
Farhad Sunavala
fsbiz at yahoo.com
Wed Jun 15 21:11:10 UTC 2016
>It's already possible to do what you want. Have the learned flows set a
>register to a distinctive value, such as 1, and match on that register
>after resubmitting to the table that contains the learned flows. > In the next table, ^^^^^^^^^^^^^^^^^^^^^
That brings me back to my original question.How do you go to the next table inside a learned flow ?The only actions available for a learned flow are load, store and output.
Regards,Farhad.
learn(argument[,argument]...)
This action adds or modifies a flow in an OpenFlow table,
similar to ovs-ofctl --strict mod-flows. The arguments
specify the flow's match fields, actions, and other prop‐
erties, as follows. At least one match criterion and one
action argument should ordinarily be specified.
idle_timeout=seconds
hard_timeout=seconds
priority=value
cookie=value
send_flow_rem
These arguments have the same meaning as in the
usual ovs-ofctl flow syntax.
fin_idle_timeout=seconds
fin_hard_timeout=seconds
Adds a fin_timeout action with the specified argu‐
ments to the new flow. This feature was added in
Open vSwitch 1.5.90.
table=number
The table in which the new flow should be
inserted. Specify a decimal number between 0 and
254. The default, if table is unspecified, is ta‐
ble 1.
delete_learned
This flag enables deletion of the learned flows
when the flow with the learn action is removed.
Specifically, when the last learn action with this
flag and particular table and cookie values is
removed, the switch deletes all of the flows in
the specified table with the specified cookie.
This flag was added in Open vSwitch 2.4.
field=value
field[start..end]=src[start..end]
field[start..end]
Adds a match criterion to the new flow.
The first form specifies that field must match the
literal value, e.g. dl_type=0x0800. All of the
fields and values for ovs-ofctl flow syntax are
available with their usual meanings.
The second form specifies that field[start..end]
in the new flow must match src[start..end] taken
from the flow currently being processed.
The third form is a shorthand for the second form.
It specifies that field[start..end] in the new
flow must match field[start..end] taken from the
flow currently being processed.
load:value->dst[start..end]
load:src[start..end]->dst[start..end]
Adds a load action to the new flow.
The first form loads the literal value into bits
start through end, inclusive, in field dst. Its
syntax is the same as the load action described
earlier in this section.
The second form loads src[start..end], a value
from the flow currently being processed, into bits
start through end, inclusive, in field dst.
output:field[start..end]
Add an output action to the new flow's actions,
that outputs to the OpenFlow port taken from
field[start..end], which must be an NXM field as
described above.
>if the register contains the value, resubmit to table 22,
>otherwise don't.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openvswitch.org/pipermail/ovs-discuss/attachments/20160615/9286c4e5/attachment-0002.html>
More information about the discuss
mailing list