Following patch adds skb-priority to flow key. So userspace will know
what was priority when packet arrived and we can remove the pop/reset
priority action. It's no longer necessary to have a special action for
pop that is based on the kernel remembering original skb->priority.
Userspace can just emit a set priority action with the original value.
Since the priority field is a match field with just a normal set action,
we can convert it into the new model for actions that are based on
matches.
Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
Bug #7715
The exit action causes the switch to immediately halt processing of
further actions. It's intended to be used in conjunction with
multi table support. It allows a table to force tables which call
it to discontinue processing a flow.
This function was only pretty-printing "bad request" error payloads. I
don't know why. It makes sense to pretty-print all of them except for
"hello" messages, which already have their own special cases.
Suggestion #7369.
Suggested-by: Reid Price <reid@nicira.com>
Until now, OVS has handled IP fragments more awkwardly than necessary. It
has not been possible to match on L4 headers, even in fragments with offset
0 where they are actually present. This means that there was no way to
implement ACLs that treat, say, different TCP ports differently, on
fragmented traffic; instead, all decisions for fragment forwarding had to
be made on the basis of L2 and L3 headers alone.
This commit improves the situation significantly. It is still not possible
to match on L4 headers in fragments with nonzero offset, because that
information is simply not present in such fragments, but this commit adds
the ability to match on L4 headers for fragments with zero offset. This
means that it becomes possible to implement ACLs that drop such "first
fragments" on the basis of L4 headers. In practice, that effectively
blocks even fragmented traffic on an L4 basis, because the receiving IP
stack cannot reassemble a full packet when the first fragment is missing.
This commit works by adding a new "fragment type" to the kernel flow match
and making it available through OpenFlow as a new NXM field named
NXM_NX_IP_FRAG. Because OpenFlow 1.0 explicitly says that the L4 fields
are always 0 for IP fragments, it adds a new OpenFlow fragment handling
mode that fills in the L4 fields for "first fragments". It also enhances
ovs-ofctl to allow users to configure this new fragment handling mode and
to parse the new field.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Bug #7557.
These macros caused trouble if datapath-protocol.h was included before
openflow.h. Later references to the icmp_type and icmp_code members of
struct ovs_key_icmp caused compiler errors, because the macros caused them
to try to refer to nonexistent tp_src and tp_dst members in those
structures.
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
This changes the output of "ovs-ofctl show" from printing ports like this:
1(eth1): addr:50:54:00:00:00:02, config: 0x11, state:0x1
to this:
1(eth1): addr:50:54:00:00:00:02
config: PORT_DOWN NO_FLOOD
state: LINK_DOWN
which seems much easier to read.
It also eliminates trailing white space from the output.
Reported-by: Ethan Jackson <ethan@nicira.com>
This patch creates a new action called "bundle". Bundles are a way
to implement a simple form of multipath in OpenFlow by grouping
several ports in a single output-like action.
This significantly simplifies code in ofp-print and ofproto-dpif and is
likely to simplify any new ofproto implementations whose support for
actions differs from ofproto-dpif.
The existing actions_first() and actions_next() iterator functions are not
much like the other iteration constructs found throughout the Open vSwitch
tree. Also, they only work with actions that have already been validated,
so there are cases where they cannot be used.
This commit adds new macros for iterating through OpenFlow actions, one
for actions that have been validated and one for actions that have not, and
adapts the existing users. The following commit will further refine action
parsing and add more users.
An upcoming commit will introduce new OPFUTIL_* constants for actions. It
seems best to be able to visually distinguish the contants. Most of the
existing constants start with a good prefix, but OFPUTIL_INVALID does not,
so rename it.
Flow dumps printed the OpenFlow table ID under the name "table_id", but
the flow parser only accepted "table". This makes them consistent by
changing the output. (Another alternative would be to change the accepted
input name.)
An upcoming patch will make stats messages much more like other messages,
in that their structures will include all of the headers. This means that
struct ofp_aggregate_stats_reply will no longer be appropriate as a
member of struct nx_aggregate_stats_reply, because it will then include
those additional header members.
Also, struct nx_aggregate_stats_reply doesn't need to use the special
ovs_32aligned_be64 type, since its 64-bit members are correctly aligned,
which is another reasonable reason to keep it separate.
These structures for OpenFlow stats requests and replies have identical
memebers, but until now they have been separate structures. Since in some
cases we actually want to treat both of them the same way, this has led
to various kinds of awkwardness. This commit merges them into a new
"struct ofp_stats_msg" and fixes up the users.
The NXAST_DROP_SPOOFED_ARP action has been deprecated in favor of
defining flows using the NXM_NX_ARP_SHA flow match for a while. This
commit removes it.
Signed-off-by: Justin Pettit <jpettit@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
I know already that this breaks the statsfixes that were implemented by the
following commits:
827ab71c97f "ofproto: Datapath statistics accounted twice."
6f1435fc8f7 "ofproto: Resubmit statistics improperly account during..."
These were already broken in a previous merge. I will work on a fix.
I looked at almost every uint<N>_t in the tree to determine whether it was
really in network byte order, and converted the ones that were.
The only remaining ones, modulo my mistakes, are in openflow.h. I'm not
sure whether we should convert those, because there might be some value
in remaining close to upstream for this header.
This implements basic multiple table support in ofproto and supporting
libraries and utilities. The design is the same as the one that has been
on the Open vSwitch "wdp" branch for a long time. There is no support for
multiple tables in the software switch implementation (ofproto-dpif), only
a set of hooks for other switch implementations to use.
To allow controllers to add flows in a particular table, Open vSwitch adds
an OpenFlow 1.0 extension called NXT_FLOW_MOD_TABLE_ID.
I looked at almost every uint<N>_t in the tree to determine whether it was
really in network byte order, and converted the ones that were.
The only remaining ones, modulo my mistakes, are in openflow.h. I'm not
sure whether we should convert those, because there might be some value
in remaining close to upstream for this header.
The "tun_id_from_cookie" OpenFlow extension predated NXM and supports only
a fraction of its features. Nothing (at Nicira, anyway) uses it any
longer. Support for it had been broken since January and it took until a
few days ago for anyone to complain, so it cannot be too important. This
commit removes it.
The range of "enum" types varies from one ABI to another. If the enums
being tested in these functions happen to be 16 bits wide, then GCC may
issue a warning because, in such a case, the comparison is always true.
Using an int instead of a uint16_t avoids that particular problem and
should suppress the warning.
Fixes the following reported warnings:
lib/ofp-print.c:240: warning: comparison is always true due to limited
range of data type
lib/ofp-util.c:1973: warning: comparison is always false due to limited
range of data type
Reported-by: YAMAMOTO Takashi <yamamoto@valinux.co.jp>
The ctype functions often need casts to be fully C standards compliant.
Here's the full explanation that I used to post to comp.lang.c from time
to time when the issue came up:
With the to*() and is*() functions, you should be careful to cast
`char' arguments to `unsigned char' before calling them. Type `char'
may be signed or unsigned, depending on your compiler or its
configuration. If `char' is signed, then some characters have
negative values; however, the arguments to is*() and to*() functions
must be nonnegative (or EOF). Casting to `unsigned char' fixes this
problem by forcing the character to the corresponding positive value.
This fixes the following warnings from some version of GCC:
lib/ofp-parse.c:828: warning: array subscript has type 'char'
lib/ofp-print.c:617: warning: array subscript has type 'char'
Reported-by: YAMAMOTO Takashi <yamamoto@valinux.co.jp>
Back in 2008 or so, I introduced this extension as a way to provide
information about switch status to the new "switch UI" program. Since
then, the switch UI program has been removed and the important information
that was provided by the switch status extension is now available in the
database, so we might as well get rid of this extension, and that is what
this commit does.
This function will see more use later in this series. This commit just
starts using it to make ofp-print output entirely consistent for
OFPST_FLOW and NXST_FLOW replies.
In NXST_FLOW replies, the priority was printed only if it was not
OFP_DEFAULT_PRIORITY, but it was always printed in OFPST_FLOW replies.
This commit changes OFPST_FLOW replies to match NXST_FLOW replies.
There's no value in the timestamp here, because it will always be the
same. Printing it just makes results less reproducible because output
then depends on the time zone.
This fixes a test failure in California due to yesterday's DST change,
and presumably a test failure almost everywhere else all the time.
Reported-by: Andrew Evans <aevans@nicira.com>
The blind replacement of strncpy() by ovs_strlcpy() is risky because
strncpy() never reads more bytes from its source string than necessary to
write its destination string, but ovs_strlcpy() and the OpenBSD function
that inspired it both read the entire source string. This avoids that
problem.
Given that change, we can use ovs_strlcpy() in a few more places, and
this commit does that too.
Coverity #10697,10696,10695,10694,10693,10692,10691,10690.
Without this commit, many of the unit tests for ofp-print.c fail with bus
errors on RISC architectures (tested on sparc) and presumably so would any
other code that uses these same struct members.
A few common IP protocol types were defined in "lib/packets.h". However,
we already assume the existence of <netinet/in.h> which contains a more
exhaustive list and should be available on POSIX systems.
