There’s a new book to speed up your knowledge of OpenStack Neutron. The second edition of "Learning OpenStack Networking (Neutron)," is coming down the pike with updates and additional chapters.

Author James Denton, principal architect at Rackspace, has had his work cut out for him since the October 2014 edition launched. This 329-page manual available now from Packt Publishing promises to help readers "wield the power" of networking in OpenStack.

Superuser talked to Denton about why networking is taking center stage now, eliminating pain points in the Neutron project and his favorite resources for learning about OpenStack.

etcjix1k6p2yenurm9g4

What are the most significant updates to this edition of the book?

The second edition is based on features available as of the Kilo release and includes a few new chapters that cover:

• L3 High Availability using Virtual Router Redundancy Protocol (VRRP)
• Distributed Virtual Routing
• VPN as-a-service

In addition, Security Groups and firewall-as-a-service have been broken out into their own chapters, each with new and/or enhanced diagrams and figures to better explain their respective concepts and functionality. The concepts described in the book apply to the Liberty release as well, but there many be minor differences in implementation along with additional functionality compared to Kilo.

https://twitter.com/saintaardvark/status/600843276057505793

What was your reaction when Neutron was called out in the Tokyo Summit keynote as the most active project in OpenStack?

Neutron has been called out numerous times over the last two years as a major pain point in architecting and operating an OpenStack cloud.

It’s no surprise that Neutron was noted as the most active project this time around, considering all of the focus and resources that have been poured into stabilizing core features and functionality.

Also, as the project has matured, you’re seeing more vendors take notice and begin developing plugins to bring their technologies into the fold. Networking is the foundation of the cloud, and the work that the team has put into the project in the last two to three release cycles has really paid off.

Any thoughts on why "The time is now for networking to have its day," as Mark Collier said?

Server virtualization technologies have really matured, and the focus now is to bring the network stack into the fold. It makes sense that the next logical step is to virtualize network appliances in the same way servers were virtualized years ago. Network vendors are making it easier to bring firewalls, load balancers, and more in as virtual appliances that can be treated like any other virtual machine. A lot of work has been done in Neutron over the last couple of releases to ensure that the network plumbing and security model can support virtualized network appliances.

Now that the barriers are being eliminated, we should start seeing more and more network administrators embrace the idea of network virtualization and its benefits, much like server administrators did a decade ago. In addition, containerization technologies have really turned traditional networking implementations on their head, so I think we’ll see a shift towards software-defined networking (SDN) and other non-traditional ways of connecting devices to allow for large scale networking.

There’s a lot of work to be done!

Neutron has been criticized for its complexity on several OpenStack user surveys — what’s the best way to tackle that for an operator/administrator?

Networking is complicated, and we as users have been fortunate in recent years that vendors have simplified the process of configuring network devices and even networking within operating systems. Think back 15-20 years though, and things weren’t so easy. The underlying network functions are as complex as ever, but when those functions and configurations are abstracted from the user, one can take for granted how ‘easy’ it is.

Neutron is complex because networking is complex. No one system or environment is the same, and Neutron has to allow for numerous combinations and configurations. I think it’s important to have a solid foundation in networking to understand how to configure and implement Neutron features; even more so if you’re responsible for maintaining and troubleshooting them. Many operators may have a strong system administration or development background, but lack foundational network knowledge that would benefit them in standing up and maintaining an OpenStack cloud. Work is underway to provide better documentation on simple network configurations, but the truth is, anything other than simple is going to require some work to get right for your environment and use-case.

https://twitter.com/gatuus/status/664912895663169536

There’s so much you can learn online — why buy a physical book (or even an e-book)?

There is a ton of useful information regarding OpenStack and Neutron on the internet. The problem is finding what’s relevant to you. When you’re new to a subject, it’s hard to know what to search for, and even harder to weed through information without context or experience. Most blogs and snippets cover a particular issue or feature, and while extremely useful, are just one piece of a much larger puzzle.

The goal with this book is to provide an end-to-end experience for the reader, beginning with architecting the physical network, installing OpenStack and Neutron, and laying a foundation that enable the creation of networks, subnets, routers, and advanced network devices. I think readers can appreciate having all of that information in a centralized location.

What books or materials got you started with OpenStack?

When I started with OpenStack, we were deploying Essex-based clouds using nova-network. When Grizzly was introduced, we decided to adopt Quantum (Neutron) and found there was little information to be found other than the code itself.

I spent a lot of time testing various configurations until I found one that provided some kind of connectivity. I read up on the Open vSwitch manual to figure out how flows worked and were implemented, and spent some time reverse-engineering various OpenStack code files to see what was going on under the hood. Manually creating bridges and flows, creating and attaching VMs, and breaking things really helped me figure out how everything fit together and was orchestrated. Asaaf Muller, a core Neutron developer, has an excellent blog at http://assafmuller.com/ where he breaks down various Neutron components and technologies. I highly recommended his blog for anyone looking to immerse themselves in the nuts and bolts of Neutron.

Cover Photo // CC BY NC