There is no need to for a forward declaration of vsp_vlandev_to_realdev()
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Ben Pfaff <blp@nicira.com>
In ovs-bugtool, we do a bunch of Popen calls to
get the results of some shell commands with stdout
set to PIPE. Once we are done, we need to
close the file descriptors.
Bug #11083.
Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
Ofproto-dpif treats an output to OFPP_NONE as a NOOP, but ofputil
treated it as an error. The former behavior seems more natural.
Reported-by: Teemu Koponen <koponen@nicira.com>
Signed-off-by: Ethan Jackson <ethan@nicira.com>
The ofproto parameters to lookup_input_bundle(), get_ofp_port() and
get_odp_port() may be const.
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Ben Pfaff <blp@nicira.com>
It improves to have proper out file name in bugtool archive with respect
to ovs-appctl commands. E.g. if command is 'ovs-appctl lacp/show' then
the related out file will be 'ovs-appctl-lacp-show.out'
Feature #11283.
Signed-off-by: Arun Sharma <arun.sharma@calsoftinc.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
This is an enhancement in bugtool archive output to determine the bond
state information. It is implemented as a plugin which internally calls
"ovs-appctl bond/show" command to get bond state.
Feature #11283.
Signed-off-by: Arun Sharma <arun.sharma@calsoftinc.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Until now, packets for these special protocols have been mixed with general
traffic in the kernel-to-userspace queues. This means that a big-enough
storm of new flows in these queues can cause packets for these special
protocols to be dropped at this interface, fooling userspace into believing
that, say, no CFM packets have been received even though they are arriving
at the expected rate.
This commit moves special protocols to a dedicated kernel-to-userspace
queue to avoid the problem.
Bug #7550.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Most exact-match flows can be handled directly in the datapath, but
for various reasons, some cannot: every packet in these flows must
be sent separately to userspace. Until now, flows that cannot be
handled entirely in the kernel have been allowed to miss each time
in the datapath. This is generally OK, but it has a few
disadvantages:
* It can make troubleshooting at the level where one must look
at datapath flows a bit confusing in some cases, because
datapath misses due to genuinely new flows are mixed in with
datapath misses for known flows that cannot be set up.
* It means that the kernel-to-userspace packets for a given
input port always go to a single kernel-to-userspace queue,
even if we'd like to segregate out some of the packets for
known flows. (An upcoming commit has examples.)
This commit therefore introduces the concept of a "slow path" flow,
one that is installed in the datapath with a single action that
sends the flow's packets to userspace. To make troubleshooting
easier, the action includes a reason code (displayed by "ovs-dpctl
dump-flows") that explains why the flow has been slow-pathed.
Bug #7550.
Signed-off-by: Ben Pfaff <blp@nicira.com>
The ofproto-dpif implementation of "facet"s requires a facet to be
associated with an OpenFlow rule. Until now, this meant that packets
that miss in the OpenFlow table (and thus didn't have OpenFlow rules)
couldn't be set up as facets and thus couldn't be installed in the
kernel. This commit changes that, by introducing "internal" OpenFlow
rules to associate with such packets.
Signed-off-by: Ben Pfaff <blp@nicira.com>
An upcoming commit will introduce a new type and a new use for the
additional members. It seems cleanest to use a union, rather that using
the existing members multiple ways.
Signed-off-by: Ben Pfaff <blp@nicira.com>
The compiler warns when we forget to handle some value of an enum, whereas
it won't for a sequence of 'if' statements.
Signed-off-by: Ben Pfaff <blp@nicira.com>
This bug is ordinarily not exposed because bridge_configure_tables() in
bridge.c configures the max number of flows soon after an ofproto is
created. But an upcoming commit will make construct() in ofproto-dpif.c
try to create some built-in flows before bridge gets control, so we need
to allow creating flows immediately upon initialization.
Signed-off-by: Ben Pfaff <blp@nicira.com>
If the daemon(s) aren't running for whatever reason, the RHEL ovs
ifup/ifdown scripts don't take that into account and an attempt to reboot a
system could take forever. (literally. endless loop!) Here are a couple of
patches (one of ifup, one for ifdown) to add timeouts (10 seconds), because
it runs per interface you have configured and that could take awhile to
reboot a system if needed.
Signed-off-by: Brian Kruger <bkruger+ovsdev@gmail.com>
[blp@nicira.com fixed up a conflict against master]
Signed-off-by: Ben Pfaff <blp@nicira.com>
Using the --no-wait option in the ifupdown script creates a
race condition where-in the network devices may not yet be created
after ovs-vsctl returns successfully.
Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
Not all ports may fit in a Features Reply, so if that's the case, then
use the new port description stat message for looking up ports.
Signed-off-by: Justin Pettit <jpettit@nicira.com>
OpenFlow Features Reply messages prior to 1.3 can give users the wrong
impression about how many ports are on the system. With this commit,
the command will check if the number of ports may be truncated. If so,
it will send a Port Description stats request to get the complete list
and ignore the Features Reply port list.
Bug #11087
Signed-off-by: Justin Pettit <jpettit@nicira.com>
There are a few places where we determine the size of a physical port
structure based on the OpenFlow version. Use a helper function to do
that.
Suggested-by: Ben Pfaff <blp@nicira.com>
Signed-off-by: Justin Pettit <jpettit@nicira.com>
Add function to determine whether the max number of ports are contains
in a Features Reply. If so, it removes the port list, since it may be
incomplete. This function will be used in a later commit.
Signed-off-by: Justin Pettit <jpettit@nicira.com>
OpenFlow 1.0 is limited to displaying 1364 ports in the Features Reply
message, and there is no other way to get consolidated port information.
OpenFlow 1.3 adds a new port description multipart message
(OFPMP_PORT_DESC) that is not limited by size. This commit adds support
through the OpenFlow 1.0 stats mechanism, since they have complimentary
enum values.
Bug #11040
Signed-off-by: Justin Pettit <jpettit@nicira.com>
We will be adding some OpenFlow 1.3 stats (aka multipart request)
messages to our OpenFlow 1.0 implementation. As such, move the
definition of those message numbers to the common location.
Signed-off-by: Justin Pettit <jpettit@nicira.com>
When the kernel validates set TCP/UDP port actions, it looks at
the ports in the existing flow to make sure that the L4 header exists.
However, these actions always use the IPv4 version of the struct.
Following patch fixes this by checking for flow ip protocol first.
Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
Bug #11205
Some OpenFlow 1.0 controllers incorrectly use OPFP_CONTROLLER as the
in_port in packet-out messages, when OFPP_NONE is their intent. Until now,
Open vSwitch has rejected such requests with an error message. This commit
makes Open vSwitch instead treat OFPP_CONTROLLER the same as OFPP_NONE for
compatibility with those controllers.
(Also, as of this writing, OpenFlow 1.0.1 appears to be changing the port
to use from OFPP_NONE to OFPP_CONTROLLER.)
Suggested-by: Rob Sherwood <rob.sherwood@bigswitch.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Until now it has not been possible to directly trace flows that include
register values and other concepts that are not in datapath flows, because
"ofproto/trace" requires a flow in the format output by "ovs-dpctl
dump-flows", which doesn't know anything about registers. This commit
makes it possible to instead specify an OpenFlow-like flow.
Feature #10084.
Requested-by: Igor Ganichev <iganichev@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
This function parses a flow rather than a cls_rule. It will be useful
for "ofproto/trace", which currently requires an odp_flow and thus can't
accept values for registers and other concepts that don't exist in the
kernel.
Signed-off-by: Ben Pfaff <blp@nicira.com>
ofputil_parse_key_value() is safe to use from a process that must not abort
except in one case: where the argument contains unbalanced parentheses.
This commit eliminates that call to ovs_fatal(), instead just treating the
end of the string as closing all nested parentheses.
It would be better to propagate the error condition upward, but I'm not
sure that it's worth it just for this one corner case.
The purpose of this commit is to make it possible to use this function
indirectly within the "ofproto/trace" implementation, which must never
abort ovs-vswitchd. (All the current callers are within ovs-ofctl and
other utilities.)
Signed-off-by: Ben Pfaff <blp@nicira.com>
Add scripts that will allow Open vSwitch bridges and ports to be
configured through /etc/network/interfaces. This patch follows a
very similar style as OVS network integration for rhel.
Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
This patch fixes a possible lock-up bug where rtnl_lock might not
get released.
Acked-by: Jesse Gross <jesse@nicira.com>
Signed-off-by: Ansis Atteka <aatteka@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>
As part of the bridge's main loop, it queries the STP status of all
ports. If the port doesn't exist, log files can become filled with
warning messages. This situation is very unusual, since system devices
do not normally disappear, but it's easy enough to rate-limit these
messages.
Bug #10936
Reported-by: Reid Price <reid@nicira.com>
Signed-off-by: Justin Pettit <jpettit@nicira.com>
The paragraph near the end that starts out "However, unlike OpenFlow 1.1,
..." seems to correctly document OVS behavior, but it also seems like
pretty lousy behavior. Justin says that he's going to fix it before we
put out an OVS release version with this behavior.
CC: Justin Pettit <jpettit@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
This should make it more obvious when the admin needs to restart a DHCP
client (or other daemon). Without this, unless the admin carefully reads
the documentation, the first notice he gets about a need to restart the
DHCP client can easily be when the lease expires and the machine drops off
the network.
Bug #5391.
Tested-by: Gurucharan Shetty <gshetty@nicira.com>
Suggested-by: Duffie Cooley <dcooley@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Before idle_age and hard_age were added, in the absence of timeouts there
was a space between the statistics for a flow and the start of the flow
match. This restores that space.
Requested-by: Paul Ingram <paul@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
