An upcoming commit will introduce another member that has a length, and
it seems weird that bare 'len' would be one or the other.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Jarno Rajahalme <jarno@ovn.org>
It's not const in all cases so it doesn't entirely make sense to mark
it const here.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Jarno Rajahalme <jarno@ovn.org>
A number of times I've looked at code and thought that it would be easier
to understand if I could write an initializer instead of
ofpbuf_use_const(). This commit adds a function for that purpose and
adapts a lot of code to use it, in the places where I thought it made
the code better.
In theory this could improve code generation since the new function can
be inlined whereas ofpbuf_use_const() isn't. But I guess that's probably
insignificant; the intent of this change is code readability.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Jarno Rajahalme <jarno@ovn.org>
Until now, ofputil_decode_switch_features() has put the ports from the
switch features message into a separate ofpbuf supplied as an argument.
The natural desire for a caller is to just reuse an ofpbuf that it already
has, and that's what one of the callers did. This however has the
nonobvious effect of leaking the memory that the ofpbuf previously owned,
since it gets replaced by an OFPBUF_CONST-type ofpbuf.
This commit avoids the problem by changing the interface to pull the
header from an ofpbuf that the caller already has.
This fixes a leak in testcase 909 "ofproto-dpif - patch ports".
Found by valgrind.
Reported-by: William Tu <u9012063@gmail.com>
Reported-at: http://openvswitch.org/pipermail/dev/2016-January/064771.html
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Andy Zhou <azhou@ovn.org>
Packet-in messages have been a bit of a mess. First, their abstraction
in the form of struct ofputil_packet_in has some fields that are used
in a clear way for incoming and outgoing packet-ins, and others
(packet_len, total_len, buffer_id) have have confusing meanings or
usage pattern depending on their direction.
Second, it's very confusing how a packet-in has both a reason (OFPR_*)
and a miss type (OFPROTO_PACKET_IN_*) and how those add up to the
actual reason that is used "on the wire" for each OpenFlow version (and
even whether the packet-in is sent at all!).
Finally, there's all kind of low-level detail randomly scattered between
connmgr, ofproto-dpif-xlate, and ofp-util.
This commit attempts to clear up some of the confusion. It simplifies
the struct ofputil_packet_in abstraction by removing the members that
didn't have a clear and consistent meaning between incoming and outgoing
packet-ins. It gets rid of OFPROTO_PACKET_IN_*, instead adding a couple
of nonstandard OFPR_* reasons that add up to what OFPROTO_PACKET_IN_*
was meant to say (in what I hope is a clearer way). And it consolidates
the tricky parts into ofp-util, where I hope it will be easier to
understand all in one place.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Jarno Rajahalme <jarno@ovn.org>
It's actually harder to parse OF1.2/OF1.3 "packet-in" messages when
ofp13_packet_in is involved than when the code just realizes that
ofp13_packet_in = ofp12_packet_in + cookie.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Jarno Rajahalme <jarno@ovn.org>
This isn't used yet but it will be in future commits.
This also looks forward to supporting Open vSwitch extensions to OAM_*,
which will be coming up soon.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Jarno Rajahalme <jarno@ovn.org>
The OF1.0 through OF1.3 "set async config" set the whole configuration,
OF1.4+ only update parts of it piecemeal, but the decoding function always
set the whole configuration. This commit fixes the problem by changing the
interface to require the caller to provide an initial state. (It would
be possible to simply make it mutate existing state in-place, but that
interface seems a little more error-prone.)
Found by inspection.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Jarno Rajahalme <jarno@ovn.org>
The encoding and decoding of the OpenFlow and Open vSwitch async config
messages was, until now, a collection of disjoint code that had a lot of
redundancy. This commit changes it all to be driven using a single central
table.
This rewrite fixes a bug in the OF1.4+ version of the code, which until
now assumed that every TLV in an OF1.4+ asynchronous configuration message
was exactly 8 bytes long, and reported an error if any was a different
length. This invariant is true of all the standard TLVs already defined,
but it won't be true of any experimenter TLVs (and won't necessarily be
true of any new standard TLVs), so this commit changes it to be more
tolerant.
The OFPACPT_* constants are no longer useful (they are encoded directly
in the table and do not need to be anywhere else), so this removes them.
This commit also adds support for experimenter async config messages.
We don't have any yet but an upcoming commit will add one.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Jarno Rajahalme <jarno@ovn.org>
OpenFlow 1.0 through 1.3 have a message OFPT_QUEUE_GET_CONFIG_REQUEST and
its corresponding reply, for fetching a description of the queues
configured on a given port. OpenFlow 1.4 changes this message to a
multipart message OFPMP_QUEUE_DESC, which Open vSwitch has not until now
implemented. This commit adds an implemntation of that message. Because
the message is a replacement for the former one, this commit implements it
using the same ofp-util functions as the former message, so that the client
code doesn't have to distinguish a difference between versions.
The ovs-ofctl command queue-get-config was previously undocumented (due
only to an oversight). This commit corrects that and documents the new
feature available with OpenFlow 1.4.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Jarno Rajahalme <jarno@ovn.org>
Several OpenFlow 1.3+ messages use TLV-based properties that take a
common form. Until now, ofp-util has had some static functions for
dealing with properties. Because properties will start to be needed
outside of ofp-util, this commit breaks them out into a new library,
renaming them to begin with ofpprop_.
The following commit will add a few new interfaces that add new
functionality.
Signed-off-by: Ben Pfaff <blp@ovn.org>
The callers had some common code that could be reasonably encapsulated, so
this commit does so.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Jarno Rajahalme <jarno@ovn.org>
An upcoming commit will have a need to parse actions incrementally, so this
change makes that easier to do.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Jarno Rajahalme <jarno@ovn.org>
At first glance, OF1.4 queue properties look a lot like those for OF1.0
to OF1.3, but in fact their different padding makes them incompatible. In
addition, OF1.4 switches from using regular OpenFlow messages to request
queue properties, to using multipart messages. Thus, we really need to
use separate code to deal with OF1.4 queues.
OF1.0, OF1.1, and OF1.2 all have slightly different queue config reply
messages, but only OF1.0 and OF1.2 had tests, so this adds tests. (There
is no test for OF1.3 because it's the same as OF1.2.)
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Jarno Rajahalme <jarno@ovn.org>
The OFPT_SET_CONFIG and OFPT_GET_CONFIG_REPLY messages, which have the
same format, have a 'flags' field in which OpenFlow defines some bits,
which change somewhat from one version to another, and does not define
others. Until now, Open vSwitch has not abstracted these messages at all
and has ignored the bits that OpenFlow leaves undefined. This commit
abstracts the messages in the same way as other OpenFlow messages and
validates in OFPT_SET_CONFIG messages that the undefined bits are set to
zero.
OpenFlow 1.1 and 1.2, but not OpenFlow 1.0, define a flag named
OFPC_INVALID_TTL_TO_CONTROLLER. Open vSwitch has until now also
implemented this as an extension to OpenFlow 1.0, and this commit retains
that extension.
Reported-by: Manpreet Singh <er.manpreet25@gmail.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Andy Zhou <azhou@ovn.org>
I was not previously aware that this feature was missing.
Reported-by: Minoru TAKAHASHI <takahashi.minoru7@gmail.com>
Reported-at: http://openvswitch.org/pipermail/discuss/2015-October/019229.html
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Andy Zhou <azhou@ovn.org>
The code is easier to reason about with all of the assignments to the
members of 'reply' in one place.
Suggested-by: Andy Zhou <azhou@ovn.org>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Justin Pettit <jpettit@ovn.org>
Code earlier in this function validated that gm->type is valid, so
the default case at the end of the function would be impossible, but
since the code can change or perhaps get copied, return the correct
error to keep consistency and avoid reintroducing the bug fixed by
commit 09d4b951636b ("ofp-util: Reject bad group type and command
with error instead of abort.")
Signed-off-by: Flavio Leitner <fbl@redhat.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
This patch renames the command name related with geneve-map to a more
generic name as following:
add-geneve-map -> add-tlv-map
del-geneve-map -> del-tlv-map
dump-geneve-map -> dump-tlv-map
It also renames the Geneve_table to tlv_table.
By doing this renaming, the NSH variable context header (the same TLV
format as Geneve) or other protocol can reuse the field tun_metadata<N>
in the future.
Signed-off-by: Mengke Liu <mengke.liu@intel.com>
Signed-off-by: Ricky Li <ricky.li@intel.com>
Signed-off-by: Jesse Gross <jesse@kernel.org>
This patch adds support for Openflow1.4 error codes for set-async-config.
In this patch, a new error type, OFPET_ASYNC_CONFIG_FAILED is introduced
that enables the switch to properly inform the controller when controller
tries to set invalid mask or unsupported configuration.
Signed-off-by: Ambika Arora <ambika.arora@tcs.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Note that because there's been no prerequisite on the outer protocol,
we cannot add it now. Instead, treat the ipv4 and ipv6 dst fields in the way
that either both are null, or at most one of them is non-null.
[cascardo: abstract testing either dst with flow_tnl_dst_is_set]
cascardo: using IPv4-mapped address is an exercise for the future, since this
would require special handling of MFF_TUN_SRC and MFF_TUN_DST and OpenFlow
messages.
Signed-off-by: Jiri Benc <jbenc@redhat.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@redhat.com>
Co-authored-by: Thadeu Lima de Souza Cascardo <cascardo@redhat.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
This patch adds support for vacancy events in table-desc.
ovs-ofctl -O OpenFlow14 dump-tables-desc <switch>
-This command is enhanced to display the Vacancy Event configuration
of the tables on a <switch>, which is set using the mod-table command.
Signed-off-by: Saloni Jain <saloni.jain@tcs.com>
Co-authored-by: Hiteshi Kalra <hiteshi.kalra@tcs.com>
Signed-off-by: Hiteshi Kalra <hiteshi.kalra@tcs.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
OpenFlow 1.4 introduces the ability to turn on vacancy events with an
OFPT_TABLE_MOD message specifying OFPTC_VACANCY_EVENTS. This commit adds
support for the new feature in ovs-ofctl mod-table.
As per the openflow specification-1.4, vacancy event adds a mechanism
enabling the controller to get an early warning based on capacity
threshold chosen by the controller.
With this commit, vacancy events can be configured as:
ovs-ofctl -O OpenFlow14 mod-table <bridge> <table> vacancy:<low,high>
<low,high> specify vacancy threshold values in percentage for vacancy_down
and vacancy_up respectively.
To disable vacancy events, following command should be given:
ovs-ofctl -O OpenFlow14 mod-table <bridge> <table> novacancy
Signed-off-by: Saloni Jain <saloni.jain@tcs.com>
Co-authored-by: Shashwat Srivastava <shashwat.srivastava@tcs.com>
Signed-off-by: Shashwat Srivastava <shashwat.srivastava@tcs.com>
Co-authored-by: Sandeep Kumar <sandeep.kumar16@tcs.com>
Signed-off-by: Sandeep Kumar <sandeep.kumar16@tcs.com>
[blp@ovn.org fixed a few typos]
Signed-off-by: Ben Pfaff <blp@ovn.org>
Protocol-independent symbols OFPG_* were already defined in
openflow-common.h, so remove the protocol version dependent symbols.
Found by inspection.
Signed-off-by: Jarno Rajahalme <jarno@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
* encode: if properties are present include their length in
value of the length field of the group desc
* decode: use the value of the length field to calculate the length of
properties rather than assuming that the rest of the message
is properties. This assumption is not correct as a message
may contain multiple group descs.
Fixes: 18ac06d3546e ("ofp-util: Encoding and decoding of (draft) OpenFlow 1.5 group messages.")
Signed-off-by: Simon Horman <simon.horman@netronome.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
This patch adds a new action and fields to OVS that allow connection
tracking to be performed. This support works in conjunction with the
Linux kernel support merged into the Linux-4.3 development cycle.
Packets have two possible states with respect to connection tracking:
Untracked packets have not previously passed through the connection
tracker, while tracked packets have previously been through the
connection tracker. For OpenFlow pipeline processing, untracked packets
can become tracked, and they will remain tracked until the end of the
pipeline. Tracked packets cannot become untracked.
Connections can be unknown, uncommitted, or committed. Packets which are
untracked have unknown connection state. To know the connection state,
the packet must become tracked. Uncommitted connections have no
connection state stored about them, so it is only possible for the
connection tracker to identify whether they are a new connection or
whether they are invalid. Committed connections have connection state
stored beyond the lifetime of the packet, which allows later packets in
the same connection to be identified as part of the same established
connection, or related to an existing connection - for instance ICMP
error responses.
The new 'ct' action transitions the packet from "untracked" to
"tracked" by sending this flow through the connection tracker.
The following parameters are supported initally:
- "commit": When commit is executed, the connection moves from
uncommitted state to committed state. This signals that information
about the connection should be stored beyond the lifetime of the
packet within the pipeline. This allows future packets in the same
connection to be recognized as part of the same "established" (est)
connection, as well as identifying packets in the reply (rpl)
direction, or packets related to an existing connection (rel).
- "zone=[u16|NXM]": Perform connection tracking in the zone specified.
Each zone is an independent connection tracking context. When the
"commit" parameter is used, the connection will only be committed in
the specified zone, and not in other zones. This is 0 by default.
- "table=NUMBER": Fork pipeline processing in two. The original instance
of the packet will continue processing the current actions list as an
untracked packet. An additional instance of the packet will be sent to
the connection tracker, which will be re-injected into the OpenFlow
pipeline to resume processing in the specified table, with the
ct_state and other ct match fields set. If the table is not specified,
then the packet is submitted to the connection tracker, but the
pipeline does not fork and the ct match fields are not populated. It
is strongly recommended to specify a table later than the current
table to prevent loops.
When the "table" option is used, the packet that continues processing in
the specified table will have the ct_state populated. The ct_state may
have any of the following flags set:
- Tracked (trk): Connection tracking has occurred.
- Reply (rpl): The flow is in the reply direction.
- Invalid (inv): The connection tracker couldn't identify the connection.
- New (new): This is the beginning of a new connection.
- Established (est): This is part of an already existing connection.
- Related (rel): This connection is related to an existing connection.
For more information, consult the ovs-ofctl(8) man pages.
Below is a simple example flow table to allow outbound TCP traffic from
port 1 and drop traffic from port 2 that was not initiated by port 1:
table=0,priority=1,action=drop
table=0,arp,action=normal
table=0,in_port=1,tcp,ct_state=-trk,action=ct(commit,zone=9),2
table=0,in_port=2,tcp,ct_state=-trk,action=ct(zone=9,table=1)
table=1,in_port=2,ct_state=+trk+est,tcp,action=1
table=1,in_port=2,ct_state=+trk+new,tcp,action=drop
Based on original design by Justin Pettit, contributions from Thomas
Graf and Daniele Di Proietto.
Signed-off-by: Joe Stringer <joestringer@nicira.com>
Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
Due to an error on my part the Netronome vendor Id is incorrect:
the last digit should be 'd' rather than '0' as per the
Netronome IEEE OUI.
Signed-off-by: Simon Horman <simon.horman@netronome.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
This patch adds support for Openflow1.4 Group & meter change notification
messages. In a multi controller environment, when a controller modifies the
state of group and meter table, the request that successfully modifies this
state is forwarded to other controllers. Other controllers are informed with
the OFPT_REQUESTFORWARD message. Request forwarding is enabled on a per
controller channel basis using the Set Asynchronous Configuration Message.
Signed-off-by: Niti Rohilla <niti.rohilla@tcs.com>
Co-authored-by: Ben Pfaff <blp@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Sometimes it is useful to match only on whether a Geneve option
is present even if the specific value is unimportant. A special
case of this is zero length options where there is no value at all
and the only information conveyed is whether the option was included
in the packet.
This operation was partially supported before but it was not consistent -
in particular, options were never serialized through NXM/OXM unless
they had a non-zero mask. Furthermore, zero length options were rejected
altogether when they were installed through the Geneve map OpenFlow
command.
This adds support for these types of matches by making any NXM/OXM for
tunnel metadata force a match on that field. In the case of a zero length
option, both the value and mask of the NXM are ignored.
Signed-off-by: Jesse Gross <jesse@nicira.com>
Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
Define struct eth_addr and use it instead of a uint8_t array for all
ethernet addresses in OVS userspace. The struct is always the right
size, and it can be assigned without an explicit memcpy, which makes
code more readable.
"struct eth_addr" is a good type name for this as many utility
functions are already named accordingly.
struct eth_addr can be accessed as bytes as well as ovs_be16's, which
makes the struct 16-bit aligned. All use seems to be 16-bit aligned,
so some algorithms on the ethernet addresses can be made a bit more
efficient making use of this fact.
As the struct fits into a register (in 64-bit systems) we pass it by
value when possible.
This patch also changes the few uses of Linux specific ETH_ALEN to
OVS's own ETH_ADDR_LEN, and removes the OFP_ETH_ALEN, as it is no
longer needed.
This work stemmed from a desire to make all struct flow members
assignable for unrelated exploration purposes. However, I think this
might be a nice code readability improvement by itself.
Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
OpenFlow 1.0.1 says:
The dl_vlan_pcp field must be ignored when the OFPFW_DL_VLAN wildcard
bit is set or when the dl_vlan value is set to OFP_VLAN_NONE. Fields
that are ignored don’t need to be wildcarded and should be set to 0.
Previously, OVS wildcarded the PCP field when dl_vlan was OFP_VLAN_NONE,
but this commit changes the behavior to that suggested above: the PCP
field should not be wildcarded (and should be set to 0, but the code
already did that).
This commit only changes the translation from OVS's internal flow format
to the OpenFlow 1.0 wire format. Translation in the other direction and
to other formats is unaffected.
Found by OFTest.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
OpenFlow 1.5 says:
If the group-mod request specifies more than one bucket for a group of
type Indirect, the switch must refuse to add the group entry and must
send an ofp_error_msg with OFPET_GROUP_MOD_FAILED type and
OFPGMFC_INVALID_GROUP code.
Older versions don't specify a particular error for this case, so we might
as well use it for older OpenFlow also.
Found by OFTest.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
Until now, OVS has parsed all OF1.1+ group buckets that lack a weight
as having weight 1. Unfortunately, OpenFlow says that only "select"
groups may have a nonzero weight, and requires reporting an error for
other kinds of groups that have a nonzero weight. This commit fixes
the problem by parsing only select groups with a default weight of 1
and other groups with a default weight of 0. It also adds the
OpenFlow-required check for nonzero weights for other kinds of groups.
This complies with OpenFlow 1.1 and later. OF1.1 says in section 5.8:
If a specified group type is invalid (ie: includes fields such as
weight that are undefined for the specified group type) then the
switch must refuse to add the group entry and must send an
ofp_error_msg with OFPET_GROUP_MOD_FAILED type and
OFPGMFC_INVALID_GROUP code.
Found by OFTest.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Flavio Leitner <fbl@sysclose.org>
This patch adds support for Openflow1.4 set/get asynchronous configuration
messages. OpenVSwitch already supports set/get asynchronous configuration
messages for Openflow1.3. In this patch OFPT_SET_ASYNC_CONFIG message
allows the controllers to set the configuration for OFPT_ROLE_STATUS,
OFPT_TABLE_STATUS and OFPT_REQUESTFORWARD in addition to the Openflow1.3
messages. In a OFPT_SET_ASYNC, only the properties that shall be changed
need to be included, properties that are omitted from the message are
unchanged.
The OFPT_GET_ASYNC_CONFIG is used to query the asynchronous configuration
of switch. In a OFPT_GET_ASYNC_REPLY message, all properties must be
included.
According to Openflow1.4 the initial configuration shall be:
- In the “master” or “equal” role, enable all OFPT_PACKET_IN messages,
except those with reason OFPR_INVALID_TTL, enable all OFPT_PORT_STATUS
and OFPT_FLOW_REMOVED messages, and disable all OFPT_ROLE_STATUS,
OFPT_TABLE_STATUS and OFPT_REQUESTFORWARD messages.
- In the “slave” role, enable all OFPT_PORT_STATUS messages and disable
all OFPT_PACKET_IN, OFPT_FLOW_REMOVED, OFPT_ROLE_STATUS,
OFPT_TABLE_STATUS and OFPT_REQUESTFORWARD messages.
Signed-off-by: Niti Rohilla <niti.rohilla@tcs.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Otherwise, if some future version of OVS supports more Geneve options than
the current version, and any of these extras are in use, then one would be
unable to dump them with "ovs-ofctl dump-geneve-map", and any other
OVS-based software that wants to dump the Geneve map to work with the
existing options (i.e. ovn-controller) would fail entirely, instead of
being able to work with at least a subset.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
Several encapsulation formats have the concept of an 'OAM' bit
which typically is used with networking tracing tools to
distinguish test packets from real traffic. OVS already internally
has support for this, however, it doesn't do anything with it
and it also isn't exposed for controllers to use. This enables
support through OpenFlow.
There are several other tunnel flags which are consumed internally
by OVS. It's not clear that it makes sense to use them externally
so this does not expose those flags - although it should be easy
to do so if necessary in the future.
Signed-off-by: Jesse Gross <jesse@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
It doesn't make sense for the messages added to a bundle to have a
different OpenFlow version from the outer OpenFlow version.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
