The OpenFlow 1.0 specification says:
Emergency flow mod messages must have timeout values set to zero.
Otherwise, the switch must refuse the addition and respond with an
ofp_error_msg with OFPET_FLOW_MOD_FAILED type and
OFPFMFC_BAD_EMERG_TIMEOUT code.
but Open vSwitch reported OFPFMFC_TABLE_FULL in this case. This commit
fixes the problem.
Fixes detailed_contr_sw_messages.EmerFlowTimeout failure in OFTest.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Kyle Mestery <kmestery@cisco.com>
The OFPERR_* naming scheme is confusing, because it mixes categories with
specific errors. Categories can't be encoded for sending to controllers,
so this is a problem. This commit fixes up the cases where categories
were used as errors, replacing them by real errors types.
Signed-off-by: Jarno Rajahalme <jarno.rajahalme@nsn.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Moved remaining common definitions from openflow-1.0.h to
openflow-common.h and renamed 1.0 specific definitions with
the "10" infix. Added hstamp rules for new headers, fixed
non-ASCII characters in openflow-1.3.h, Commented out
trailing zero-length data members.
Signed-off-by: Jarno Rajahalme <jarno.rajahalme@nsn.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
The values of enum ofputil_protocol have meanings that overlap with
OpenFlow version numbers. These new functions provide ways to figure out
these overlaps.
These functions will be used for the first time in an upcoming commit.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Simon Horman <horms@verge.net.au>
To my mind, it makes sense, when a user requests OXM as the flow format,
to allow any protocol based on the OXM flow format to be used. Until this
commit, however, "OXM" was specifically OpenFlow 1.2, and "OpenFlow13" was
required to request OXM on OpenFlow 1.3.
This doesn't affect the behavior of any released version of Open vSwitch.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Simon Horman <horms@verge.net.au>
Initial OpenFlow 1.3 support with new include/openflow/openflow-1.3.h.
Most of the messages that differ from 1.2 are implemented. OFPT_SET_ASYNC
is implemented via NX_SET_ASYNC_CONFIG, other new message types are yet to
be implemented. Stats replies that add duration fields are implemented at
encode/decode level only. Test cases for implemented features are included.
Remaining FIXME:s should not cause runtime aborts. Make check comes out
clean.
Signed-off-by: Jarno Rajahalme <jarno.rajahalme@nsn.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Add OFPP_ANY to include/openflow/openflow-1.1.h, and allow it as a port in
queue stats request. Make ovs_ofctl use OFPP_ANY instead of OFPP_ALL for queue
stats requests on OF 1.1+.
This patch changes "none" ports print out. "none" is still accepted on input
for backwards compatibility, but it prints out as "ANY". To make this less
confusing, I changed the test cases to use "controller" or "any" instead of
"none". The test case that tests for both "none" and "controller" still tests
for them.
Signed-off-by: Jarno Rajahalme <jarno.rajahalme@nsn.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
This patch adds support for skb mark matching and set action.
Acked-by: Jesse Gross <jesse@nicira.com>
Signed-off-by: Ansis Atteka <aatteka@nicira.com>
Allow only OpenFlow 12 as a flow dump protocol.
The implementation of set_protocol_for_flow_dump ensures that
this will only be selected if an OpenFlow12 connection has
been negotiated.
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Versions may be configured using the protocols column of
the bridge table. The protocols column is a set which accepts zero
or more of the values: 'OpenFlow10' and 'OpenFlow12'.
If the protocols column is empty, then OpenFlow10 is used.
This default is consistent with the behaviour of ovs-vswtichd
prior to this patch.
Signed-off-by: Simon Horman <horms@verge.net.au>
[blp@nicira.com adjusted comments and documentation]
Signed-off-by: Ben Pfaff <blp@nicira.com>
This was meant to splice OXM support into OpenFlow 1.0, in place of NXM,
but I no longer see any value in it.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Reviewed-by: Simon Horman <horms@verge.net.au>
Soon, it's not going to be possible to switch between every possible
protocol on an established OpenFlow connection, yet
ofputil_encode_set_protocol() didn't have a documented way to report such
a problem. This commit adds a means for reporting and makes its callers
able to handle the problem.
Also, initially make ofputil_encode_set_protocol() fail when the current
and requested protocols are for different OpenFlow versions.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Reviewed-by: Simon Horman <horms@verge.net.au>
It wasn't clear to me, at least, whether an OFPUTIL_P_* constant
indicated an OpenFlow version and a flow format or just a flow format.
After some reflection, I think it's more useful if it indicates both,
because otherwise it might be necessary to pass both an OpenFlow version
and an OFPUTIL_P_* constant in some contexts, but this way only the latter
is needed.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Reviewed-by: Simon Horman <horms@verge.net.au>
This doesn't fix a visible bug, because code to send OpenFlow messages
updates the length itself, but it still seems like the right thing to do.
Signed-off-by: Ben Pfaff <blp@nicira.com>
This code has, until now, parsed and accepted invalid bitmaps. It seems
better to simply ignore them, leaving the original set of allowed versions
from the version field in the ofp_header.
Signed-off-by: Ben Pfaff <blp@nicira.com>
The length of the hello version bitmap is measured in bytes
so the return value of sizeof is sufficient. Dividing
this by CHAR_BIT (=8) seems to be an artifact of reworking
a previous version of this code.
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Allow encoding and decoding of version bitmap in hello messages
as specified in Open Flow 1.3.1.
Signed-off-by: Simon Horman <horms@verge.net.au>
[blp@nicira.com simplified and generalized decode/encode functions]
Signed-off-by: Ben Pfaff <blp@nicira.com>
The bitmap is simple a uint32_t, allowing for versions up until
wire-protocol number 31.
Bit offsets correspond to ofp_version numbers which in turn
correspond to wire-protocol numbers for Open Flow versions..
E.g. (1 << OFP10_VERSION) is the mask for Open Flow 1.1.
If the bit for a version is set then it is allowed, otherwise it is
disallowed.
This is in preparation for allowing the range of allowed OpenFlow
versions to be configured.
Signed-off-by: Simon Horman <horms@verge.net.au>
[blp@nicira.com simplified some functions to constants, and rewrote
a few functions in terms of utility bitwise functions]
Signed-off-by: Ben Pfaff <blp@nicira.com>
When a link is down, or when a link has no speed because it is not a
physical interface, Open vSwitch previously reported that its rate is 100
Mbps as a default. This is counterintuitive, however, so this commit
changes Open vSwitch behavior to report 0 Mbps when a link is down or its
speed is otherwise unavailable.
Bug #13388.
Reported-by: Hiroshi Tanaka <htanaka@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
With this commit, OVS will match the data in the RARP packets having
ethertype 0x8035, in the same way as the data in the ARP packets.
Signed-off-by: Mehak Mahajan <mmahajan@nicira.com>
Commit c6100d92142b (ovs-ofctl: Accept port keywords, OF1.1 port numbers,
reject port number 0.) intentionally prohibited using port 0, which is not
a valid OpenFlow port number, in OpenFlow commands and actions. However,
since then we have discovered that the NVP controller uses port 0 in
"resubmit" actions and hence in flow matches as well. This seems like a
valid enough use case; after all, the port number in a resubmit action is
really just an arbitrary number that need not (and preferably does not)
refer to an actual OpenFlow port. Therefore, this commit restores the
ability to use port 0.
(Only functions that parse OpenFlow commands and actions from strings, not
those that interpret binary OpenFlow coming in on OpenFlow connections,
were affected by this prohibition, so this only comes up in corner cases
anyhow.)
Reported-by: Gurucharan Shetty <gshetty@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
When I wrote this function I didn't think that port 0 was important (it's
not a valid OpenFlow port number) so I used a return value of 0 to indicate
an error. However, my assumption turns out to be wrong, so this commit
changes the interface to use the return value only for error reporting
and store the parsed port number into a pointer passed in as a parameter.
This commit doesn't change the behavior of ofputil_port_from_string().
Signed-off-by: Ben Pfaff <blp@nicira.com>
When the command of a Flow Mod messages is ADD the cookie should be set as
fm->new_cookie, this is the new cookie value to be set. Otherwise it
should be set as fm->cookie, internally this is the cookie value to match.
Also remove 'XXX' marker from the matching code in the decoder.
I am now comfortable with the implementation.
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Ben Pfaff <blp@nicira.com>
This allows for encoding and decoding Open Flow 1.1 and 1.2 Queue Stats
Request and Reply messages.
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Ben Pfaff <blp@nicira.com>
This function changed a few times before it was merged,
unfortunately at some point the comment wasn't kept in sync
with the changes.
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Ben Pfaff <blp@nicira.com>
The return type of both ofputil_decode_flow_removed() and nx_pull_match()
is enum ofperr so it makes sense for error be of that type too.
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Ben Pfaff <blp@nicira.com>
This allows for encoding and decoding Open Flow 1.1 and 1.2 Port Stats
Request and Reply message
Signed-off-by: Simon Horman <horms@verge.net.au>
[blp@nicira.com added ofputil_count_port_stas(), simplified
interface of ofputil_decode_port_stats(), style changes]
Signed-off-by: Ben Pfaff <blp@nicira.com>
Soon the kernel will begin supplying the information about the outer
IP header for tunneled packets and userspace will need to be able to
track it as part of the flow. For the time being this is only used
internally by OVS and not exposed outwards to OpenFlow. As a result,
this threads the information throughout userspace but simply stores
the existing tun_id in it.
Signed-off-by: Jesse Gross <jesse@nicira.com>
Previously this field was ignored on decode and
set to zero on encode
Signed-off-by: Simon Horman <horms@verge.net.au>
[blp@nicira.com changed "missing" value, removed OFPTT_ALL]
Signed-off-by: Ben Pfaff <blp@nicira.com>
This is a necessary step toward supporting full 32-bit OF1.1+ port numbers
in a later version of OVS.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Ethan Jackson <ethan@nicira.com>
Previously there was no need for this, because all implemented standard
OpenFlow actions had a fixed length, but the OF1.2 "set-field" action (soon
to be implemented) is variable length.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Reviewed-by: Simon Horman <horms@verge.net.au>
The numbering of OpenFlow 1.0 actions overlaps with the numbering
of OpenFlow 1.1+ actions, so the two sets of actions have to be
distinguished for input and output. But OpenFlow 1.1 and 1.2
actions are numbered to avoid this problem, so there is no need
to distinguish them in the same way. Therefore, this commit
prepares to treat them together.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Reviewed-by: Simon Horman <horms@verge.net.au>
OpenFlow 1.0 has special reserved ports in the range 0xfff8 to 0xffff.
OpenFlow 1.1 and later has the same ports in the range 0xfffffff8 to
0xffffffff and allows the OF1.0 range to be used for ordinary ("physical")
switch ports. This means that, naively, the meaning of a port number in
the range 0xfff8 to 0xffff given on the ovs-ofctl command line depends on
the protocol in use. This commit implements something a little smarter:
- Accept keyword names (e.g. LOCAL) for special reserved ports
everywhere that such a port can plausibly be used (previously they
were only accepted in some places).
- Translate 0xfff8...0xffff to 0xfffffff8...0xffffffff for now, since
OF1.1+ isn't in widespread use and those particular ports aren't
likely to be in use in OF1.1+ anyway.
- Log warnings about those ports when they are specified by number, to
allow users to fix their invocations.
Also:
- Accept the OF1.1+ port numbers for these ports, without warning, for
compatibility with the upcoming OF1.1+ support.
- Stop accepting port number 0, which has never been a valid port
number in OpenFlow 1.0 and later. (This required fixing some tests
that inadvertently used this port number).
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Simon Horman <horms@verge.net.au>
[blp@nicira.com then made substantial changes that were then:]
Reviewed-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Ben Pfaff <blp@nicira.com>
* In the case of OpenFlow 1.2+ OFPERR_OFPBRC_BAD_PORT is defined
in the specification and seems to be the most appropriate error
to use when an invalid port is encountered in a Packet Out request.
* In the case of OpenFlow 1.0 and 1.1 no appropriate error message
seems to exist. Perhaps because an invalid port is not possible?
I'm unsure.
In any case, make use of a non-standard error code (1,514).
This was formerly known as OFPERR_NXBRC_BAD_IN_PORT but
has been rolled into OFPERR_NXBRC_BAD_IN_PORT to allow the
latter to be used without concern for the prevailing Open Flow version.
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Add necessary macros to ofp-util for OF12 support.
This is just a placeholder.
Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Ben Pfaff <blp@nicira.com>
OFPERR_NXFMFC_GROUPS_NOT_SUPPORTED is currently only used in paths which
are part of a non-NX extension portions of the Open Flow 1.1+
implementation.
After recent discussion it has been decided to attempt to only use
standardised, albeit lest-specify, errors unless errors arise from use of
an NX extension.
With the above in mind it seems appropriate to:
* Use OFPERR_OFPFMFC_UNKNOWN in place of OFPERR_NXFMFC_GROUPS_NOT_SUPPORTED.
* Remove OFPERR_NXFMFC_GROUPS_NOT_SUPPORTED as it is no longer used.
An unfortunate side-effect of this change is that the error for
the case in question is now less-specific.
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Ben Pfaff <blp@nicira.com>
