In-Band Management for Indigo

Owned by Former user (Deleted)
Last updated: Mar 26, 2013 by Former user (Deleted)Version comment
3 min read

Table of Contents

Notes on In Band Controller Connection Design

This feature has been developed targeting a small scale conference network deployment (40 OF switches + 20 non-OF switches + 600 OVS OF switching hosts).

Definitions

  • Management traffic: Traffic between OpenFlow switches and an OpenFlow controller. This traffic may be originated from or transitting a given OpenFlow switch.
  • CPU: The switch CPU. A management entity and network endpoint.
  • Fail-host: A term suggested by Nick in contrast to "fail-closed": On loss of the controller connection, drop packets except those that should go to the CPU for whatever reason.
  • BC/MC: Abbreviation of broadcast/multicast packets.
  • Tree configured: A method by which OpenFlow switches are configured according to their proximity to the controller. The switch(es) closest to the controller are configured first and then OF switching is enabled on them allowing the next stage of switches to be configured.

Assumptions

  • (One Controller) There is only one OpenFlow controller active in the deployment at any given time.
  • (Mgmt VLAN) The management VLAN ID can be fixed prior to deployment and will not need to be changed (without reconfiguring the deployment).

Design Points

  • The controller traffic remains under OpenFlow control (hence the One Controller assumption).
  • The controller traffic will be restricted to a fixed VLAN which will be pre-configured in the switches.
  • Support an L2 address map cache on the switch for sending traffic from the CPU. Only addresses sending unicast packets to the switch's MAC address will have their locations recorded in the cache. Support may be required for detecting station movement due to loops.
  • It is vital to properly integrate inband management with the switch's behavior when the connection to the controller is lost. The approach is given in the UI section below, where fail-open/-closed is replaced/augmented.
  • A mechanism to signal a loss of controller connection should be implemented. Periodically flashing LEDs in a special pattern is one suggestion.
  • The state of the controller connection thus needs to be visible in more places in the code than it is presently. The core OF driver needs it for determining whether expiration processing should change. It is likely that external aps will want to get this information as well.

Design Description

UI Changes

The following will be changed in the UI

  • Add a text input field for the management VLAN ID.
  • Add a checkbox option to allow OpenFlow control of management traffic.
  • Change the management port selection to allow "any".
  • Add radio buttons to select if management traffic is OF controlled. Default is "no".
  • Add warning about the above (one-controller assumption, controller needs special programming to work with this mode).
  • Add failure mode radio buttons. Currently there are "fail open/closed". We will add:
    • fail-host: Delete all flowtable entries and drop packets except those normally forwarded to the CPU as management traffic. This should make the switch appear as simply a host on the network.
    • fail-static: Disable timeout processing and leave the flow table alone.

Note: BC/MC traffic is not differentiated from unicast traffic. Either it is dropped (fail-closed/fail-host) or forwarded according to the current flow table. This should allow BC/MC packets generated by the CPU to be sent to all ports without generating storms in "tree configured" switch deployments. This will cause problems if fail-open is selected and there are loops in the network.

OpenFlow Changes

The following will be changed in the OpenFlow code

  • The ofprotocol code will be changed to implement fail-host.
  • The ofprotocol code will be changed to implement fail-static.

The implementation of fail-static will be done with changes to the switch driver to simplify the process of disabling time-outs.

  • The state of the controller connection will be maintained in the datapath object as a boolean value (connected/not connected).
  • Handlers for controller connection state change will be added.
  • TBD: A conduit allowing the communication of controller connection state changes to the switch driver.
    • Implement a REST API in the command server that allows this to be communicated to ofswd
    • Option 1: ofproto is modified to make the REST API call
    • Option 2: Script that will poll the log output of ofproto and make a call to the REST API

(Note: Option 1 has been implemented and is under test)

The following may be changed in the Command Server code

An application to flash the LEDs on the loss of controller connection may be implemented.

Other todos:

  • Add "locate switch" mechanism that flashes LEDs (in a different pattern than "loss of controller connection")