[ovs-dev] [PATCH 2/2] secchan: Better tolerate failing controller admission control in fail-open.
keith at nicira.com
Tue Sep 15 08:22:24 UTC 2009
On Mon, 2009-09-14 at 17:02 -0700, Ben Pfaff wrote:
> Do you have an idea for a "harmless" packet to send though? I'm
> concerned that we could send out a packet that either would
> confuse the controller ("WTF is that? I don't know anything
> about that MAC address!") or that it would just ignore and not
> reply to.
I've a couple of alternative suggestions. These may already have been
considered and rejected for good reasons, but I wanted to make sure:
* Could we depend on the openflow protocol connection
establishment protocol? It seems like the controller could
reject the openflow connection at three points 1) before any
openflow messages are sent (for example if the TLS handshake
fails), 2) if the hello handshake does not contain compatible
openflow versions, 3) if there is something in the response to
the features request the controller doesn't like (for example a
duplicate DPID). Unfortunately, as I read the spec at least,
there is no positive acknowledgment of any of these stages.
Instead, the controller sends errors and terminates the
connection if it doesn't like how things are proceeding.
However, we could do something like have a user-configurable
timeout for which the switch will wait at each of these stages.
If the switch gets past sending the features response (stage 3)
and the timeout expires without the controller terminating the
connection, the switch could conclude the connection is good and
then start using it.
* Could we use OpenFlow echo request/reply messages? We're using
these now to determine the health of the connection when no
messages have been sent for a period of time anyway. We could
send one as early as immediately after the initial hello if that
isn't a protocol violation and depend on the reply coming within
a user configurable time as well.
Regardless of these mechanisms, we still probably need a mechanism for
timing out connections for which the controller never sends any data but
holds the TCP connection open, etc. I'm sure these already exist and
would be addressed by the changes already suggested, but include them
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dev