Installing and configuring Neutron services
In this installation, the various services that make up OpenStack Networking will be installed on the controller node rather than a dedicated networking node. The compute nodes will run L2 agents that interface with the controller node and provide virtual switch connections to instances.
Tip
Remember that the configuration settings recommended here and online at docs.openstack.org may not be appropriate for production systems.
To install the Neutron API server, the DHCP and metadata agents, and the ML2 plugin on the controller, issue the following command:
# apt-get install neutron-server neutron-dhcp-agent \ neutron-metadata-agent neutron-plugin-ml2 neutron-common \ python-neutronclient
On the compute nodes, only the ML2 plugin is required:
# apt-get install neutron-plugin-ml2
Creating the Neutron database
Using the mysql client, create the Neutron database and associated user. When prompted for the root password, use openstack:
# mysql –u root –p
Enter the following SQL statements in the MariaDB [(none)] > prompt:
CREATE DATABASE neutron; GRANT ALL PRIVILEGES ON neutron.* TO 'neutron'@'localhost' IDENTIFIED BY 'neutron'; GRANT ALL PRIVILEGES ON neutron.* TO 'neutron'@'%' IDENTIFIED BY 'neutron'; quit;
Update the [database] section of the Neutron configuration file at /etc/neutron/neutron.conf on all nodes to use the proper MySQL database connection string based on the preceding values rather than the default value:
[database] ... connection = mysql://neutron:neutron@controller01/neutron
Configuring the Neutron user, role, and endpoint in Keystone
Neutron requires that you create a user, role, and endpoint in Keystone in order to function properly. When executed from the controller node, the following commands will create a user called neutron in Keystone, associate the admin role with the neutron user, and add the neutron user to the service project:
# openstack user create neutron --password neutron # openstack role add --project service --user neutron admin
Create a service in Keystone that describes the OpenStack Networking service by executing the following command on the controller node:
# openstack service create --name neutron \ --description "OpenStack Networking" network
The service create command will result in the following output:
Figure 3.2
To create the endpoint, use the following openstack endpoint create command:
# openstack endpoint create \ --publicurl http://controller01:9696 \ --adminurl http://controller01:9696 \ --internalurl http://controller01:9696 \ --region RegionOne \ network
The resulting endpoint is as follows:
Figure 3.3
Enabling packet forwarding
Before the nodes can properly forward or route traffic for virtual machine instances, there are three kernel parameters that must be configured on all nodes:
net.ipv4.ip_forwardnet.ipv4.conf.all.rp_filternet.ipv4.conf.default.rp_filter
The net.ipv4.ip_forward kernel parameter allows the nodes to forward traffic from the instances to the network. The default value is 0 and should be set to 1 to enable IP forwarding. Use the following command on all nodes to implement this change:
# sysctl -w "net.ipv4.ip_forward=1"
The net.ipv4.conf.default.rp_filter and net.ipv4.conf.all.rp_filter kernel parameters are related to reverse path filtering, a mechanism intended to prevent certain types of denial of service attacks. When enabled, the Linux kernel will examine every packet to ensure that the source address of the packet is routable back through the interface in which it came. Without this validation, a router can be used to forward malicious packets from a sender who has spoofed the source address to prevent the target machine from responding properly.
In OpenStack, anti-spoofing rules are implemented by Neutron on each compute node within iptables. Therefore, the preferred configuration for these two rp_filter values is to disable them by setting them to 0. Use the following sysctl commands on all nodes to implement this change:
# sysctl -w "net.ipv4.conf.default.rp_filter=0" # sysctl -w "net.ipv4.conf.all.rp_filter=0"
Using sysctl –w makes the changes take effect immediately. However, the changes are not persistent across reboots. To make the changes persistent, edit the /etc/sysctl.conf file on all hosts and add the following lines:
net.ipv4.ip_forward = 1 net.ipv4.conf.default.rp_filter = 0 net.ipv4.conf.all.rp_filter = 0
Load the changes into memory on all nodes with the following sysctl command:
# sysctl -p
Configuring Neutron to use Keystone
The Neutron configuration file found at /etc/neutron/neutron.conf has dozens of settings that can be modified to meet the needs of the OpenStack cloud administrator. A handful of these settings must be changed from their defaults as part of this installation.
To specify Keystone as the authentication method for Neutron, update the [DEFAULT] section of the Neutron configuration file on all hosts with the following setting:
[DEFAULT] ... auth_strategy = keystone
Neutron must also be configured with the appropriate Keystone authentication settings. The username and password for the neutron user in Keystone were set earlier in this chapter. Update the [keystone_authtoken] section of the Neutron configuration file on all hosts with the following settings:
[keystone_authtoken] ... auth_uri = http://controller01:5000 auth_url = http://controller01:35357 auth_plugin = password project_domain_id = default user_domain_id = default project_name = service username = neutron password = neutron
Configuring Neutron to use a messaging service
Neutron communicates with various OpenStack services on the AMQP messaging bus. Update the [DEFAULT] and [oslo_messaging_rabbit] sections of the Neutron configuration file on all hosts to specify RabbitMQ as the messaging broker:
[DEFAULT] ... rpc_backend = rabbit
The RabbitMQ authentication settings should match what was previously configured for the other OpenStack services:
[oslo_messaging_rabbit] ... rabbit_host = controller01 rabbit_userid = openstack rabbit_password = rabbit
Configuring Nova to utilize Neutron networking
Before Neutron can be utilized as the network manager for Nova Compute services, the appropriate configuration options must be set in the Nova configuration file located at /etc/nova/nova.conf on all hosts.
Start by updating the following sections with information on the Neutron API class and URL:
[DEFAULT] ... network_api_class = nova.network.neutronv2.api.API [neutron] ... url = http://controller01:9696
Then, update the [neutron] section with the proper Neutron credentials:
[neutron] ... auth_strategy = keystone admin_tenant_name = service admin_username = neutron admin_password = neutron admin_auth_url = http://controller01:35357/v2.0
Nova uses the firewall_driver configuration option to determine how to implement firewalling. As the option is meant for use with the nova-network networking service, it should be set to nova.virt.firewall.NoopFirewallDriver to instruct Nova not to implement firewalling when Neutron is in use:
[DEFAULT] ... firewall_driver = nova.virt.firewall.NoopFirewallDriver
The security_group_api configuration option specifies which API Nova should use when working with security groups. For installations using Neutron instead of nova-network, this option should be set to neutron as follows:
[DEFAULT] ... security_group_api = neutron
Nova requires additional configuration once a mechanism driver has been determined. The LinuxBridge and Open vSwitch mechanism drivers and their respective agents and Nova configuration changes will be discussed in further detail in Chapter 4, Building a Virtual Switching Infrastructure.
Configuring Neutron to notify Nova
Neutron must be configured to notify Nova of network topology changes. Update the [DEFAULT] and [nova] sections of the Neutron configuration file on the controller node located at /etc/neutron/neutron.conf with the following settings:
[DEFAULT] ... notify_nova_on_port_status_changes = True notify_nova_on_port_data_changes = True nova_url = http://controller01:8774/v2 [nova] ... auth_url = http://controller01:35357 auth_plugin = password project_domain_id = default user_domain_id = default region_name = RegionOne project_name = service username = nova password = nova