[ovs-dev] [PATCH v2 3/3] secchan: Better tolerate failing controller admission control in fail-open.
Peter Balland
peter at nicira.com
Tue Sep 15 23:47:02 UTC 2009
Ben Pfaff wrote:
> +/*
> + * Fail-open mode.
> + *
> + * In fail-open mode, the switch detects when the controller cannot be
> + * contacted or when the controller is dropping switch connections because the
> + * switch does not pass its admission control policy. In those situations the
> + * switch sets up flows itself using the "normal" action.
> + *
> + * There is a little subtlety to implementation, to properly handle the case
> + * where the controller allows switch connections but drops them a few seconds
> + * later for admission control reasons. Because of this case, we don't want to
> + * just stop setting up flows when we connect to the controller: if we did,
> + * then new flow setup and existing flows would stop during the duration of
> + * connection to the controller, and thus the whole network would go down for
> + * that period of time.
> + *
> + * So, instead, we add some special caseswhen we are connected to a controller,
> + * but not yet sure that it has admitted us:
> + *
> + * - We set up flows immediately ourselves, but simultaneously send out an
> + * OFPT_PACKET_IN to the controller. We put a special bogus buffer-id in
> + * these OFPT_PACKET_IN messages so that duplicate packets don't get sent
> + * out to the network when the controller replies.
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.
> + * - 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.
- Peter
More information about the dev
mailing list