Neutron is an abstraction layer. It separates your physical network from the direct "tenant network"/virtual network topology. It allows you pragmatically (through a reach API and cli) create virtual routers, lb, firewall. That way it allows you to emulate/virtualize physical devices in cloud.

The main idea is to keep the physical layer as simple and minimal as possible but reach enough so you can create more complex configuration on top of it. That way you can think about Neutron in term of configuration management, orchestration or network vitalization management.

Neutron

It defines a clear public API how to interact with Openstack to create network objects.

Provide Network as a Service (NaaS) to tenants to enable more advance deployments and configuration options.

Initially the goal was to remove the Nova Network from Openstack and create its won project to allow more flexibility and expand functionality (Nova network does support only a limited number of topologies: flat, flat DHCP and VLANs).

Platform for new future network development in Openstack.

Neutron is promising a scalable and highly available infrastructure for tenants.

There are some single point of failures (SPOF) in the current vanilla Havana release. This is one of the differences between the open source vanilla Neutron and vendor specific plugins.

It provides a choice of technology and no vendor lock-in for network in Openstack. One way of looking at it is that the customer have a choice of what technology/vendor he would like to use to build up the network infrastructure. The there benefit is access to an public open API that is independent of the actual backed technology. But it is important to understand that various backed drivers may provide different and more reach functionality than the Openstack one. In this case you can always get access to this through API extension that Neutron exposes as well. In this sense you can gain additional way of interacting and using your new technology and still remain open and interoperable with feature versions.

It allows for vendor specific extension for more advance networking features that may not be present in current Neutron API.

It is the platform to integrate all network functionality in cloud. Although its main focus is on the most common cases and what users demand.

Openstack wants to be the the reference model for the next generation cloud data center and Neutron aims to provide support for the networking part. By providing a common and widely acceptable platform it opens and allows multi network vendors integration.

Every vendor can have its own differentiate factors. In the current state of networking industry it is impossible to have a single API in Openstack to address every use case needs. It looks like there will be always space for vendor extension in Neutron for these infrastructure providers or customer who demand more specific and unique features that are not present yet.

Exposes network abstraction to developers, operation and devops teams who don't need to worry about the implemented details.

Would you run vanilla Openstack Neutron in production

This question was asked at about 41.50. There were different answers.

If you want to run the vanilla Neutron configuration it is not recommend to run it in production without good knowledge of how all Openstack components work and interact together.

You can run Neutron with vendor plugin in production. By choosing a vendor plugin instead of the vanilla open source solution you get additional level of confidence and support.

Maybe for private cloud depending on feature requirements and scalability but no for public cloud and enterprise network deployments.

Last posts

About Me

Linux enthusiast

Profile:Curious systems engineer interested in many of the IT technologies but especially in cloud systems and network engineering. A quick learner who likes to tinker and who often spent time researching and trying new technologies for personal and business benefit.

Please note that the code available here is only for demonstration purposes. If you want to be serious, you'll have to make it more robust and integrate it. Also, the description is by no means a definitive reference on any of the subjects, but rather the result of my experimentation. Feel free to report any bugs or errors you find in the code or otherwise in the articles. Thanks