neutron contrail #0

Supports: trusty


Neutron is a virtual network service for Openstack, and a part of Netstack. Just like OpenStack Nova provides an API to dynamically request and configure virtual servers, Neutron provides an API to dynamically request and configure virtual networks. These networks connect "interfaces" from other OpenStack services (e.g., virtual NICs from Nova VMs). The Neutron API supports extensions to provide advanced network capabilities (e.g., QoS, ACLs, network monitoring, etc.) . This charm provides the OpenStack Neutron OpenContrail agent, managing L2 connectivity on nova-compute services.


OpenContrail ( is a fully featured Software Defined Networking (SDN) solution for private clouds. It supports high performance isolated tenant networks without requiring external hardware support. It provides a Neutron plugin to integrate with OpenStack.

This charm is designed to be used in conjunction with the rest of the OpenStack related charms in the charm store to virtualize the network that Nova Compute instances plug into.

This subordinate charm provides the Nova Compute vRouter component which contains the contrail-vrouter-agent service. Only OpenStack Icehouse or newer is supported. Juju 1.23.2+ required.


Nova Compute, Contrail Configuration and Keystone are prerequisite services to deploy.

Nova Compute should be deployed with legacy plugin management set to false:

  manage-neutron-plugin-legacy-mode: false

Once ready, deploy and relate as follows:

juju deploy neutron-contrail
juju add-relation nova-compute neutron-contrail
juju add-relation neutron-contrail:contrail-discovery contrail-configuration:contrail-discovery
juju add-relation neutron-contrail:contrail-api contrail-configuration:contrail-api
juju add-relation neutron-contrail keystone

Install Sources

The version of OpenContrail installed when deploying can be changed using the 'install-sources' option. This is a multilined value that may refer to PPAs or Deb repositories.

Control Node Relation

This charm is typically related to contrail-configuration:contrail-discovery. This instructs the Contrail vRouter agent to use the discovery service for locating control nodes. This is the recommended approach.

Should the user wish to use vRouter configuration that specifies the location of control nodes explicitly, not using the discovery service, they can relate to a contrail-control charm:

juju add-relation neutron-contrail contrail-control

Nova Metadata

To use Nova Metadata with Nova Compute instances, a metadata service must first be registered. Registration allows OpenContrail to create the appropriate network config to proxy requests from instances to a nova-api service on the network.

Option 'local-metadata-server' controls if a local nova-api-metadata service is started (per Compute Node) and registered to serve metadata requests. It is the recommended approach for serving metadata to instances and is enabled by default.

Alternatively, relating to a charm implementing neutron-metadata interface will use this external metadata service:

juju add-relation neutron-contrail neutron-metadata-charm

contrail-configuration charm also needs to be related to the same charm to register the metadata service:

juju add-relation contrail-configuration neutron-metadata-charm

Virtual Gateways

For launched instances to be able to access external networks e.g. the Internet a gateway is required that allows virtual network traffic to traverse an IP network.

For production setups, this is typically a hardware gateway. For testing purposes OpenContrail provides a software gateway (Simple Gateway) that runs on Compute Node(s) and provides this function.

Option 'virtual-gateways' allows specifying of one or more software gateways. The value is a YAML encoded string using a list of maps, where each map consists of the following attributes:

project - project name
network - network name
interface - interface to use (will be created)
subnets - list of virtual subnets to route
routes - list of routes gateway will make available to virtual subnets, selects all routes

For example to create a gateway for virtual subnet on 'admin:public' network using local interface vgw for routing:

juju set neutron-contrail \
  "virtual-gateways=[ { project: admin, network: public, interface: vgw, subnets: [ ], routes: [ ] } ]"

Previously specified gateways will be removed.

The routing of external IP networks needs to be updated if virtual network traffic will traverse it. Traffic flow from the IP network should be directed to one of the Compute Nodes.

For example a static route could be added to the router of the Compute Node network:

// assuming it's a linux box
sudo ip route add via <compute ip>

The virtual-gateways option can be used with 'floating-ip-pools' option of the contrail-configuration charm to create a typical Neutron setup of launched instances attached to a private network, each with an assigned public/external floating IP.

Using the running example above, you would use Neutron to create an external network with subnet and a private network of You would set the virtual-gateways option (as above) and the floating-ip-pools option. You would attach launched instances to the private network and then assign them floating IPs from the external network. vRouter will automatically perform 1:1 NAT of an external address to a private one. (Note: security groups may still need to be updated to allow traffic flow).


(string) Specify contrail-api ip manually
(int) Specify contrail-api port manually
(string) Specify the interface to use for the control channel. Default is to use vRouter interface that will be created.
(string) Specify discovery server ip manually
(string) Apt keys for package install sources
(string) Package sources for install
- "ppa:opencontrail/ppa" - "ppa:opencontrail/r2.20"
(boolean) Run a local instance of nova-api-metadata for serving metadata to VMs. An external metadata server (neutron-metadata relation) is not required when enabled.
(boolean) Juju on MAAS creates a juju-br0 bridge for deploying LXC and KVM workloads. Enable this to remove this bridge if you want to install vhost0 directly on the underlying interface. WARNING: This will break current and future juju-deployed LXC or KVM workloads on all machines where this is set to true.
(string) Specify the gateway for vhost0, either an IPv4 address or keyword 'auto'. 'auto' will set gateway automatically based on host's existing routes.
(string) Specify the interface to install vhost0 on. If left empty, vhost0 will be installed on the default gateway interface.
(string) Virtual gateways to create (software based). Using a YAML encoded string specify one or more gateways using a list of maps, where each map consists of the following attributes: project - project name network - network name interface - interface to use (will be created) subnets - list of virtual subnets to route routes - list of routes gateway will make available to virtual subnets, selects all routes For example: // make any network available to virtual subnet on // admin:public network using local interface vgw to route [ { project: admin, network: public, interface: vgw, subnets: [ ], routes: [ ] } ]