[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