Make "make" behave properly when these are changed by re-running
"configure", by putting their definitions into a generated file that
depends on Makefile.
Fail-open mode is entered or left in a secchan "periodic" callback, which
may not be called immediately after the connection to the controller
actually comes up. This can cause the fail-open local-packet CB to
locally handle messages from the datapath and drop them, causing the
controller to think that it's being ignore and drop the connection.
Thanks to Dan for raising the issue.
Before, we tried to use the port configuration bits to implement STP; e.g.
if a port was in LISTEN state we turned off sending and receiving frame
other than BPDUs. Unfortunately this interacts very badly with in-band
control: when the switch connects to the controller, it can be connected
to the controller over a port that is not in FORWARD, and so then the
controller disabled that port, and the connection eventually dropped when
an echo request/reply failed to get through.
Now, we implement STP by querying the flows on the switch and killing
off the ones that STP does not allow. This works much better because,
although we still kill off the in-band control connection, the in-band
hook in secchan is then able to resurrect it.
--no-stp is still the default since this has not been tested very much.
To enable SNAT, run configure with the "--enable-snat" flag. This has
only been tested with the 2.6.23 kernel...more diverse testing will follow.
Documentation and a cleaner build setup will also be in a future check-in.
When secchan is configured to "fail open" after failing to connect to
a controller for a period of time, it needs a heuristic for what
constitutes a successful connection. Until now, that heuristic was
simply that when it received an OpenFlow message from the controller
(any OpenFlow message), it considered the connection successful.
However, this is no longer good enough, because NOX performs
admission control on connections after sending a number of OpenFlow
messages, in particular after doing OpenFlow version negotiation and
requesting the switch features (and receiving the reply). Thus, this
commit adjusts the heuristic by only considering certain OpenFlow
messages to demonstrate that admission control checks have passed and
thus that the connection should be considered successful.
As a fallback, any connection that persists for 30 seconds or longer is
also considered successful.
An alternate and complementary approach (that this commit does not
implement) would be to use an OpenFlow error message to indicate why
the connection is closing.
Fixes bug #239.
Fixes a problem that a port that is disabled via "ifconfig down" does
not come back up properly when it is brought back up again with "ifconfig
up", if STP is enabled.
This new OpenFlow message format provides a cleaner interface and greater
detail and control over ports. It is now possible to see what features
the switch's port is currently configured as having, what it's advertising,
and what it's capable of handling. It is also possible to return the
features advertised by the port's peer.
802.1D Spanning Tree Protocol supports a maximum of 255 ports per bridge,
but OpenFlow supported 256, so 1 port had to not implement STP. This
gets rid of the problem by reducing the maximum number of ports to 255.
The kernel datapath was claiming that it implements STP, which is untrue.
In fact, the secchan implements STP, so if the secchan was not running
the STP support did not work. Thus, "controller nl:0" would do the
wrong thing.
This makes the secchan edit the responses from the datapath to claim
STP support.
The "port watcher" in secchan was not keeping track of updates to port
flags by the controller, which caused some combinations of secchan
and controller to not turn on ports when the STP state otherwise should
have done so.
Thanks to Justin for reporting the problem.
This commit prevents the secure channel from sending any traffic to
or from the controller up to the controller over its OpenFlow connection.
Instead, such traffic is always handled completely locally. This is
what the changes to in-band control up until now have been converging on:
each time, we have reduced the category of traffic that can be sent up
to the controller because we have found that doing so can cause a control
loop. This change goes all the way.
This reverts commit 123301f8b5,
because it broke second-hop OpenFlow switches' attempts to connect
to the controller.
Probably re-spin it later, with more testing this time.
This commit prevents the secure channel from sending any traffic to
or from the controller up to the controller over its OpenFlow connection.
Instead, such traffic is always handled completely locally. This is
what the changes to in-band control up until now have been converging on:
each time, we have reduced the category of traffic that can be sent up
to the controller because we have found that doing so can cause a control
loop. This change goes all the way.
When a hub has two switches and the controller on three of its ports,
control traffic from the controller to switch 1 is seen by switch 2 as
data traffic, and switch 2 sends it up over its OpenFlow connection. That
control traffic is in turn seen by the switch 1 as data traffic, and so
switch 1 sends it up over its OpenFlow connection. And so on: this is a
loop.
This commit fixes the situation by not sending up over the OpenFlow
connection traffic to the controller that arrived on the controller's
port, as well as traffic from the controller.
Ben Pfaff
Justin Pettit