Skip to content

Instantly share code, notes, and snippets.

@madorn
Last active January 4, 2016 03:59
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save madorn/8565097 to your computer and use it in GitHub Desktop.
Save madorn/8565097 to your computer and use it in GitHub Desktop.
Havana: Neutron

Havana: Neutron

ML2 Plugin

One of the most significant features of Havana is the introduction of the ML2 (Modular Layer 2) plugin framework.

This allows OpenStack Networking to utilize a variety of existing layer 2 agents instead of locking into one specific vendor plugin.

Here is an example of OpenStack Networking utilizing the traditional monolithic OpenvSwitch plugin:

image

Here is an example of OpenStack Networking utilizing the traditional monolithic Linux Bridge plugin:

image

The ML2 introduces the use of Type and Driver Managers to allow for the use of variety of vendors and networking technologies:

image

  • The monolithic OpenvSwitch and Linuxbridge plugins will be depreciated when Icehouse is introduced.

Firewall as a Service (FWaaS)

Havana introduces Firewall as a Service.

FWaaS implements firewall rules with the use of Iptables. The Iptables configuration will be realized by an agent-driver combination that will program the Iptables rules on a gateway host. This agent is collocated with the L3 agent.

FWaas is a perimeter firewall distributed one per tenant. Creating a firewall stays in pending state until a router is created and the firewall is applied to that router.

Here are some examples:

neutron firewall-rule-create --protocol TCP --destination-port 80 --action allow webrule
neutron firewall-rule-create --protocol TCP --destination-port 22 --action allow sshrule
neutron firewall-policy-create --firewall-rules webrule sshrule mypolicy 
neutron firewall-rule-create --protocol TCP --destination-port 22 --action allow sshrule

To configure:

Set this parameter in the neutron.conf file on the host that runs neutron-server:

service_plugins = neutron.services.firewall.fwaas_plugin.FirewallPlugin

To use the reference implementation, you must also add a FWaaS driver configuration to the neutron.conf file on every node where the Neutron L3 agent is deployed:

[fwaas]
driver = neutron.services.firewall.drivers.linux.iptables_fwaas.IptablesFwaasDriver
enabled = True

Load Balancer as a Service (LBaaS)

Although LBaaS was introduced in Grizzly, starting with the Havana release, the Neutron Load-Balancer-as-a-Service (LBaaS) supports an agent scheduling mechanism, so several neutron-lbaas-agents can be run on several nodes (one per one).

Install the agent by running:

sudo apt-get install neutron-lbaas-agent

If you are using:

An OVS-based plug-in (OVS, NVP, Ryu, NEC, BigSwitch/Floodlight), you must set:

interface_driver = neutron.agent.linux.interface.OVSInterfaceDriver

To use the reference implementation, you must also set:

device_driver = neutron.services.loadbalancer.drivers.haproxy.namespace_driver.HaproxyNSDriver

Set this parameter in the neutron.conf file on the host that runs neutron-server:

service_plugins = neutron.services.loadbalancer.plugin.LoadBalancerPlugin

VPN as a Service (VPNaaS)

The VPNaaS extension provides OpenStack tenants with the ability to extend private networks across the public telecommunication infrastructure. The capabilities provided by this initial implementation of the VPNaaS extension are:

  • Site-to-site Virtual Private Network connecting two private networks.
  • Multiple VPN connections per tenant.
  • Supporting IKEv1 policy with 3des, aes-128, aes-256, or aes-192 encryption.
  • Supporting IPSec policy with 3des, aes-128, aes-256, or aes-192 encryption, sha1 authentication, ESP, AH, or AH-ESP transform protocol, and tunnel or transport mode encapsulation.
  • Dead Peer Detection (DPD) allowing hold, clear, restart, disabled, or restart-by-peer actions.

A VPN service relates the Virtual Private Network with a specific subnet and router for a tenant.

An IKE Policy is used for phase one and phase two negotiation of the VPN connection. Configuration selects the authentication and encryption algorithm used to establish a connection.

An IPsec Policy is used to specify the encryption algorithm, transform protocol, and mode (tunnel/transport) for the VPN connection.

A VPN connection represents the IPsec tunnel established between two sites for the tenant. This contains configuration settings specifying the policies used, peer information, MTU, and the DPD actions to take.

High-level VPN Flow:

The high-level task flow for using VPNaaS API to configure a site-to-site Virtual Private Network is as follows:

The tenant creates a VPN service specifying the router and subnet.

The tenant creates an IKE Policy.

The tenant creates an IPsec Policy.

The tenant creates a VPN connection, specifying the VPN service, peer information, and IKE and IPsec policies.

  • At this time VPNaaS does not support connectivity to VPN clients.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment