With the previous default burst limit of rate limit * 2, we would queue
up 2 seconds worth of packet_in messages. This is not only much more
than actually needed, it causes an actual problem: the datapath only
retains buffered packets for up to 1 second, by default, so that flow
setups sent in response have no packet to work with.
Now it helps clients track the number of in-flight messages, but lets the
clients do the limiting themselves. This will come in handy for packet-in
rate limiting (in an upcoming commit), in which we want to track in-flight
packet-in messages separately from other in-flight messages.
Before, if a hub connected a number of OpenFlow switches and the controller,
then in-band control traffic from one of the OpenFlow switches would be
seen by each of the other switches and forwarded up to the controller as
an ofp_packet_in message. That message would then be seen by all of the
other OpenFlow switches and also forwarded, and so on in an infinite loop.
This change prevents this situation by keeping secchan from forwarding
ofp_packet_in messages for a packet destined to the controller that
arrives on the port where the controller is located.
This code has at least two weaknesses. First, if the controller's port
changes, then the flows set up to drop packets will not be deleted. This
should not be a major problem: if this inadvertently kills a switch's
connection to the controller, then the switch will realize it after it
stops receiving data and re-connect. Its new connection will have new
flow data and therefore its packets will not be dropped.
Second, the notion of the "controller's port" does not take into account
the possibility of loops in the network topology. We need spanning tree
protocol for that.
This allows us to have DHCP clients that don't actually bind or unbind
a network device's IP address. This is useful for doing controller
discovery without actually reconfiguring a network device.
libtool was needed when NOX was directly linking against libopenflow.
Since it doesn't do that anymore, we can drop its use (and that makes
OpenFlow configure and build slightly faster).
This keeps vlogconf, in particular, from being linked against OpenSSL,
which in turn keeps the Debian package build tools from complaining that
the openflow-common package shouldn't need to depend on OpenSSL but does
because of the spurious library link.
One use case is when NOX is running on localhost, in which case waiting
for the full default backoff interval is unnecessary and undesirable.
Also changes default maximum backoff to 15 seconds (from 60).
With in-band control, it can happen that the controller needs to send
out an ARP request to find out the MAC address of the switch. These
packets are sent as broadcasts, so the secure channel will attempt to
send them back to the controller as ofp_packet_in messages. Of course,
that won't work, because the controller won't be able to respond to
the ofp_packet_in (because it needs the MAC address of the switch to
do so).
This commit makes the secure channel recognize broadcast ARP packets
that originate from the controller and flood them without passing them
back up to the controller.
Without this change, the secure channel announces that it is
entering or exiting fail-open mode only when an OpenFlow
message actually arrives from the local datapath. Thus,
when no packets arrive on any switch port, the secchan
never enters fail-open mode. Functionally, this makes no
difference, because there are no packets to switch anyhow
in that case, but it makes the log harder to interpret
since it's unclear whether the controller connection is
actually up.
With this change, the secure channel announcing that it is
entering or exiting fail-open mode is not tied to receiving
a packet on a switch port. Thus, the log is easier to
interpret.
It can happen that the secure channel thinks that it is connected
to the controller, but in fact the connection has dropped. For
example, a switch intermediate between the secure channel and the
controller could have a flow inserted, due to a malfunction, that
causes packets in one direction or the other to be dropped. When
this happens, the Linux kernel's TCP implementation will continue
retransmitting packets for somewhere between 13 and 30 minutes,
depending on the connection's retransmission timeout (according
to linux/Documentation/networking/ip-sysctl.txt) with the default
Linux settings.
We want to detect the lost connection and re-connect much faster
than that. We use OpenFlow echo request and reply messages: if
no message is received from the controller for N seconds, we
send out an echo request. If no reply (actually, any message at
all) is received for an additional N seconds, then we assume
that the connection has been lost, and reconnect.
Before, in in-band mode, the secure channel would flood all flows
destined for the broadcast destination when not connected to a
controller. The rationale was that this allowed for ARP replies
to be forwarded to the local port, so that the secure channel
could obtain the Ethernet address of the controller. But this
is a false rationale: ARP replies are unicast to the requester,
not broadcast. (Frames unicast to the local port are always handled
by the secure channel.)
Also, even if it were a correct rationale, it would not help in
at least one case: if the controller's Ethernet address has expired
from the ARP cache, but the secure channel's TCP connection to
the controller is still connected, then the secure channel attempt
to ARP would fail, since the broadcast ARP reply would not be
handled by the secure channel (since the secure channel thought
that it was still connected).
Ben Pfaff
Ben Pfaff