devstack/doc/source/guides/neutron.rst

Using DevStack with neutron Networking

This guide will walk you through using OpenStack neutron with the ML2 plugin and the Open vSwitch mechanism driver.

Network Interface Configuration

To use neutron, it is suggested that two network interfaces be present in the host operating system.

The first interface, eth0 is used for the OpenStack management (API, message bus, etc) as well as for ssh for an administrator to access the machine.

stack@compute:~$ ifconfig eth0
eth0      Link encap:Ethernet  HWaddr bc:16:65:20:af:fc
          inet addr:192.168.1.18

eth1 is manually configured at boot to not have an IP address. Consult your operating system documentation for the appropriate technique. For Ubuntu, the contents of /etc/network/interfaces contains:

auto eth1
iface eth1 inet manual
        up ifconfig $IFACE 0.0.0.0 up
        down ifconfig $IFACE 0.0.0.0 down

The second physical interface, eth1 is added to a bridge (in this case named br-ex), which is used to forward network traffic from guest VMs. Network traffic from eth1 on the compute nodes is then NAT'd by the controller node that runs Neutron's neutron-l3-agent and provides L3 connectivity.

stack@compute:~$ sudo ovs-vsctl add-br br-ex
stack@compute:~$ sudo ovs-vsctl add-port br-ex eth1
stack@compute:~$ sudo ovs-vsctl show
9a25c837-32ab-45f6-b9f2-1dd888abcf0f
    Bridge br-ex
        Port br-ex
            Interface br-ex
                type: internal
        Port phy-br-ex
            Interface phy-br-ex
                type: patch
                options: {peer=int-br-ex}
        Port "eth1"
            Interface "eth1"

Disabling Next Generation Firewall Tools

DevStack does not properly operate with modern firewall tools. Specifically it will appear as if the guest VM can access the external network via ICMP, but UDP and TCP packets will not be delivered to the guest VM. The root cause of the issue is that both ufw (Uncomplicated Firewall) and firewalld (Fedora's firewall manager) apply firewall rules to all interfaces in the system, rather then per-device. One solution to this problem is to revert to iptables functionality.

To get a functional firewall configuration for Fedora do the following:

sudo service iptables save
sudo systemctl disable firewalld
sudo systemctl enable iptables
sudo systemctl stop firewalld
sudo systemctl start iptables

To get a functional firewall configuration for distributions containing ufw, disable ufw. Note ufw is generally not enabled by default in Ubuntu. To disable ufw if it was enabled, do the following:

sudo service iptables save
sudo ufw disable

Neutron Networking with Open vSwitch

Configuring neutron, OpenStack Networking in DevStack is very similar to configuring nova-network - many of the same configuration variables (like FIXED_RANGE and FLOATING_RANGE) used by nova-network are used by neutron, which is intentional.

The only difference is the disabling of nova-network in your local.conf, and the enabling of the neutron components.

Configuration

FIXED_RANGE=10.0.0.0/24
FLOATING_RANGE=192.168.27.0/24
PUBLIC_NETWORK_GATEWAY=192.168.27.2

disable_service n-net
enable_service q-svc
enable_service q-agt
enable_service q-dhcp
enable_service q-meta
enable_service q-l3

Q_USE_SECGROUP=True
ENABLE_TENANT_VLANS=True
TENANT_VLAN_RANGE=1000:1999
PHYSICAL_NETWORK=default
OVS_PHYSICAL_BRIDGE=br-ex

In this configuration we are defining FLOATING_RANGE to be a subnet that exists in the private RFC1918 address space - however in in a real setup FLOATING_RANGE would be a public IP address range.

Neutron Networking with Open vSwitch and Provider Networks

In some instances, it is desirable to use neutron's provider networking extension, so that networks that are configured on an external router can be utilized by neutron, and instances created via Nova can attach to the network managed by the external router.

For example, in some lab environments, a hardware router has been pre-configured by another party, and an OpenStack developer has been given a VLAN tag and IP address range, so that instances created via DevStack will use the external router for L3 connectivity, as opposed to the neutron L3 service.

Service Configuration

Control Node

In this example, the control node will run the majority of the OpenStack API and management services (keystone, glance, nova, neutron)

Compute Nodes

In this example, the nodes that will host guest instances will run the neutron-openvswitch-agent for network connectivity, as well as the compute service nova-compute.

DevStack Configuration

The following is a snippet of the DevStack configuration on the controller node.

PUBLIC_INTERFACE=eth1

## Neutron options
Q_USE_SECGROUP=True
ENABLE_TENANT_VLANS=True
TENANT_VLAN_RANGE=3001:4000
PHYSICAL_NETWORK=default
OVS_PHYSICAL_BRIDGE=br-ex

Q_USE_PROVIDER_NETWORKING=True
Q_L3_ENABLED=False

# Do not use Nova-Network
disable_service n-net

# Neutron
ENABLED_SERVICES+=,q-svc,q-dhcp,q-meta,q-agt

## Neutron Networking options used to create Neutron Subnets

FIXED_RANGE="10.1.1.0/24"
PROVIDER_SUBNET_NAME="provider_net"
PROVIDER_NETWORK_TYPE="vlan"
SEGMENTATION_ID=2010

In this configuration we are defining FIXED_RANGE to be a subnet that exists in the private RFC1918 address space - however in a real setup FIXED_RANGE would be a public IP address range, so that you could access your instances from the public internet.

The following is a snippet of the DevStack configuration on the compute node.

# Services that a compute node runs
ENABLED_SERVICES=n-cpu,rabbit,q-agt

## Neutron options
Q_USE_SECGROUP=True
ENABLE_TENANT_VLANS=True
TENANT_VLAN_RANGE=3001:4000
PHYSICAL_NETWORK=default
OVS_PHYSICAL_BRIDGE=br-ex
PUBLIC_INTERFACE=eth1
Q_USE_PROVIDER_NETWORKING=True
Q_L3_ENABLED=False

When DevStack is configured to use provider networking (via Q_USE_PROVIDER_NETWORKING is True and Q_L3_ENABLED is False) -DevStack will automatically add the network interface defined in PUBLIC_INTERFACE to the OVS_PHYSICAL_BRIDGE

For example, with the above configuration, a bridge is created, named br-ex which is managed by Open vSwitch, and the second interface on the compute node, eth1 is attached to the bridge, to forward traffic sent by guest VMs.