[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