[ovs-dev] [PATCH 2/2] secchan: Better tolerate failing controller admission control in fail-open.

Keith Amidon 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
for completeness.

--- Keith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-dev/attachments/20090915/8c765025/attachment-0003.html>

More information about the dev mailing list