Understanding Openflow controller statistics

Kanzhe Jiang | Mar 6, 2012

    Network Monitoring has been an integral part of operating a network. It not only provides the visibility into how well the network performs, but also is an important tool when it comes to troubleshoot problems. Given the distributed nature of switching or routing devices in the network, a typical network monitoring tool usually queries a set of devices via some network management protocol, such as SNMP, and correlates results into reports or graphs. Even though SNMP is standardized, many vendors provide extension to the standard MIBs, which forced the management tools to be vendor aware and sometimes even version aware. For example, each router vendor has its own MIBS for MPLS and MPLS-based tunnels and VPNs.

    Openflow provides a centralized controller architecture that can consolidate many network states at a logical central server, which is called Openflow controller. The controller is not only the brain for the network, but also a software platform for other network applications. Network monitoring applications will be able to leverage controller’s global view of the network and provide visibility into the connectivities, throughputs, and flows at the data-path. The same application can also be standalone if it chooses, but still have the power to query network states and statistics via controller’s north-bound interfaces. The standardization of controller’s north bound interface is currently under consideration.
    The floodlight controller has a counterStore module that support counter-like statistics. The controller already collects a set of openflow statistics, which are available through its REST interface. Currently, the controller collects overall counts of OFPacketIn, OFPacketOut, and OFFlowmod and separate counts by switches and ports. The OFPacketIn counters are further classifies into separate broadcast, multicast, and unicast counters and different Layer 3 and L4 protocol counters to give the visibility of the types of flows in the network. It also keeps track of the number of active flows per switch. All counters are available via controller’s REST interface.
    For example,
    • an OFPacketIn of a particular switch can be retrieved with “http://<controllerIp>:8080/wm/core/counter/<switchdpid>/OFPacketIn/json”.  The output is a json dictionary object:
                {
                   ”<switchdpid>”: {
                        “Fri Mar 02 19:38:13 UTC 2012″: 128
                   }
               }
    • an OFPacketIn for L3 IPv4 counts: ”http://<controllerIp>:8080/wm/core/counter/<switchdpid>/OFPacketIn__L3_IPv4/json”.
              The output is a json dictionary object:
                {
                   ”<switchdpid>”: {
                        “Fri Mar 02 19:38:13 UTC 2012″: 102
                   }
                }
    There are many more important statistics that can be collected and useful in troubleshooting or providing better visibility into the health of the network. Please let us know or simple upload an implementation for your favorite stats.
    – Kanzhe Jiang

    Leave a Comment