OpenFlow 1.0 doesn't allow matching on the ARP source and target
hardware address. This has caused us to introduce hacks such as the
Drop Spoofed ARP action. Now that we have extensible match, we can
match on more fields within ARP:
- Source Hardware Address (arp_sha)
- Target Hardware Address (arp_tha)
Signed-off-by: Justin Pettit <jpettit@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
One of the goals for Open vSwitch is to decouple kernel and userspace
software, so that either one can be upgraded or rolled back independent of
the other. To do this in full generality, it must be possible to change
the kernel's idea of the flow key separately from the userspace version.
In turn, that means that flow keys must become variable-length. This
commit makes that change using Netlink attribute sequences.
This commit does not actually make userspace flexible enough to handle
changes in the kernel flow key structure, because userspace doesn't yet
have enough information to do that intelligently. Upcoming commits will
fix that.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
check_action_exact_len() will always report that a Nicira extension action
has type 65535 (OFPAT_VENDOR), which isn't very helpful for debugging.
This introduces a new function that reports the subtype.
Also, log the subtype of unknown Nicira vendor actions.
First, this is an important message since it indicates a bug in the
controller, so log it at warning level instead of debug level--we want to
know about it.
Second, properly byteswap the action type.
Third, use the correct PRIu16 format specified for a uint16_t.
We have a need to identify tunnels with keys longer than 32 bits. This
commit adds basic datapath and OpenFlow support for such keys. It doesn't
actually add any tunnel protocols that support 64-bit keys, so this is not
very useful yet.
The 'arg' member of struct odp_msg had to be expanded to 64-bits also,
because it sometimes contains a tunnel ID. This member also contains the
argument passed to ODPAT_CONTROLLER, so I expanded that action's argument
to 64 bits also so that it can use the full width of the expanded 'arg'.
Userspace doesn't take advantage of the new space though (it was only
using 16 bits anyhow).
This commit has been tested only to the extent that it doesn't disrupt
basic Open vSwitch operation. I have not tested it with tunnel traffic.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
Feature #3976.
This fixes OpenFlow 1.0 flow stats reporting of flows added via NXM.
I noticed this problem while implementing 64-bit tunnel IDs, hence the
positioning. The following commit adds a test.
Acked-by: Jesse Gross <jesse@nicira.com>
In the medium term, we plan to migrate the datapath to use Netlink as its
communication channel. In the short term, we need to be able to have
actions with 64-bit arguments but "struct odp_action" only has room for
48 bits. So this patch shifts to variable-length arguments using Netlink
attributes, which starts in on the Netlink transition and makes 64-bit
arguments possible at the same time.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
The new 'zero' member was not being properly initialized. One approach
would be to add an assignment, but it seems more future-proof to let
flow_wildcards_init_catchall() do the right thing.
Noticed by valgrind.
Acked-by: Jesse Gross <jesse@nicira.com>
These will be useful for adding Nicira Extended Match support to ovs-ofctl.
This commit makes ofproto use the new flow_mod abstraction, but not the
new flow and aggregate stats abstraction. The latter takes a bit more
infrastructure that I haven't finished yet.
Open vSwitch contains a few different chunks of code that need to decode
an OpenFlow message to determine its type and then validate that it is
long enough. Until now, the code for doing this has been more or less
scattered across the tree. Whenever a new piece of code needed to do this,
it generally needed to reimplement at least part of it.
This commit centralizes all of that work into a single function,
ofputil_decode_msg_type(), and helper functions, and converts all of the
code that was decoding messages by hand to use the new function.
In NXFF_OPENFLOW10, the tun_id field is always supposed to be wildcarded.
That is what OVS used to do, but commit d8ae4d67 "flow: Fully separate
flow_wildcards from OpenFlow wildcard bits" broke it.
Since the Nicira Extended Match was specified nicira-ext.h has claimed that
arbitrary masks are allowed, but in fact only certain masks were actually
implemented. This commit implements general masking for the 802.1Q VLAN
TCI field.
This reduces code duplication, by eliminating a function that translates
from "struct flow" to "struct ofp_match" in favor of the existing function
ofputil_cls_rule_to_match(). It also allows the caller to specify the
desired priority (as part of the cls_rule).
Originally, wildcards were just the OpenFlow OFPFW_* bits. Then, when
OpenFlow added CIDR masks for IP addresses, struct flow_wildcards was born
with additional members for those masks, derived from the wildcard bits.
Then, when OVS added support for tunnels, we added another bit
NXFW_TUN_ID that coexisted with the OFPFW_*. Later we added even more bits
that do not appear in the OpenFlow 1.0 match structure at all. This had
become really confusing, and the difficulties were especially visible in
the long list of invariants in comments on struct flow_wildcards.
This commit cleanly separates the OpenFlow 1.0 wildcard bits from the
bits used inside Open vSwitch, by defining a new set of bits that are
used only internally to Open vSwitch and converting to and from those
wildcard bits at the point where data comes off or goes onto the wire.
It also moves those functions into ofp-util.[ch] since they are only for
dealing with OpenFlow wire protocol now.
The 'xid' in an ofp_header is not interpreted by the receiver but only by
the sender, so it need not be in any particular byte order. OVS used to
try to take advantage of this to avoid host/network byte order conversions
for this field. Older code in OVS, therefore, treats xid as being in host
byte order. However, as time went on, I forgot that I had introduced this
trick, and so newer code treats xid as being in network byte order.
This commit fixes up the situation by consistently treating xid as being
in network byte order. I think that this will be less surprising and
easier to remember in the future.
This doesn't fix any actual bugs except that some log messages would have
printed xids in the wrong byte order.
I don't know of any reason why the transaction id should be random. Using
consecutive ids means that there is no chance that two messages sent around
the same time will have the same transaction ID, which is probabilitically
possible with random IDs.
Our controller group at Nicira has requested a way to annotate flows with
extra information beyond the flow cookie. The new NXAST_NOTE action
provides such a way.
This new action is somewhat controversial. Some have suggested that it
should be added another way (either as part of the Nicira Extended Match
or as a new component of the flow_mod and related messages). Others think
that it has no place in the OpenFlow protocol at all and that an equivalent
should be implemented using the already available features of OVSDB. So
it is possible that this extension will be deleted and the feature will
be reimplemented some other way (or not at all).
CC: Teemu Koponen <koponen@nicira.com>
CC: Jeremy Stribling <strib@nicira.com>
The upcoming support for actions on registers will require the flow to
validate actions, so this commit adds the parameter in advance. It is
not yet used.
An upcoming commit will require the flow to be passed in as part of
OpenFlow action validation, but handle_packet_out() has until now been
structured to make this difficult. This commit refactors it to better
suit this purpose.
This breaks this OpenFlow handler into two parts, one responsible
for parsing and constructing OpenFlow messages and one that works
with the flow table. The latter will be reused in a later commit
that implements the Nicira Extended Match flexible flow match
extension.
There's no need to have a mask in this action, because both parts of the
TCI are part of the flow structure.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>