Mirantis broadcast a live webinar on October 29, explaining what’s new in OpenStack Havana and fielding questions from the audience. (If you’ve missed it, or if you just want to see it again, you can download it here.) As part of that discussion, we explained what’s new in OpenStack Havana as far as OpenStack Networking, and we thought we’d bring some of that to you here. We’ll be focusing on Firewall-as-a-Service (FaaS), the L3 router service, the new ML2 plug-in, and the the Indigo Virtual Switch (IVS).
Firewall as a Service (FaaS)
One of the points of Neutron is that it’s software-defined networking. A lot of things that used to be done on dedicated hardware can now be done using software, and if you can do it using software, you can offer it as a service. One example of that in Havana is Firewall as a Service (FaaS).
Just like Load Balancing-as-a-Service (LBaaS), this is a reference implementation that can be replaced by vendor plugins, and in fact vArmor provides one with the Havan release. The reference implementation, in this case, uses Open vSwitch and IPTables and is not meant to be used in production without some serious testing.
FaaS is a perimeter firewall distributed one per tenant. If you create a firewall, it’s going to stay pending until you create a router, and then, once you do, it will apply to that router and to any other routers you create. And, because it’s meant to be a service available for your users, it’s available both in Horizon and from the command line, as you can see here.
neutron firewall-rule-create \ --protocol --destination-port --action neutron firewall-policy-create --firewall-rules \ "" \ myfirewallpolicy neutron firewall-create <firewall-policy-uuid>
It’s pretty straightforward–rules make up policies, and policies make up a firewall.
Migrate L3-router service from mix-in to plug-in
Some changes are more core to Neutron itself. One major change has to do with with the L3 router service. It used to be made up of two pieces–one on the client and one baked into the core on the server–which made it tough if you wanted an alternate implementation, say from a vendor. Now all of the L3 routing is provided as a separate plugin, so you can replace it if you want to.
New modular L2 (ML2) plug-in
Similarly, we now have a new modular L2 plugin, called ML2, which gets around a problem that was most eloquently described in Ivan Pepelnjak’s post, “OpenStack Quantum (Neutron) Plug-in: There Can Only Be One.” The problem was that the architecture allowed you to use only one plugin, which caused all kinds of problems if you wanted to, for example, mix hardware from different vendors who each might have their own plug-ins. So the ML2 plug-in creates a single plug-in, which can then be accessed by multiple L2 agents. So there is no more vendor lock-in, the plug-in works with the existing L2 agents, and it’s much easier to create new L2 agents as time goes on.
For further information
For a full look at what’s new in OpenStack Networking, OpenStack Compute, OpenStack Object Storage, and OpenStack Identity, check out the Neutron, Nova, Swift, and Keystone slide decks, below. You can also see the entire presentation, along with the explanatory audio and Q&A, here.