This article is the first in a set of articles that will walk through the evaluation of Midokura’s MidoNet product. In the first article we will discuss Midokura’s solution, what it is made of, how it works and what expectations have been set with regard to performance and the solution it aims to solve.
An Overview of Midokura:
SDN Startup Midokura launched this week at the OpenStack conference in San Diego and has gained a lot of attention in the last week or two. If you are looking for a good write up on Midokura’s Midonet solution check out Shamus McGillicuddy‘s article on TechTarget called “Midokura network virtualization”
Ivan Pepelnjak did a nice technical write up back in August titled “Midokura’s Midonet Layer 2-4 Virtual Network Solution”
The Testing View:
In order to build a complete test plan we must first understand the parts of the solution.
By reading articles and looking at the Midokura website, we came up with a good idea of what Midokura was doing.
Midokura Midonet offers a way for companies solve complex network scaling issues using commodity PC hardware. Midonet creates a fully-meshed overlay network on top of an existing IP network.
MidoNet is a collection of different components:
- The MidoNet Agent, which runs on each node, fully processing packets as they enter the network and making sure they are delivered to the right host.
- A routing component based to handle L3 packets (something Nicira’s solution does not offer)
- A fast, distributed database to keep all of the flow, forwarding, filtering and other data needed to create the virtual topology.
- Tools to keep everything in synchronization and flowing.
Once we finished the paper evaluation, we reached out to Midokura to get more specific information.
Discussion with Midokura:
We were lucky to be able to grab about 30 minutes of Ben Cherian’s (CSO of Midokura) time on Friday night, only two days before the 2012 OpenStack conference. As our ultimate goal is to test the MidoNet product, we need a good understanding of MidoNet. From our discussion we learned the following:
Lab tests have shown a fully utilized 10GE Interface driven by a single core from a multi-core processor.
In MidoNet, Midokura uses some well known Open Source products. For routing, Midokura uses Quagga. For the databases Apache Cassandra. The underlying vSwitch is Open vSwitch and Apache Zookeeper is used to keep everything in sync.
GRE was given as an example in the virtual network overlay as it has been tested and is known to work. Other protocols could and probably are supported but have not had enough lab time to be called supported.
Evaluating MidoNet Part 1:
As we break down MidoNet’s design we can surmise that as new flows enter the network, the lookup on the first packet should take the longest. Once the first packets have been processed and a flow created, other packets matching the same flow should have a lower latency.
As all inbound packets must pass through the edge, the test plan should look at the time it takes for new packet flows to be inspected, looked up and installed into the flow table. This can be done by measuring the latency of packets crossing the system and comparing the first packet to the later ones once the latency has stabilized. Initially no features should be enabled.
Once a base measurement has been taken and verified, features such as packet filtering should be enabled. The features should be applied and extended, for example with packet filtering it would start with simple IP destination address filtering. IP source address, source port, destination port, window size and other knobs should be enabled and measurements taken to see how each new addition affects the lookup time and possibly forwarding performance.
After the base and IP filtering tests are complete you can evaluate the results to build more specific test cases that push MidoNet.
In the next article we will talk more about the MidoNet design what we know about its underlying components and how to test scale.