Team CodeChix presented their OpenMUL integration demo at OpenVswitch Summit 2014. Last year, Codechix chose OpenMUL as their platform of choice for developing OFConnect library for ONF driver contest. The video is also available here.
The major problem with legacy network equipment which spawned the SDN
movement has been the lack of simple and centralized management plane all the
while making the network highly agile. Various legacy devices like IP routers
had different and proprietary control plane to data plane interfaces and hence it
became impossible to centralize the control plane. Even the north bound
interfaces on top of control planes like SNMP, netconf varied wildly for each
One of the major USP of Openflow has been standardized interface between
control and data plane. It gives us immense potential to centralize control planes
and provide centralized control to network operators.
Having such a separation is great but is it a good idea to reinvent the way
networks all around the world have been designed?
The simple answer-we don’t need to redesign the networks. Because networks
still need to talk, say, OSPFv2 or BGPv4. These are built into DNA of modern
network infrastructure. But, Openflow can be definitely be used to solve the
centralized management problems. Effort should be put to bring more devices
under centralized management umbrella while letting interface to the external
world unchanged i.e. use OSPF, BGP etc as is.
Read the whitepaper here
The open-source code will be available in upcoming release of OpenMul ‘Concave’ in Jan 2015.
Many SDN enthusiasts ask us what sets us apart from other bigger projects like Opendaylight. ODL is a great project no doubt and has many features but we feel ODL is not yet ready for prime time and its architecture is inherently prone to stability and performance problems related to switch and application handling. On a highly loaded and dynamic network, stability and performance are of prime importance and that is where Openmul delivers and wins. Check Openmul Vs ODL performance and find out more.
Apart from performance the major points which sets openmul apart from the competition:
This article explains the spanning tree implementation of MUL SDN Controller.
This feature is used when there are one or more occurrences of loop in the network. Spanning Tree implementation makes sure that there are no loops when there are two or more paths to reach a particular network element. Once a loop is occurred due to a broadcast stream then it can be deadly for the network. So, this makes Loop Detection feature an antidote for any network.
Loop detection module uses LLDP for implementing Spanning Tree. When network element is added to a network, MUL SDN controller sends LLDP packets to every port of the attached network element. By doing this, MUL Controller gets the information about the network topology.
After getting all the information about the neighbours, port states needs to be decided.
Details of the process are : Continue reading
We are glad to announce availability of openmul release v4.0.1. Highlights of this release are :
– Support for Openflow 1.4
– Support for (almost) all Openflow 1.3 features
– Backward compatibility with Openflow 1.0, Openflow 1.3
– Support for RESTapi
* High performance Python tornado based webserver
– Improved documentation (here)
– Huge improvement in CLI features
* Tons of configuration options
– Many security and stability fixes in infrastructure
– Support for Overlays
– SSL support (TLSv1.2)
– Python bindings/Apis for advanced scripting
openmul development team
We did some benchmarking with open-mul and popular controller benchmark tool (cbench). And the results were amazing. Continue reading
We have strived hard to make Open-mul (and Pro version) one of the best performing SDN platforms in the world. Control plane performance and scalability is critical for SDN as there are so many things to manage and administer. But, MuL is not only about performance and newer openflow version support. We have focused on a few areas where we believe we can excel and bring real value :
1) Openflow based ethernet fabrics :
With advanced topology discovery and Openstack integration, it becomes very easy to have an Ethernet fabric up and running in a matter of few hours (if not minutes). Fabrics which are fast, which, are free from any vendor lockin makes a lot of sense to lot of people. It is unfortunate to see technology like TRILL still being pushed when Openflow can do far far better. Many commercial vendors (barring few) have given up Openflow based fabric. The main reasons being a) Lack of decent OpenFlow gear b) Lack of decent Software that makes up SDN c) Solid orchestration and network visibility/tools d) Last but not the least, effort by big vendors to push Openflow off-track and promote their own version of SDN
Ok, but how do we solve performance/scalability issues with Openflow and controllers ?? The answer is simple – By knowing what are limits of Openflow and engineering solutions based on collective understanding of Openflow and legacy systems. Control plane performance/scalability is not a problem for us because of our grounds up design to meet those requirements. Continue reading
Open-MuL has got bigger/ better with time. It also has a brand new home @ http://www.openmul.org
Thanks everyone for helping us reach where we are today