Generic selectors
Exact matches only
Search in title
Search in content
Search in posts
Search in pages

What a Difference a Plug-in Makes

I work for Nuage Networks and we recently announced an integration of our Openstack Neutron plug-in with Oracle Linux and Oracle Openstack. A key question arrived via Twitter: What is so special about this plug-in?

First of all, plug-ins are a mechanism to provide different vendor specific implementations of the same basic functionality / interface. Openstack Neutron comes with a default plug-in and it provides a functional implementation of all the concepts defined in the Neutron API (i.e. things like subnets, routers, ACLs, load balancing, etc.). The Nuage plug-in replaces the default plug-in, and connects Openstack with our Nuage network policy engine (VSD) and control plane (federated VSCs).

To understand how the resulting system differs from stock Openstack, it is important to understand the notion of having a separate control plane – a key aspect of Software Defined Networking (SDN).

In traditional Ethernet based networks, switches decide the port to forward a given packet to based on learning. Each switch maintains a table with a mapping between MAC address and forwarding port; if a given MAC address has no mapping, the packet is flooded out of every active port until a packet with the MAC address as source is received. Due to limited MAC table space and aging, there is a limit to the number of end points that can be supported with reasonable performance in such a network.

In order to build bigger networks like the Internet, routers were added. Like Ethernet switches, routers need to decide where to forward a given packet – but unlike switches, routers use separate protocols ( e.g. BGP, OSPF ) to exchange reachability information with other routers. This separate “control plane” replaces the “data plane” based learning process. It scales better than the Ethernet learning/flooding process, because each entry in the forwarding table represents a whole range of end points (subnet) and there is no flooding for unknown destinations.

With Nuage VSP, we build overlay networks that use a separate control plane (based on standard protocols like BGP and OpenFlow) for exchanging reachability information, for both L2 (Ethernet MAC addresses) and L3 ( Internet IP addresses ). This allows us to scale to large overlay networks that can span multiple data centres, and gives us the means to apply security and traffic management policies ( uch as allowing/blocking certain ports, controlling which endpoints can communicate and on which ports/protocols). We use an enhanced version of OpenVSwitch as the virtual switch/router in every hyper-visor, and OpenFlow to program each OVS instance.

The integrated system can be used in two ways: Networks can be created through OpenStack, or they can be created through the Nuage system ( VSD ) and “imported” into OpenStack. In both cases, VSD adds additional networking features to the resulting virtual networks, such as traffic statistics, QoS, advanced forwarding/redirection rules for service chaining, template-based policies, etc.

We can also connect physical servers and appliances to these virtual networks through software or hardware based gateways.

Standard OpenStack comes with a Neutron plug-in that integrates with OpenVSwitch too, however this configuration does not use a separate control plane, and it does not provide the additional functionality offered by VSP.

Keep in touch with Jeroen on Twitter here.

**Watch the recent #NFD8 live demo to learn more about what we do at Nuage Networks.**

 

The Nuage site uses cookies. By using this site, you are agreeing to our Privacy Policy.