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

Ben Pfaff blp at nicira.com
Wed Sep 16 21:29:10 UTC 2009


Peter Balland <peter at nicira.com> writes:

> As it is currently implemented (designed?), it is my understanding
> that the controller can assume that it controls the fate of any
> packets for which a packet_in is received.  This commit appears to
> change that assumption, which may lead to problems for controllers
> trying to do some "weird" things.  Consider a controller that wants to
> rewrite packets in software and send them back out.  During the
> admittance window, the destination host may receive two packets: the
> original forwarded by the switch, and the forged packet generated by
> the controller from the packet_in message.
>
> Ben Pfaff wrote:
>> + *     - We also send out OFPT_PACKET_IN messages for totally bogus packets
>> + *       every so often, in case no real new flows are arriving in the network.
>
> I am bit uncomfortable with the forging of packets to determine
> controller admittance.  Controllers performing accounting, anomaly
> detection, etc, would all need to be aware of such packets.  While
> this complicated to do, it's one more thing to remember whenever
> dealing with packet_ins.  A new message type explicitly for admittance
> detection would be cleaner and self-documenting.

Pete, you're completely right about this.  I think that we can do
better than what this commit does, if we do some work on the NOX
side.

What I really want to do right now is, then, this:

        - Push this as-is.

        - File a bug describing my thoughts on how to fix it
          properly..

        - Fix that bug later, either just in NOX or in OpenFlow
          as a whole if we can get the consortium to agree.

Does that make sense, or do you think it should be fixed all at
once?

(This is semi-urgent, because the current implementation of
fail-open appears to sometimes causes HA failures and thus host
reboots on XenServer.)




More information about the dev mailing list