F5 OpenStack LBaaSv1 Documentation · CHAPTER 2 Releases and Versions The F5® OpenStack LBaaSv1 v...

F5 OpenStack LBaaSv1 DocumentationRelease 9.0.1

F5 Networks

Aug 04, 2017

Contents

1 Introduction 3

2 Releases and Versions 5

3 Quick Start 73.1 Downloads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.2 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.3 Upgrading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

4 Copyright 9

5 Support 11

6 License 136.1 Apache V2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

7 Site Contents 157.1 Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157.2 User Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

8 Support 47

9 Copyright 49

10 License 5110.1 Apache V2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5110.2 Contributor License Agreement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

i

F5 OpenStack LBaaSv1 Documentation, Release 9.0.1

Attention: End of Technical Support for F5 OpenStack LBaaS version 1

F5 announces the End of Technical Support (EoTS) for the F5 OpenStack LBaaS version 1 integration. Thisannouncement is in compliance with the OpenStack community deprecation of the OpenStack Neutron LBaaSversion 1 plugin. Customers are encouraged to move to OpenStack LBaaS version 2.

F5 ceased to repair defects and perform maintenance on the F5 OpenStack LBaaS version 1 integration as of theOpenstack Ocata release in April 2017.

For additional information, please refer to the F5 End of Life policy.

Contents 1

https://support.f5.com/csp/article/K3225

https://travis-ci.org/F5Networks/f5-openstack-lbaasv1


2 Contents

CHAPTER 1

Introduction

This site hosts the documentation for the F5® OpenStack OpenStack Neutron LBaaSv1 plugin and agent, used todeploy F5® BIG-IP® services in OpenStack. You can access the source code and download release packages atF5Networks/f5-openstack-lbaasv1.

3

https://github.com/F5Networks/f5-openstack-lbaasv1


4 Chapter 1. Introduction

CHAPTER 2

Releases and Versions

The F5® OpenStack LBaaSv1 v 9.0.1 plugin supports the OpenStack Mitaka release. See F5® OpenStack Releasesand Support Matrix for information about the LBaaSv1 plugin, BIG-IP®, and OpenStack release compatibility.

5

http://f5-openstack-docs.readthedocs.org/en/latest/releases_and_versioning.html

http://f5-openstack-docs.readthedocs.org/en/latest/releases_and_versioning.html


6 Chapter 2. Releases and Versions

CHAPTER 3

Quick Start

3.1 Downloads

You can download a release package directly from GitHub using curl or wget. Then, un-tar the package into thelocation of your choice.

Tip: Replace “<version_number>” with the version appropriate for your environment.

Example:

# curl -L -O https://github.com/F5Networks/f5-openstack-lbaasv1/releases/download/9.→˓0.1final/f5-lbaasv1_9.0.1final.tgz# tar -xf f5-lbaasv1_9.0.1final.tgz

3.2 Installation

3.2.1 Debian/Ubuntu

1. Install the F5 BIG-IP common libraries.

$ dpkg -i build/deb_dist/f5-bigip-common_9.0.1-final_all.deb

2. Install the plugin driver.

$ dpkg -i build/deb_dist/f5-lbaas-driver_9.0.1-final_all.deb

3. Install the plugin agent.

7

https://github.com/F5Networks/f5-openstack-lbaasv1/releases


$ dpkg -i build/deb_dist/f5-bigip-lbaas-agent_9.0.1-final_all.deb

3.2.2 RedHat/CentOS


$ rpm -i build/el7/f5-bigip-common_9.0.1-final.noarch.el7.rpm


$ rpm -i build/el7/f5-lbaas-driver-9.0.1-final.noarch.el7.rpm

3. Install the agent.

$ rpm -i build/el7/f5-bigip-lbaas-agent-9.0.1-final.noarch.el7.rpm

3.3 Upgrading

If you are upgrading from an earlier version, F5 recommends that you uninstall the current version before installingthe new version.

Note: Perform the following steps on every server running the F5® agent.

1. Make a copy of the F5 agent configuration file. An existing configuration file in /etc/neutron will be overwrittenduring installation.

$ cp /etc/neutron/f5-oslbaasv1-agent.ini ~/

2. Stop and remove the old version of the libraries, plugin driver and agent.

Debian/Ubuntu

$ sudo service f5-oslbaasv1-agent stop$ dpkg -r f5-bigip-common f5-lbaas-driver f5-bigip-lbaas-agent

Red Hat/CentOS

$ sudo service f5-oslbaasv1-agent stop$ yum remove f5-bigip-common.noarch f5-oslbaasv1-agent.noarch f5-→˓oslbaasv1-driver.noarch

3. Follow the installation instructions in the previous section.

4. Restore the F5 agent configuration file.

Compare the backup file with the new one created during installation to make sure only the necessary settingsfor your deployment are modified. Then, copy your configuration file back into /etc/neutron/.

$ cp ~/f5-oslbaasv1-agent.ini /etc/neutron/f5-oslbaasv1-agent.ini

8 Chapter 3. Quick Start

CHAPTER 4

Copyright

Copyright 2013-2016 F5 Networks, Inc.

9


10 Chapter 4. Copyright

CHAPTER 5

Support

See SUPPORT.md.

11


12 Chapter 5. Support

CHAPTER 6

License

6.1 Apache V2.0

Licensed under the Apache License, Version 2.0 (the “License”); you may not use this file except in compliance withthe License. ou may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an“AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See theLicense for the specific language governing permissions and limitations under the License.

13



14 Chapter 6. License

CHAPTER 7

Site Contents





7.1 Release Notes

7.1.1 Release Version

9.0.1

Supported Features

The following features of OpenStack Neutron LBaaSv1 are supported in this release:

• Load balancing methods: Round robin, Source IP, and Least connections

• Monitors

• Management

• Connection limits

• Session persistence

15


http://docs.openstack.org/admin-guide/networking_introduction.html#load-balancer-as-a-service-lbaas-overview


7.1.2 Compatibility

See the F5® OpenStack Releases and Support Matrix.

7.1.3 Package Contents

• Release Readme (this document)

• SUPPORT.md

• build

– deb_dist : Ubuntu installation files

– el6 : Red Hat / CentOS 6 installation files

– el7 : Red Hat / CentOS 7 installation files

7.1.4 Overview

The F5 OpenStack LBaaSv1 plugin allows you to orchestrate BIG-IP® Local Traffic Manager™ (LTM®) services –including virtual IPs, pools, device service groups, and health monitoring – in an OpenStack environment.

7.1.5 Before You Begin

You will need the following to use the F5 OpenStack LBaaSv1 plugin.

• Licensed BIG-IP (hardware or virtual edition)

• OpenStack Mitaka Neutron network deployment

Note: In order to use the Neutron command set, you need source a user file that has admin permissions.

$ source keystonerc_admin

7.1.6 Installation

Debian / Ubuntu







16 Chapter 7. Site Contents


Red Hat / CentOS







7.1.7 Upgrading






Debian/Ubuntu


Red Hat/CentOS








7.1. Release Notes 17




7.2 User Guide

This guide contains an overview of the F5® OpenStack LBaaSv1 plugin; its components and architecture; installationand configuration instructions; and basic overviews of BIG-IP® configurations that the plugin can manage in anOpenStack environment.





7.2.1 Overview

Release Version

9.0.1

Compatibility

See the F5® OpenStack Releases and Support Matrix.

Introduction

The F5® OpenStack LBaaSv1 plugin allows you to orchestrate BIG-IP® load balancing services – including virtualIPs, pools, device service groups, and health monitoring – in an OpenStack environment.

The F5® LBaaSv1 agent translates ‘OpenStack’ to ‘BIG-IP®’, so to speak, allowing you to provision BIG-IP® LocalTraffic Manager® (LTM®) services in an OpenStack environment.

The diagram below shows a sample OpenStack environment using the F5® plugin for OpenStack LBaaSv1. TheLBaaSv1 agent communicates with a BIG-IP® platform or Virtual Edition via iControl® REST. The load balancingservice request is handled by the BIG-IP® according to its configurations; it can then connect, discover, and/or deployto the cloud-based apps or vms in the OpenStack project network.






Fig. 7.1: Sample OpenStack Environment with F5® LBaaSv1 Plugin




7.2.2 Neutron Networking Prerequisites

The F5® OpenStack LBaaSv1 plugin supports two modes of network operation: global routed mode and L2 adjacentmode (the default). The Neutron core provider requirements are different for each mode; the modes are described indetail later in this document. You can configure this in the L3 Segmentation Mode Settings section of theagent configuration file, as described in Configuring the F5® LBaaSv1 agent.

Neutron is configured to use the ML2 core plugin by default. This configuration should appear in /etc/neutron/neutron.conf as shown below.

core_plugin = neutron.plugins.ml2.plugin.Ml2Plugin

The Neutron providernet extension allows you to configure a provider network that can be mapped directly to anexisting physical network.

The F5® LBaaSv1 agent uses providernet attributes to establish an L2 connection to BIG-IP® devices. If yourNeutron network doesn’t use the providernet extension, the F5® agent will not be able to correctly provision L2isolation and tenancy on your BIG-IP® devices.

7.2. User Guide 19


https://wiki.openstack.org/wiki/Neutron/ML2


To see if your Neutron networks support the providernet extension:

Tip: The *starred* attributes must be present for the agent to function properly.

# neutron net-show <network_name>+-----------------------------+--------------------------------------+| Field | Value |+-----------------------------+--------------------------------------+| admin_state_up | True || id | 07f92400-4bb6-4ebc-9b5e-eb8ffcd5b34c || name | Provider-VLAN-62 || *provider:network_type* | vlan || *provider:physical_network* | ph-eth3 || *provider:segmentation_id* | 62 || router:external | False || shared | True || status | ACTIVE || subnets | a89aa39e-3a8e-4f2f-9b57-45aa052b87bf || tenant_id | 3aef8f59a43943359932300f634513b3 |+-----------------------------+--------------------------------------+

See also:

• OpenStack Networking Guide - Provider networks with Open vSwitch

• OpenStack Administrator Guide





7.2.3 Plugin Components

The F5® OpenStack LBaaSv1 plugin comprises three packages:

• f5-bigip-common

• f5-oslbaasv1-agent

• f5-oslbaasv1-driver

All are open source and accessible on GitHub at F5Networks/f5-openstack-lbaasv1.


F5 announces the End of Technical Support (EoTS) for the F5 OpenStack LBaaS version 1 integration. Thisannouncement is in compliance with the OpenStack community deprecation of the OpenStack Neutron LBaaS


http://docs.openstack.org/mitaka/networking-guide/scenario-provider-ovs.html

http://docs.openstack.org/admin-guide/networking_adv-features.html


https://github.com/F5Networks/f5-openstack-lbaasv1


version 1 plugin. Customers are encouraged to move to OpenStack LBaaS version 2.



7.2.4 Architecture

Neutron LBaaSv1

When Neutron LBaaSv1 API calls are issued to your Neutron controller, the community LBaaSv1 plugin attempts touse either a designated service provider driver or the default service provider driver to provision LBaaSv1 resources.

F5® LBaaSv1 Plugin

The F5® LBaaSv1 service provider driver runs within the Neutron controller processes. It utilizes Neutron RPCmessaging queues to issue provisioning tasks to F5® LBaaSv1 agent processes.

When an LBaaSv1 API interface is invoked, the F5® LBaaSv1 driver schedules tasks to an F5® agent based on theagent’s availability (determined from the standard Neutron agent status messages). The agent starts, and communi-cates with, a configured BIG-IP®, then registers its own named queue where it will receive tasks from the Neutroncontroller(s).

The The F5® agent makes callbacks to the F5® drivers to query additional Neutron network, port, and subnet in-formation; allocate Neutron objects (for example, fixed IP addresses); and report provisioning and pool status. Thesecallback requests are placed on an RPC message queue processed by all listening F5® drivers in a round robin fashion.Since all Neutron controller processes are working transactionally off the same backend database, it doesn’t matterwhich of the available Neutron controller processes handles the requests.

F5® LBaaSv1 Driver and Agent Placement

The F5® LBaaSv1 driver should be installed on at least one Neutron controller. Installing drivers on additionalcontrollers scales out communications to Neutron.

The F5® LBaaSv1 agent should be installed on at least on Neutron controller. Installing additional agents on differenthosts in the same BIG-IP® environment (in other words, hosts that have the same BIG-IP® environment_prefixand iControl® endpoint settings) adds scheduled redundancy to the provision process. See BIG-IP® Environments formore information.

Neutron Agent Binding

Neutron LBaaSv1 binds pools to specific agents for the life of the pool. The redundancy allows other agents runningin the same environment to handle requests if the bound agent is not active.

Note: If the bound agent is inactive, it’s expected that it will be brought back online. If an agent is deleted, allpools bound to it should also be deleted. Run neutron lb-pool-list-on-agent <agent-id> to identifyall pools associated with an agent.

7.2. User Guide 21



Fig. 7.2: F5® LBaaSv1 Plugin Architecture



BIG-IP® Environments

Two agents which have different iControl® endpoint settings (in other words, agents that are provisioning differentsets of BIG-IP® devices) can not be configured with the same environment_prefix.

The scheduler uses the environment_prefix as a unique identifier for the agent process. If you use the sameenvironment_prefix for two agents that are managing separate BIG-IP® devices, the scheduler will confusethem, most likely resulting in errors.

See Running Multiple Agents on the Same Host for more information.

Tip: You can check the status of all running Neutron agent processes via the Neutron API agent interfaces, or byusing the commands shown below in the CLI client.

# neutron agent-list# neutron agent-show <agent_id>





7.2.5 Deploying the F5® OpenStack LBaaSv1 Plugin

Introduction

The most basic deployment consists of one F5® OpenStack LBaaSv1 driver and one LBaaSv1 agent installed onthe same Neutron controller. This is the recommended configuration for testing / POCs. Scale out and redundantinstallations can be added at any time.

Before you begin

You will need the following to use the F5 OpenStack LBaaSv1 plugin.

• Licensed BIG-IP (hardware or virtual edition)

• OpenStack Mitaka Neutron network deployment

Note: In order to use the Neutron command set, you need source a user file that has admin permissions.

$ source keystonerc_admin

7.2. User Guide 23



Downloads

You can download a release package directly from GitHub using curl or wget. Then, un-tar the package into thelocation of your choice.

Tip: Replace “<version_number>” with the version appropriate for your environment.

Example:

# curl -L -O https://github.com/F5Networks/f5-openstack-lbaasv1/releases/download/9.→˓0.1final/f5-lbaasv1_9.0.1final.tgz# tar -xf f5-lbaasv1_9.0.1final.tgz

Installation

Debian/Ubuntu







RedHat/CentOS







Upgrading



https://github.com/F5Networks/f5-openstack-lbaasv1/releases






Debian/Ubuntu


Red Hat/CentOS






Configuration

Configure the F5® LBaaSv1 Agent

The agent settings are found in /etc/neutron/f5-oslbaasv1-agent.ini. See the Sample Agent Configfile for detailed explanations of all available settings.

Important: At minimum, you will need to edit the Device Settings, Device Driver - iControlDriver Setting, and L3 Segmentation Mode Settings sections of the config file.

Be sure to provide the iControl® hostname, username, and password; without this information, the agent will not beable to connect to the BIG-IP® and will not run.

The installation process automatically starts an agent process; after you configure the /etc/neutron/f5-oslbaasv1-agent.init file, restart the agent process <start-the-agent>.

Configure the Neutron Service

The Neutron service settings are found in /etc/neutron/neutron_lbaas.conf. Edit the Default andService Providers sections as shown below to tell Neutron to use the F5® LBaaSv1 service provider driver.

7.2. User Guide 25


Note: In the service providers section, the f5.os.lbaasv1driver entry will be present, but commented out.Uncomment this line to identify the F5® plugin as the LBaaSv1 service provider. Add :default to the end ofthe line as shown below to set it as the default LBaaSv1 service provider.

# vi /etc/neutron/neutron_lbaas.conf[DEFAULT]loadbalancer_plugin = neutron.services.loadbalancer.plugin.LoadBalancerPlugin...[service providers]service_provider = LOADBALANCER:F5:f5.oslbaasv1driver.drivers.plugin_driver.→˓F5PluginDriver:default

Set the agent scheduler (optional)

In the default section of your neutron.conf file, the f5_loadbalancer_pool_scheduler_driver vari-able can be set to an alternative agent scheduler. The default value for this setting, f5.oslbaasv1driver.drivers.agent_scheduler.TenantScheduler, causes LBaaSv1 pools to be distributed within an environ-ment with tenant affinity.

Warning: You should only provide an alternate scheduler if you have an alternate service placement requirementand your own scheduler.

Restart the Neutron service

# service neutron-server restart \\ Debian/Ubuntu# systemctl neutron-service.service restart \\ RedHat/CentOS

Restart the http service

# service apache2 restart \\ Debian/Ubuntu# service httpd restart \\ Red Hat/CentOS

Start the F5® agent

The F5® agent may start running automatically upon installation. Taking this step will start or restart the service,depending on the agent’s current status.

# service f5-oslbaasv1-agent start

Note: If you want to start with clean logs, you should remove the log file first:

# rm /var/log/neutron/f5-oslbaasv1-agent.log

See also:



Once the agent has been installed and configured, you can use the Neutron agent commands to manage it.





7.2.6 Multiple Controllers and Agent Redundancy

The F5® LBaaSv1 plugin driver runs within the Neutron controller. When the Neutron community LBaaS pluginloads the driver, it creates a global messaging queue that will be used for all inbound callbacks and status updaterequests from F5® LBaaSv1 agents.

Tip: To run multiple queues, see the differentiated services section.

In an environment with multiple Neutron controllers, the F5® drivers all listen to the same message queue, providingcontroller redundancy and scale-out.

Note: All Neutron controllers must use the same Neutron database to avoid state problems with concurrently-runningcontroller instances.

If you choose to deploy multiple agents with the same BIG-IP® environment_prefix, each agent must runon a different host. The F5® agent uses the Neutron messaging configurations found in the file /etc/neutron/neutron.conf. To make sure the messaging settings on each host match those of the controller, we recommendcopying /etc/neutron/neutron.conf from the controller to each host.

Each F5® agent will communicate with its configured iControl® endpoint(s) to do the following:

• Verify that the BIG-IP® system(s) meet minimal requirements.

• Create a unique named queue to process provisioning requests from the F5® driver.

• Report as a valid F5® LBaaSv1 agent via the standard Neutron controller agent status queue.

The agents report their status to the agent queue on a periodic basis (every 10 seconds, by default; this can be configuredin /etc/neutron/f5-oslbaasv1-agent.ini).

When a Neutron controller receives a request for a new pool, the F5® LBaaSv1 driver invokes the tenant scheduler.The scheduler queries all active F5® agents and determines what, if any, existing pools are bound to each agent. If thedriver locates an active agent that already has a bound pool for the same tenant_id as the newly-requested pool, thedriver selects that agent. Otherwise, the driver selects an active agent at random. The request to create the pool serviceis sent to the selected agent’s task queue. When the provisioning task is complete, the agent reports the outcome to theLBaaSv1 callback queue. The driver processes the agent’s report and updates the Neutron database. The agent whichhandled the provisioning task is bound to the pool for the pool’s lifetime (in other words, that agent will handle alltasks for that pool as long as the agent and/or pool are active).

If a bound agent is inactive, the tenant scheduler looks for other agents with the same environment_prefix asthe bound agent. The scheduler assigns the task to the first active agent with a matching environment_prefixthat it finds. The pool remains bound to the original (currently inactive) agent with the expectation that the agent will

7.2. User Guide 27



eventually be brought back online. If the agent cannot be brought back online, communication with all pools managedby that agent is lost.

Warning: If you delete an agent, you should also delete all pools bound to that agent.

Run neutron lb-pool-list-on-agent <agent-id> to identify all pools associated with an agent.

Fig. 7.3: Horizontal Scale-out with the F5® LBaaSv1 plugin





7.2.7 Differentiated Services and Scale Out

The F5® LBaaSv1 plugin supports deployments where multiple BIG-IP® environments are required. In a differenti-ated service environment, the F5® driver for each environment has its own messaging queue. The tenant scheduler for




Fig. 7.4: F5® LBaaSv1 Plugin in Differentiated Service Environments

7.2. User Guide 29


each environment can only assign tasks to agents running in that environment.

Tip: The first section of the F5® agent config file - /etc/neutron/f5-oslbaasv1-agent.ini - providesinformation regarding the configuration of multiple environments.

To configure differentiated LBaaSv1 provisioning:

1. Install the agent and driver on each host that requires LBaaSv1 provisioning.

2. Assign an environment-specific name to the F5® agent in /etc/neutron/f5-oslbaasv1-agent.ini.

3. Create a service provider entry corresponding to each agent’s unique name in /etc/neutron/neutron_lbaas .

Warning: A differentiated BIG-IP® environment can not share anything. This precludes the use of vCMP fordifferentiated environments because vCMP guests share global VLAN IDs.

Default Environment Options

The F5® OpenStack LBaaSv1 plugin allows for the use of three default environment names - test, dev, and prod. Asshown in the excerpt from /etc/neutron/f5-oslbaasv1-agent.ini below, the service provider entries in/etc/neutron/neutron_lbaas correspond to each agent’s unique environment_prefix.

# For a test environment:## Set your agent's environment_prefix to 'test'## and add the following line to your LBaaS service_provider config# on the neutron server:## service_provider = LOADBALANCER:TEST:f5.oslbaasv1driver.drivers.plugin_driver.→˓F5®PluginDriverTest## For a dev environment:## Set your agent's environment_prefix to 'dev'## and add the following line to your LBaaS service_provider config# on the neutron server:## service_provider = LOADBALANCER:DEV:f5.oslbaasv1driver.drivers.plugin_driver.→˓F5®PluginDriverDev## For a prod environment:## Set your agent's environment_prefix to 'prod'## and add the following line to your LBaaS service_provider config# on the neutron server:## service_provider = LOADBALANCER:PROD:f5.oslbaasv1driver.drivers.plugin_driver.→˓F5®PluginDriverProd



After making changes to /etc/neutron/f5-oslbaasv1-agent.ini and /etc/neutron/neutron_lbaas, restart the neutron-server process.

# service neutron-server restart

Run neutron agent-list to view the list of active agents on your host to verify that the agent is up and running.If you do not see the f5-oslbaasv1-agent listed, you may need to restart the service.

# service f5-oslbaasv1-agent restart

Custom Environments

You can use a driver-generating module to create custom environments. On each Neutron controller which will hostyour custom environment, run the following command:

# python -m f5.oslbaasv1driver.utils.generate_env.py provider_name environment_prefix

Example: Add the custom environment ‘DFW1’.

# python -m f5.oslbaasv1driver.utils.generate_env.py DFW1 DFW1

The command creates a driver class and a corresponding service_provider entry in /etc/neutron/neutron_lbaas.

# service_provider = LOADBALANCER:DFW1:f5.oslbaasv1driver.drivers.plugin_driver_→˓Dfw1.F5®PluginDriverDfw1

Remove the comment (#) from the beginning of the new service_provider line to activate the driver.

Then, restart the neutron-server service.

# service neutron-server restart

Capacity-Based Scale Out

When using service differentiated environments, the environment can be scaled out to multiple BIG-IP® deviceservice groups by providing an environment_group_number`. Each agent associated with aspecific device service group should have the same ``environment_group_number.When environment grouping is configured, the service provider scheduler will consider the grouping along with anenvironment_capacity_score reported by the agents. Together, the agent grouping and the capacity scoreallow the scheduler to scale out a single environment across multiple BIG-IP® device service groups.

################################################################################ Environment Settings###############################################################################...# When using service differentiated environments, the environment can be# scaled out to multiple device service groups by providing a group number.# Each agent associated with a specific device service group should have# the same environment_group_number.## environment_group_number = 1

7.2. User Guide 31


#...

Each agent measures its group’s capacity. The agent reports a single environment_capacity_score for itsgroup every time it reports its status to the Neutron controller.

The environment_capacity_score value is the highest capacity recorded on several collected statistics speci-fied in the capacity_policy setting in the agent configuration. The capacity_policy setting is a dictionary,where the key is the metric name and the value is the max allowed value for that metric. The score is determined bydividing the metric collected by the max specified for that metric in the capacity_policy setting. An acceptablereported environment_capacity_score is between zero (0) and one (1). If an agent in the group reports an‘‘environment_capacity_score‘‘ of one (1) or greater, the device is considered to be at capacity.

When multiple environment_group_number-designated groups of agents are available, and a service is createdwhere the services’ tenant is not already associated with a group, the scheduler will try to assign the service to thegroup with the last recorded lowest environment_capacity_score. If the services’ tenant was associatedwith an agent where the environment_group_number for all agents in the group are above capacity, the newservice will be associated with another group where capacity is under the limit.

Warning: If you set the capacity_policy and all agents in all groups for an environment are at capacity,services will no longer be scheduled. When pools are created for an environment which has no capacity left, thepools will be placed in the error state.

The following metrics implemented by the iControl® driver can be configured in /etc/neutron/f5-oslbaasv1-agent.ini. These settings are used to manage your environment groups / BIG-IP® deviceservice groups.

################################################################################ Environment Settings###############################################################################...# throughput - total throughput in bps of the TMOS devices# inbound_throughput - throughput in bps inbound to TMOS devices# outbound_throughput - throughput in bps outbound from TMOS devices# active_connections - number of concurrent active actions on a TMOS device# tenant_count - number of tenants associated with a TMOS device# node_count - number of nodes provisioned on a TMOS device# route_domain_count - number of route domains on a TMOS device# vlan_count - number of VLANs on a TMOS device# tunnel_count - number of GRE and VxLAN overlay tunnels on a TMOS device# ssltps - the current measured SSL TPS count on a TMOS device# clientssl_profile_count - the number of clientside SSL profiles defined## You can specify one or multiple metrics.## capacity_policy = throughput:1000000000, active_connections: 250000, route_domain_→˓count: 512, tunnel_count: 2048#







7.2.8 Running Multiple F5 Agents on the Same Host

Warning: You should never run two agents for the same environment on the same host, as theenvironment_prefix setting in the agent config file allows Neutron to distinguish between agents. Mul-tiple agent processes for different environments – meaning each agent is associated with a different iControl®endpoint – can run on the same host.

Follow the steps below to set up multiple F5® agents on the same host.

1. Create a new environment.

$ python -m f5.oslbaasv1driver.utils.generate_env dsc4 dsc4

2. Add a service provider driver entry in /etc/neutron/neutron_lbaas to activate the new environment.

[service_providers]# Must be in form:# service_provider=<service_type>:<name>:<driver>[:default]# List of allowed service types includes LOADBALANCER# Combination of <service type> and <name> must be unique; <driver> must also be→˓unique# This is multiline option# service_provider=LOADBALANCER:name:lbaas_plugin_driver_path:defaultservice_provider=LOADBALANCER:DSC4:f5.oslbaasv1driver.drivers.plugin_driver_Dsc4.→˓F5PluginDriverDsc4service_provider=LOADBALANCER:F5:f5.oslbaasv1driver.drivers.plugin_driver.→˓F5PluginDriver#service_provider=LOADBALANCER:Haproxy:neutron_lbaas.services.loadbalancer.drivers.→˓haproxy.plugin_driver.HaproxyOnHostPluginDriver:default

3. Create a unique configuration file for each agent.

$ cd /etc/neutron$ cp f5-oslbaasv1-agent.ini f5-oslbaasv1-agent-dsc4.ini

4. Edit the new config file as needed.

Note: Each agent configuration file must have a unique iControl® endpoint.

5. Create additional upstart, init.d, or systemd service definitions for additional agents, using the defaultservice definitions as a guide.

Example: Create a new service definition on a Ubuntu server

7.2. User Guide 33



$ cd /etc/init$ cp f5-oslbaasv1-agent.conf f5-oslbaasv1-agent-dsc4.conf

\\ Edit the new agent start config file$ exec start-stop-daemon --start --chuid neutron --exec /usr/bin/f5-oslbaasv1-agent→˓--config-file=/etc/neutron/f5-oslbaasv1-agent-dsc4.ini --config-file=/etc/neutron/→˓neutron.conf --log-file=/var/log/neutron/f5-oslbaasv1-agent-dsc4.log

6. Start the new agent using the name of its unique upstart, init.d, or systemd service name.

$ sudo service f5-oslbaasv1-agent-dsc4 start

7. Restart neutron-server.

$ sudo service neutron-server restart





7.2.9 Supported Network Topologies

The F5® agent supports a variety of network topologies, configurable on either BIG-IP® hardware or Virtual Edition(VE).

Important: Throughout our documentation, we refer to ‘overcloud’ and ‘undercloud’ deployments.

overcloud

• BIG-IP® is deployed within your OpenStack cloud;

• requires a BIG-IP® VE;

• typically uses Global Routed Mode.

undercloud

• BIG-IP® is deployed outside of your OpenStack cloud;

• can use either physical devices or VE;

• requires L2-Adjacent Mode to tunnel (VXLAN or GRE) traffic between the BIG-IP® and tenants in thecloud.

The F5® LBaaSv1 plugin supports the following Neutron network topologies which require dynamic L2 and L3provisioning of BIG-IP® devices.

• Provider VLANs - VLANs defined by the admin tenant and shared with other tenants




• Tenant VLANs - VLANs defined by the admin tenant for other tenants, or defined by the tenants themselves

• Tenant GRE Tunnels - GRE networks defined by the tenant

• Tenant VxLAN Tunnels - VxLAN networks defined by the tenant

Global routed mode

Fig. 7.5: Global Routed Mode

In global routed mode, all VIPs are assumed routable from clients and all members are assumed routable from BIG-IP®. All L2 and L3 objects, including routes, must be pre-provisioned on the BIG-IP® prior to provisioning LBaaSv1services.

Global routed mode uses BIG-IP® AutoMap SNAT® for all VIPs. Because no explicit SNAT pools are defined, youshould create enough SelfIP addresses to handle anticipated connection loads.

Warning: In global routed mode, there is no network segregation between tenant services on the BIG-IP®.Likewise, overlapping IP address spaces for tenant objects is not available.

+--------------------------------------+--------------------------------------+| Topology | f5-oslbaasv1-agent.ini setting |+======================================+======================================+| Global Routed mode | f5_global_routed_mode = True |+--------------------------------------+--------------------------------------+

L2 Adjacent Mode

Important: L2 adjacent mode is the default mode.

7.2. User Guide 35

https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/tmos-routing-administration-12-0-0/8.html#unique_1573359865

https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/tmos-routing-administration-12-0-0/6.html#conceptid


Fig. 7.6: L2 Adjacent Mode

In L2 adjacent mode, the F5® agent provisions L2 networks – including VLANs and overlay tunnels – by associatinga specific BIG-IP® device with each tenant network that has a VIP or pool member. L3 addresses for BIG-IP® SelfIPsand SNATs are dynamically allocated from Neutron tenant subnets associated with LBaaSv1 VIPs or members. VIPlisteners are restricted to their designated Neutron tenant network.

L2 adjacent mode follows the micro-segmentation security model for gateways. Since each BIG-IP® device is L2-adjacent to all tenant networks for which LBaaSv1 objects are provisioned, the traffic flows do not logically passthrough another L3 forwarding device. Instead, traffic flows are restricted to direct L2 communication between thecloud network element and the BIG-IP®.

+--------------------------------------+--------------------------------------+| Topology | f5-oslbaasv1-agent.ini setting |+======================================+======================================+| L2 Adjacent mode | f5_global_routed_mode = False |+--------------------------------------+--------------------------------------+

One-Arm Mode

In a one-arm deployment, BIG-IP® has a single (hence, one-arm) connection to the router. VIPs and members areprovisioned from a single Neutron subnet. Use of SNATs is required; you can opt to either allocate SNAT addressesautomatically, or specify a number of SNAT addresses to make available from the subnet’s existing IP address pool(f5_snat_addresses_per_subnet).

+--------------------------------------+--------------------------------------+| Topology | f5-oslbaasv1-agent.ini settings |+======================================+======================================+| One-arm | f5_global_routed_mode = False || | f5_snat_mode = True || | || | optional settings: || | f5_snat_addresses_per_subnet = n || | || | where if n is 0, the virtual server || | will use AutoMap SNAT. If n is > 0, |



https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/tmos-routing-administration-12-0-0/8.html#unique_427846607

https://devcentral.f5.com/articles/microservices-versus-microsegmentation


Fig. 7.7: One-arm Mode

7.2. User Guide 37


| | n number of SNAT addresses will be || | allocated from the member subnet per || | active traffic group. |+--------------------------------------+--------------------------------------+

See also:

• BIG-IP TMOS: Implementations > Configuring a One-Arm Deployment

• BIG-IP TMOS: Routing Administration > NATs and SNATs

Multiple-Arm mode

Fig. 7.8: Multiple-arm Mode

Multiple-arm mode is, essentially, multiple one-arm deployments. In each arm, VIPs and members are provisionedfrom a specific Neutron subnet.

+--------------------------------------+--------------------------------------+| Topology | f5-oslbaasv1-agent.ini setting |+======================================+======================================+| Multiple-arm | f5_global_routed_mode = False || | f5_snat_mode = True || | || | optional settings: |


https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/tmos-implementations-12-0-0/33.html?sr=53479995

https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/tmos-routing-administration-12-0-0/8.html?sr=53483459


| | f5_snat_addresses_per_subnet = n || | || | where if n is 0, the virtual server || | will use AutoMap SNAT. If n is > 0, || | n number of SNAT addresses will be || | allocated from the member subnet per || | active traffic group. |+--------------------------------------+--------------------------------------+

Gateway Routed Mode

Fig. 7.9: Gateway Routed Mode

In gateway routed mode, the F5® agent attempts to create a default gateway forwarding service on the BIG-IP® formember Neutron subnets.

+--------------------------------------+--------------------------------------+| Topology | f5-oslbaasv1-agent.ini setting |+======================================+======================================+| Gateway routed mode | f5_global_routed_mode = False || | f5_snat_mode = False || | |+--------------------------------------+--------------------------------------+

VLANs

In order to establish connectivity between a BIG-IP® and VLAN, you need to map an interface on the BIG-IP® to aninterface on the physical network. In the example below, the BIG-IP interface 1.1 is mapping to the eth0 interface onthe hypervisor on which it’s running; in turn, eth0 maps to the bridges that provide connectivity from the compute nodeto the VLAN. The external bridge (br-ex) should have a corresponding provider:physical_network attribute.

See also:

F5 OpenStack Configuration Guide: Configure the Neutron Network -> Configure the Bridge.

To create the mapping, edit /etc/neutron/f5-oslbaasv1-agent.ini.

Tip: The f5_external_physical_mappings setting supports multiple, comma-separated entries. It’sgood practice to include a default mapping, for cases where the provider:physical_network doesnot match any configuration settings. A default mapping simply uses the word ‘default’ instead of a knownprovider:physical_network attribute.

7.2. User Guide 39

http://f5-openstack-docs.readthedocs.io/en/1.0/guides/map_neutron-network-initial-setup.html#configure-the-ovs-bridge


Fig. 7.10: Device VLAN to interface and tag mapping

################################################################################ L2 Segmentation Mode Settings################################################################################# Device VLAN to interface and tag mapping## For pools or VIPs created on networks with type VLAN we will map# the VLAN to a particular interface and state if the VLAN tagging# should be enforced by the external device or not. This setting# is a comma separated list of the following format:## physical_network:interface_name:tagged, physical_network:interface_name:tagged## where :# physical_network corresponds to provider:physical_network attributes# interface_name is the name of an interface or LAG trunk# tagged is a boolean (True or False)## If a network does not have a provider:physical_network attribute,# or the provider:physical_network attribute does not match in the# configured list, the 'default' physical_network setting will be# applied. At a minimum you must have a 'default' physical_network# setting.## standalone example:# f5_external_physical_mappings = default:1.1:True## pair or scalen example (1.1 and 1.2 are used for HA purposes):# f5_external_physical_mappings = default:1.3:True#



f5_external_physical_mappings = default:1.1:True#

Tunnels

For GRE and VxLAN tunnels, the F5® BIG-IP® devices expect to communicate with Open vSwitch VTEPs.The VTEP addresses for Open vSwitch VTEPs are learned from their registered Neutron agent configuration’stunneling_ip attribute.

Example:

# neutron agent-show 034bddd0-0ac3-457a-9e2c-ed456dc2ad53+---------------------+--------------------------------------+| Field | Value |+---------------------+--------------------------------------+| admin_state_up | True || agent_type | Open vSwitch agent || alive | True || binary | neutron-openvswitch-agent || configurations | { || | "tunnel_types": [ || | "gre" || | ], || | "tunneling_ip": "10.1.0.35", || | "bridge_mappings": { || | "ph-eth3": "br-eth3" || | }, || | "l2_population": true, || | "devices": 4 || | } || created_at | 2013-11-15 05:00:23 || description | || heartbeat_timestamp | 2014-04-22 16:58:21 || host | sea-osp-cmp-001 || id | 034bddd0-0ac3-457a-9e2c-ed456dc2ad53 || started_at | 2014-04-17 22:39:30 || topic | N/A |+---------------------+--------------------------------------+

The F5® LBaaSv1 agent supports the ML2 L2 population service in that overlay tunnels for Member IP accessare only built to Open vSwitch agents hosting Members. When using the ML2 population service, you can alsoelect to use static ARP entries for BIG-IP® devices to avoid flooding. This setting is found in /etc/neutron/f5-oslbaasv1-agent.ini.

# Static ARP population for members on tunnel networks## This is a boolean True or False value which specifies# that if a Pool Member IP address is associated with a gre# or vxlan tunnel network, in addition to a tunnel fdb# record being added, that a static arp entry will be created to# avoid the need to learn the member's MAC address via flooding.#f5_populate_static_arp = True

7.2. User Guide 41


The necessary ML2 port binding extensions and segmentation model are defined by default with the community ML2core plugin and Open vSwitch agents on the compute nodes.

When VIPs are placed on tenant overlay networks, the F5® LBaaSv1 agent sends tunnel update RPC messages to theOpen vSwitch agents to inform them of BIG-IP® device VTEPs. This allows tenant guest virtual machines or networknode services to interact with the BIG-IP®-provisioned VIPs across overlay networks.

BIG-IP® VTEP addresses should be added to the associated agent’s config file (/etc/neutron/f5-oslbaasv1-agent.ini).

# Device Tunneling (VTEP) selfips## This is a single entry or comma separated list of cidr (h/m) format# selfip addresses, one per BIG-IP device, to use for VTEP addresses.## If no gre or vxlan tunneling is required, these settings should be# commented out or set to None.##f5_vtep_folder = 'Common'#f5_vtep_selfip_name = 'vtep'

Run neutron agent-show <agent-id> to view/verify the VTEP configurations. The VTEP addresses arelisted as tunneling_ips.

# neutron agent-show 014ada1a-91ab-4408-8a81-7be6c4ea8113+---------------------+---------------------------------------------------------------→˓--------+| Field | Value→˓ |+---------------------+---------------------------------------------------------------→˓--------+| admin_state_up | True→˓ || agent_type | Loadbalancer agent→˓ || alive | True→˓ || binary | f5-bigip-lbaas-agent→˓ || configurations | {→˓ || | "icontrol_endpoints": {→˓ || | "10.0.64.165": {→˓ || | "device_name": "host-10-0-64-165.openstack.→˓f5se.com", || | "platform": "Virtual Edition",→˓ || | "version": "BIG-IP_v11.6.0",→˓ || | "serial_number": "b720f143-a632-464c-→˓4db92773f2a0" || | },→˓ || | "10.0.64.164": {→˓ || | "device_name": "host-10-0-64-164.openstack.→˓f5se.com", |



| | "platform": "Virtual Edition",→˓ || | "version": "BIG-IP_v11.6.0",→˓ || | "serial_number": "e1b1f439-72c3-5240-→˓4358bbc45dff" || | }→˓ || | },→˓ || | "request_queue_depth": 0,→˓ || | "environment_prefix": "dev",→˓ || | "tunneling_ips":→˓ || | "10.0.63.126",→˓ || | "10.0.63.125"→˓ || | ],→˓ || | "common_networks": {},→˓ || | "services": 0,→˓ || | "environment_capacity_score": 0,→˓ || | "tunnel_types": [→˓ || | "gre"→˓ || | ],→˓ || | "environment_group_number": 1,→˓ || | "bridge_mappings": {→˓ || | "default": "1.3"→˓ || | },→˓ || | "global_routed_mode": false→˓ || | }→˓ || created_at | 2015-08-19 13:08:15→˓ || description |→˓ || heartbeat_timestamp | 2015-08-20 15:19:15→˓ || host | sea-osp-ctl-001:f5acc0d3-24d6-5c64-bc75-866dd26310a4→˓ || id | 014ada1a-91ab-4408-8a81-7be6c4ea8113→˓ || started_at | 2015-08-19 17:30:44→˓ |

7.2. User Guide 43


| topic | f5-lbaas-process-on-agent→˓ |+---------------------+---------------------------------------------------------------→˓--------+





7.2.10 OpenStack and BIG-IP® Multi-tenancy

Fig. 7.11: BIG-IP® Multi-tenancy

To configure the F5® agent for multi-tenancy:

1. Edit /etc/neutron/f5-oslbaasv1-agent.ini.




########################################################################→˓######## L3 Segmentation Mode Settings########################################################################→˓########...#f5_global_routed_mode = False## Allow overlapping IP subnets across multiple tenants.# This creates route domains on big-ip in order to# separate the tenant networks.## This setting is forced to False if# f5_global_routed_mode = True.#use_namespaces = True## When use_namespaces is True there is normally only one route table# allocated per tenant. However, this limit can be increased by# changing the max_namespaces_per_tenant variable. This allows one# tenant to have overlapping IP subnets....#max_namespaces_per_tenant = 1## Dictates the strict isolation of the routing# tables. If you set this to True, then all# VIPs and Members must be in the same tenant# or less they can't communicate.## This setting is only valid if use_namespaces = True.#f5_route_domain_strictness = False#...

See also:

• BIG-IP® TMOS: Routing Administration > Route Domains





7.2. User Guide 45




7.2.11 BIG-IP® High Availability Modes

The F5® iControl® agent driver supports the following BIG-IP® High Availability (HA) modes:

• Standalone - No High Availability

• Pair mode - Active / Standby BIG-IP® devices – Coming soon!

• ScaleN mode - Multiple Active BIG-IP® devices (up to 4 devices) – Coming soon!

These options can be configured in the Device Settings section of /etc/neutron/f5-oslbaasv1-agent.ini.





7.2.12 Troubleshooting

If the f5-oslbaasv1-agent doesn’t appear when you run neutron agent-list, the agent is not running.

The options below can be useful for troubleshooting:

• Check the logs:

# less /var/log/neutron/f5-oslbaasv1-agent.log

• Check the status of the f5-os-lbaasv1-agent service:

# systemctl status f5-oslbaasv1-agent \\ RedHat/CentOS# service f5-oslbaasv1-agent status \\ Debian/Ubuntu

• Make sure you don’t have more than one agent running on the same host with the sameenvironment_prefix.

# environment_prefix = uuid \\ This is the default setting

• Make sure the iControl® hostname, username, and password in the config file are correct and that you canactually connect to the BIG-IP®.

• Make sure the VTEP lines in the config file are commented (#) out if you’re not using VTEP.

##f5_vtep_folder = 'Common'#f5_vtep_selfip_name = 'vtep'#

$ flake8 ./



CHAPTER 8

Support

See Support.

47

SUPPORT.md


48 Chapter 8. Support


50 Chapter 9. Copyright

CHAPTER 10

License

10.1 Apache V2.0

Licensed under the Apache License, Version 2.0 (the “License”); you may not use this file except in compliance withthe License. ou may obtain a copy of the License at


Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an“AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See theLicense for the specific language governing permissions and limitations under the License.

10.2 Contributor License Agreement

Individuals or business entities who contribute to this project must have completed and submitted the F5 ContributorLicense Agreement to [email protected] prior to their code submission being included in this project.

51


http://f5-openstack-docs.readthedocs.org/en/latest/cla_landing.html

http://f5-openstack-docs.readthedocs.org/en/latest/cla_landing.html

mailto:[email protected]

F5 OpenStack LBaaSv1 Documentation · CHAPTER 2 Releases and Versions The F5® OpenStack LBaaSv1 v...

Documents

Transcript of F5 OpenStack LBaaSv1 Documentation · CHAPTER 2 Releases and Versions The F5® OpenStack LBaaSv1 v...