Arbitrary ethernet mask support is one step on the way to support for OpenFlow
1.1+. This patch set seeks to add this capability without breaking current
protocol support.
Signed-off-by: Joe Stringer <joe@wand.net.nz>
[blp@nicira.com made some updates, see
http://openvswitch.org/pipermail/dev/2012-May/017585.html]
Signed-off-by: Ben Pfaff <blp@nicira.com>
Commit e72e793 (Add ability to restrict flow mods and flow stats
requests to cookies.) modified cookie handling. Some of its behavior
was unintuitive and there was at least one bug (described below).
Commit f66b87d (DESIGN: Document uses for flow cookies.) attempted to
document a clean design for cookie handling. This commit updates the
DESIGN document and brings the implementation in line with it.
In commit e72e793, the code that handled processing OpenFlow flow
modification requests set the cookie mask to exact-match. This seems
reasonable for adding flows, but is not correct for matching, since
OpenFlow 1.0 doesn't support matching based on the cookie. This commit
changes to cookie mask to fully wildcarded, which is the correct
behavior for modifications and deletions. It doesn't cause any problems
for flow additions, since the mask is ignored for that operation.
Bug #9742
Reported-by: Luca Giraudo <lgiraudo@nicira.com>
Reported-by: Paul Ingram <paul@nicira.com>
Signed-off-by: Justin Pettit <jpettit@nicira.com>
Replaced all instances of Nicira Networks(, Inc) to Nicira, Inc.
Feature #10593
Signed-off-by: Raju Subramanian <rsubramanian@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
The implementation of the "learn" action now properly implements
specifications such as 0x20010db885a308d313198a2e03707348->NXM_NX_IPV6_DST
but the parser used in ovs-ofctl and elsewhere could not generate such
specifications. This commit adds that support.
Signed-off-by: Ben Pfaff <blp@nicira.com>
An upcoming commit will start referring to OpenFlow 1.1 actions, which are
renumbered relative to OpenFlow 1.0 actions, so this commit prepares by
changing all the existing uses of OFPAT_* to instead use OFPAT10_*.
This commit also introduces the OFPAT11_* constants.
Reviewed-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Ben Pfaff <blp@nicira.com>
The "learn" action can create matching return flows. If those have a long
timeout then it's a good idea to have a way to notice when in fact the
flows have terminated. This new action and matching "learn" feature
provides that way.
Feature #8603.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Until now, parts of a field have been dealt with in a fairly ad-hoc way.
struct mf_subfield and the supporting functions added by this commit make
their use more systematic.
Signed-off-by: Ben Pfaff <blp@nicira.com>
This commit switches from using the actual protocol values of error codes
internally in Open vSwitch, to using abstract values that are translated to
and from protocol values at message parsing and serialization time. I
believe that this makes the code easier to read and to write.
This is also one step along the way toward OpenFlow 1.1 support because
OpenFlow 1.1 renumbered a bunch of error codes.
Signed-off-by: Ben Pfaff <blp@nicira.com>
learn_parse() and learn_check() are supposed to apply the same checks, but
they are implemented very differently. It seems best to have learn_parse()
actually call learn_check() just to be sure.
This would have caught the bug fixed in the previous commit, because
the tests actually contain instances of "learn" actions that trigger the
bug, but the tests only parsed the actions without ever doing anything
that checked them (like sending them to ovs-vswitchd over OpenFlow).
nxm_dst_check() requires a writable field. Since NX_LEARN_DST_MATCH only
matches on a field and doesn't write to a field, use nxm_src_check() for
that case instead.
Bug #7507.
Reported-by: Michael Mao <mmao@nicira.com>
There are a few loose ends here. First, learning actions cause too much
flow revalidation. Upcoming commits will fix that problem. The following
additional issues have not yet been addressed:
* Resource limits: nothing yet limits the maximum number of flows that
can be learned. It is possible to exhaust all system memory.
* Age reporting: there is no way to find out how soon a learned table
entry is due to be evicted.
To try this action out, here's a recipe for a very simple-minded MAC
learning switch. It uses a 10-second MAC expiration time to make it easier
to see what's going on:
ovs-vsctl del-controller br0
ovs-ofctl del-flows br0
ovs-ofctl add-flow br0 "table=0 actions=learn(table=1, hard_timeout=10, \
NXM_OF_VLAN_TCI[0..11], NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[], \
output:NXM_OF_IN_PORT[]), resubmit(,1)"
ovs-ofctl add-flow br0 "table=1 priority=0 actions=flood"
You can then dump the MAC learning table with:
ovs-ofctl dump-flows br0 table=1
