F5 OpenStack LBaaSv2Documentation - Read the Docs · 3.3 F5 OpenStack LBaaSv2 User Guide ... This...

F5 OpenStack LBaaSv2DocumentationRelease 9.0.1

F5 Networks

Jul 13, 2016

Contents

1 Release 3

2 Compatibility 5

3 Site Contents 73.1 Release Notes v 9.0.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.2 Supported Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.3 F5 OpenStack LBaaSv2 User Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.4 F5® OpenStack LBaaSv2 Coding Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.5 Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

i

F5 OpenStack LBaaSv2Documentation, Release 9.0.1

Contents 1


2 Contents

CHAPTER 1

Release

Release 9.0.1

3


4 Chapter 1. Release

CHAPTER 2

Compatibility

This release is compatible with OpenStack Mitaka. For more information, please see the F5® OpenStack Releases,Versioning, and Support Matrix.

5

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



6 Chapter 2. Compatibility

CHAPTER 3

Site Contents

3.1 Release Notes v 9.0.1

This release introduces support for OpenStack Mitaka.

3.1.1 Release Highlights

This is the initial release for OpenStack Mitaka.

All Supported Features for previous releases are also supported in v 9.0.1.

Unsupported Features

The following F5® features are unsupported in 9.0.1; they will be introduced in future releases.

• BIG-IP® vCMP®

• Agent High Availability (HA) 1

• Differentiated environments 2

The following OpenStack Mitaka features are unsupported in 9.0.1:

• L7 Routing

• Unattached pools 3

• Loadbalancer statistics (e.g., neutron lbaas-loadbalancer-stats)

3.2 Supported Features

The LBaaSv2 features supported in release 9.0.1 are noted below. See the agent configuration file –/etc/neutron/services/f5/f5-openstack-agent.ini – for more information about each feature.

1 Similar to BIG-IP high availability, but applies to the F5 agent processes.2 Multiple F5 agents running on the same host, managing separate BIG-IP environments.3 Creating a pool with no listener.

7

https://f5.com/resources/white-papers/virtual-clustered-multiprocessing-vcmp

http://docs.openstack.org/releasenotes/neutron-lbaas/unreleased.html#new-features


3.2.1 HA mode

Overview

HA, or, ‘high availability’, mode refers to high availability of the BIG-IP® device(s). The F5® agent can configureBIG-IP to operate in standalone, pair, or scalen mode. The F5 agent configures LBaaS objects on HA BIG-IP devicesin real time.

Use Case

High availability modes provide redundancy, helping to ensure service interruptions don’t occur if a device goes down.

• standalone mode utilizes a single BIG-IP device; here, ‘high availability’ means that BIG-IP core services areup and running, and VLANs are able to send and receive traffic to and from the device.

• pair mode requires two (2) BIG-IP devices and provides active-standby operation. When an event occurs thatprevents the ‘active’ BIG-IP device from processing network traffic, the ‘standby’ device immediately beginsprocessing that traffic so users experience no interruption in service. There is no loss in performance since thestandby device takes over the entire traffic load.

• scalen mode requires a device service cluster of two (2) - four (4) BIG-IP devices. Scalen allows you to configuremultiple active devices, each of which can fail over to other available active devices (active-active mode). Forexample, if two BIG-IPs are configured in active-active mode, both devices in the pair are actively handlingtraffic. If an event occurs that prevents one device from processing traffic, that traffic is automatically directedto the other active device.

Note: Depending on device configuration and capabilities, there may be a reduction in performancesince the secondary device is required to take over the peer traffic load in addition to its current load.

Example: BIG-IP HA pair using active-standby mode

8 Chapter 3. Site Contents


Prerequisites

• Licensed, operational BIG-IP device, pair, or device cluster.

• Operational OpenStack cloud (Mitaka release).

• Administrator access to both BIG-IP device(s) and OpenStack cloud.

• Basic understanding of OpenStack networking concepts. See the OpenStack docs for more information.

• Basic understanding of BIG-IP® Local Traffic Management

• F5 agent and service provider driver installed on the Neutron controller and all other hosts from which you wantto provision LBaaS services.

3.2. Supported Features 9

http://docs.openstack.org/liberty/

https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm-basics-12-0-0.html

http://f5-openstack-agent.readthedocs.io/en/mitaka/index.html#home


Caveats

• If you only have one (1) BIG-IP deployed, you must use standalone mode.

• In this context, HA pertains to the BIG-IP device(s), not to the F5 agent.

Configuration

1. Edit the Agent Configuration File:

$ sudo emacs /etc/neutron/services/f5/f5-openstack-agent.ini

2. Set the f5_ha_type as appropriate for your environment.

• standalone: A single BIG-IP device

• pair: An active-standby pair of BIG-IP devices

• scalen: An active device service cluster of up to 4 BIG-IP devices

Example

## HA mode## Device can be required to be:## standalone - single device no HA# pair - active-standby two device HA# scalen - active device cluster##f5_ha_type = standalone#

Further Reading

See also:

• Introducing BIG-IP Device Service Clustering

• Creating an active-standby DSC configuration

• Creating an active-active DSC configuration

• Configuring load-aware failover

3.2.2 L2/L3 Segmentation Modes

Overview

The F5® agent uses the L2/L3 segmentation mode settings to determine the L2/L3 network configurations for yourBIG-IP® device(s).


https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/bigip-device-service-clustering-admin-12-0-0/2.html?sr=55108154

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

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

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


Warning: These settings must be configured correctly for the F5 agent to manage your BIG-IP(s). Knowledge ofnetworking concepts and BIG-IP configuration is required.

L2 segmentation mode settings include:

• Mapping VLANs to BIG-IP device interfaces (with or without tagging)

• Mapping VLAN tags to specific BIG-IP ports

• Device tunneling self IPs

• Tunnel types

L3 segmentation mode settings include:

• Global Routed Mode / Route domains

• SNAT Mode and SNAT Address Counts

• Common Networks

• L3 Bindings

Use Case

Typically, the F5 agent is used to manage one (1) or more BIG-IP devices deployed at the service layer of an externalprovider network. F5 LBaaSv2 makes it possible to provision services from your existing BIG-IP(s) in an OpenStackcloud. The F5 agent L2/L3 segmentation mode settings must match the configurations of your existing externalnetwork and BIG-IP device(s).

The default mode of operation for the F5 agent is L2 adjacent mode (f5_global_routed_mode = False).

Example: L2-adjacent BIG-IP cluster



Important: Knowledge of the external network configuration, and that of the BIG-IP device(s), is required toconfigure these settings.

Prerequisites

• Licensed, operational BIG-IP device or device cluster.


• Administrator access to both the BIG-IP device(s) and the OpenStack cloud.

• Knowledge of OpenStack Networking concepts.

• Knowledge of BIG-IP system configuration, local traffic management, & device service clustering.

• VLANs and VxLAN or GRE tunnels configured as as appropriate for your environment.

• If you are using GRE or VxLAN tunnels, you must have a BIG-IP license that supports SDN.


http://docs.openstack.org/liberty/networking-guide/

https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/bigip-system-initial-configuration-12-0-0/2.html#conceptid


https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/bigip-device-service-clustering-admin-12-0-0.html

https://f5.com/products/how-to-buy/simplified-licensing


Caveats

• Many L3 segmentation mode settings are dependent on how others are configured. It’s important to read the textin the agent configuration file carefully before changing these settings to ensure they don’t conflict.

Configuration

All settings can be configured by editing the Agent Configuration File:


See also:

• Sample Agent Configuration file for VLAN (no tunnels)

• Sample Agent Configuration file for GRE

• Sample Agent Configuration file for VXLAN

L2 Segmentation Mode Settings

Device VLAN to interface and tag mapping

• f5_external_physical_mappings: Maps VLANs to BIG-IP interfaces. Must use the following format:

physical_network:interface_name:tagged

• physical_network: The external physical network; corresponds to the Neutronprovider:physical_network attribute.

• interface_name: The name of a BIG-IP interface or LAG trunk

• tagged: Value must be True or False; indicates whether or not VLAN tagging should be enforced by theBIG-IP.

Example

################################################################################ 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: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 (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#



VLAN device and interface to port mappings

• vlan_binding_driver: Binds tagged VLANs to specific BIG-IP ports; it should be configured using avalid subclass of the iControl® VLANBindingBase class. 1 To use this feature, uncomment the line in theagent configuration file.

Device Tunneling (VTEP) selfips

• f5_vtep_folder: This is the name of the BIG-IP folder or partition in which the VTEP (VxLAN tunnelendpoint) resides; the default partition is ‘Common’.

• f5_vtep_selfip_name: The name of the self IP assigned to the VTEP.

Example

# 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 = Nonef5_vtep_selfip_name = None#

Tunnel Types

• advertised_tunnel_types: The type of tunnel(s) being used to connect the BIG-IP device(s) to con-troller/compute node(s) in OpenStack; can be GRE or VxLAN. Values should be comma-separated if more thanone tunnel type is being used. If you are not using tunnels, leave this setting blank.

Example

# Tunnel types## This is a comma separated list of tunnel types to report# as available from this agent as well as to send via tunnel_sync# rpc messages to compute nodes. This should match your ml2# network types on your compute nodes.## If you are using only gre tunnels it should be:## advertised_tunnel_types = gre## If you are using only vxlan tunnels it should be:#advertised_tunnel_types = vxlan## If this agent could get both gre and vxlan tunnel networks:## advertised_tunnel_types = gre,vxlan## If you are using only vlans only it should be:## advertised_tunnel_types =#

1 Unsupported in v 9.0.1


https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/bigip-tmos-tunnels-ipsec-12-0-0/3.html#unique_1403984487


Static ARP population for members on tunnel networks

• f5_populate_static_arp: Value must be True or False; indicates whether or not static arp entries areadded for pool member IP addresses that are associated with VxLAN or GRE tunnel networks.

• l2_population: Value must be True or False; indicates whether or not BIG-IP uses L2 population serviceto update fbd tunnel entries.

Example

# 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#...# This is a boolean entry which determines if the BIG-IP® will use# L2 Population service to update its fdb tunnel entries. This needs# to be setup in accordance with the way the other tunnel agents are# setup. If the BIG-IP® agent and other tunnel agents don't match# the tunnel setup will not work properly.#l2_population = True#

L3 Segmentation Mode Settings

Note: This section covers L3 Segmentation Mode Settings with the assumption that Global Routed Mode is set to‘False’. This is the default mode of operation.

Namespaces and Routing

• use_namespaces: Value must be True or False; indicates whether or not traffic should be routed accordingto tenant routing tables. Setting this value to True allows subnet IP addresses to overlap.

Example



# 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#

• max_namespaces_per_tenant: Value must be an integer; indicates the maximum number of route do-mains allowed per tenant. This allows a tenant to have overlapping IP subnets.

Example

# 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.## Supporting multiple IP namespaces allows establishing multiple independent# IP routing topologies within one tenant project, which, for example,# can accommodate multiple testing environments in one project, with# each testing environment configured to use the same IP address# topology as each other test environment.## From a practical point of view, allowing multiple IP namespaces# per tenant results in a more complicated configuration scheme# for big-ip and also allows a single tenant to consumes more# routing tables, which are a limited resource. In order to keep# a simple one-to-one strategy of one tenant to one route domain,# it is recommended that separate projects be used if possible to# establish a new routing namespace rather than allowing multiple route# domains within one tenant.## If a tenant attempts to use a subnet that overlaps with an existing# subnet that is already in use in the existing route domain(s), and# this setting is not high enough to accomodate a new route domain to# handle the new subnet, then the relevant lbaas element (vip or pool member)# will be set to the error state.#max_namespaces_per_tenant = 1#

• f5_route_domain_strictness: Value must be True or False; indicates whether VIPS and members indifferent tenants can communicate with each other. In other words, setting this value to true forces tenant routingtables to be preferred over the global routing table.

Example



# 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#

SNAT Mode and SNAT Address Counts

• f5_snat_mode: Value must be True or False; indicates whether or not SNATs should be used.

Tip: SNATs should be used when you need to ensure that server responses always return through the BIG-IP®system, or when you want to hide the source addresses of server-initiated requests from external devices.

• f5_snat_addresses_per_subnet: Value must be an integer; indicates the number of self IP addressesthe BIG-IP should put in a SNAT pool for each subnet associated with a self IP.

• f5_common_external_networks: Value must be True or False; when set to True, traffic on all Neutronnetworks for which the router type is external will be routed according to the global routing table.

Example

# SNAT Mode and SNAT Address Counts## This setting will force the use of SNATs.## If this is set to False, a SNAT will not# be created (routed mode) and the BIG-IP®# will attempt to set up a floating self IP# as the subnet's default gateway address.# and a wild card IP forwarding virtual# server will be set up on member's network.# Setting this to False will mean Neutron# floating self IPs will no longer work# if the same BIG-IP® device is not being used# as the Neutron Router implementation.## This setting will be forced to True if# f5_global_routed_mode = True.#f5_snat_mode = True## This setting will specify the number of snat# addresses to put in a snat pool for each# subnet associated with a created local Self IP.## Setting to 0 (zero) will set VIPs to AutoMap# SNAT and the device's local Self IP will# be used to SNAT traffic.## In scalen HA mode, this is the number of snat# addresses per active traffic-group at the time# a service is provisioned.## This setting will be forced to 0 (zero) if# f5_global_routed_mode = True.#f5_snat_addresses_per_subnet = 1## This setting will cause all networks with# the router:external attribute set to True# to be created in the Common partition and# placed in route domain 0.f5_common_external_networks = True#


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

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


Common Networks

• common_network_ids: This should be a ‘name-value’ pair; multiple values can be comma-separated. Thefirst entry is the Neutron network ID; the second is the network name (as configured on the BIG-IP).

Example

# Common Networks## This setting contains a name value pair comma# separated list where if the name is a neutron# network id used for a vip or a pool member,# the network should not be created or deleted# on the BIG-IP®, but rather assumed that the value# is the name of the network already created in# the Common partition with all L3 addresses# assigned to route domain 0. This is useful# for shared networks which are already defined# on the BIG-IP® prior to LBaaS configuration. The# network should not be managed by the LBaaS agent,# but can be used for VIPs or pool members## If your Internet VLAN on your BIG-IP® is named# /Common/external, and that corresponds to# Neutron uuid: 71718972-78e2-449e-bb56-ce47cc9d2680# then the entry would look like:## common_network_ids = 71718972-78e2-449e-bb56-ce47cc9d2680:external## If you had multiple common networks, they are simply# comma separated like this example:## common_network_ids = 71718972-78e2-449e-bb56-ce47cc9d2680:external,396e06a0-05c7-→˓4a49-8e86-04bb83d14438:vlan1222## The default is no common networks defined

L3 Binding

The L3 Binding driver is required for BIG-IP VE(s) deployed within your OpenStack cloud. This setting binds L3addresses to specific ports to allow communications between Nova guest instances.

• l3_binding_driver: uncomment this line in the agent configuration file if you’re using an overcloud VE.

Example

#l3_binding_driver = f5_openstack_agent.lbaasv2.drivers.bigip.l3_binding.→˓AllowedAddressPairs#



Further Reading

See also:

• BIG-IP System - Initial Configuration

• BIG-IP Local Traffic Management Basics

• BIG-IP Routing Administration Guide

• BIG-IP Device Service Clustering Administration

3.2.3 Global Routed Mode

Overview

The F5® agent determines BIG-IP® devices’ L2 and L3 network configurations based on the settings provided in theL2/L3 Segmentation Modes settings in the agent configuration file. When configured to use global routed mode, theF5 agent makes the following assumptions:

1. LBaaS objects are accessible via global L3 routes;

2. All virtual IPs are routable from clients;

3. All pool members are routable from BIG-IP.

This means that all L2 and L3 objects, including routes, must be provisioned on your BIG-IP devices before youconfigure the F5 agent to manage them.

Example: Global Routed Mode







Use Case

Global routed mode is generally used for undercloud BIG-IP hardware deployments. The BIG-IP device(s) is deployedin the external provider network at the service tier.

Global routed mode uses BIG-IP secure network address translation (SNAT) ‘automapping’ to map one or more originIP addresses to a pool of translation addresses. The pool is created by the BIG-IP Local Traffic Manager® (LTM)from existing self IP addresses. This means that before you configure the F5 agent to use global routed mode, youshould create enough self IP addresses on the BIG-IP(s) to handle anticipated connection loads. 1 You do not need toconfigure a SNAT pool, as one will be created automatically.

Prerequisites

• Licensed, operational BIG-IP device.



• F5 LBaaSv2 driver and agent installed on each server for which BIG-IP LTM services are required.

• Understanding of NATs and SNATs.

1 When using an overcloud BIG-IP Virtual Edition (VE), IP addresses may be allocated automatically.








Fig. 3.1: Example BIG-IP ‘undercloud’ deployment



• Sufficient self IP addresses for anticipated connection loads provisioned on the BIG-IP.

Caveats

• In global routed mode, the underlying assumption is that all VIP L3 addresses are globally routable. Setting thismode to True means that all VIPs listen on all VLANs accessible to the BIG-IP.

• Because only one global routing space is used on the BIG-IP, overlapping IP addresses between tenants is notsupported.

• All L3 routes must be set up on the BIG-IP before you provision LBaaS services.

Configuration



2. Configure global_routed_mode and its dependent features.

• global_routed_mode: When set to True, causes the agent to assume that all VIPs and pool membersare reachable via global device L3 routes

• use_namespaces: Forced to False; use of overlapping namespaces is not supported in global routedmode.

• f5_snat_mode: Forced to True; forces the use of automap SNATs to allocate self IP addresses toLBaaS objects.

• f5_snat_addresses_per_subnet: Forced to 0; the device’s local self IP is used to SNAT traffic.

• f5_common_external_networks: Value must be True or False; when set to True, all Neutron net-works with the router type external are added to the global routing table (the Common partition on theBIG-IP) and placed in route domain 0.

Example






################################################################################ L3 Segmentation Mode Settings################################################################################# Global Routed Mode - No L2 or L3 Segmentation on BIG-IP®## This setting will cause the agent to assume that all VIPs# and pool members will be reachable via global device# L3 routes, which must be already provisioned on the BIG-IP®s.#...#f5_global_routed_mode = True## 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 = False#...#...## SNAT Mode and SNAT Address Counts## This setting will force the use of SNATs.## If this is set to False, a SNAT will not# be created (routed mode) and the BIG-IP®# will attempt to set up a floating self IP# as the subnet's default gateway address.# and a wild card IP forwarding virtual# server will be set up on member's network.# Setting this to False will mean Neutron# floating self IPs will no longer work# if the same BIG-IP® device is not being used# as the Neutron Router implementation.## This setting will be forced to True if# f5_global_routed_mode = True.#f5_snat_mode = True## This setting will specify the number of snat# addresses to put in a snat pool for each# subnet associated with a created local Self IP.## Setting to 0 (zero) will set VIPs to AutoMap# SNAT and the device's local Self IP will# be used to SNAT traffic.#...## This setting will be forced to 0 (zero) if# f5_global_routed_mode = True.#f5_snat_addresses_per_subnet = 0#



3. Configure f5_common_external_networks.

Example

# This setting will cause all networks with# the router:external attribute set to True# to be created in the Common partition and# placed in route domain 0.f5_common_external_networks = True#

See also:

• Sample Agent Configuration file for Global Routed Mode

Further Reading

• TMOS Routing Overview

• BIG-IP AutoMap SNAT

3.2.4 Device Driver Settings / iControl® Driver Settings

Overview

The Device Driver Settings in the Agent Configuration File provide the means of communication between the F5®agent and BIG-IP® device(s). Do not change this setting.

The iControl® Driver Settings identify the BIG-IP device(s) that you want the F5 agent to manage and record the logininformation the agent will use to communicate with the BIG-IP(s).

Use Case

If you want to use the F5 agent to manage BIG-IP from within your OpenStack cloud, you must provide the correctinformation in this section of the agent config file. The F5 agent can manage a standalone device or a device servicecluster.

See also:

Managing BIG-IP Clusters with F5 LBaaS

Prerequisites




• Basic understanding of BIG-IP® system configuration.

• F5 agent and service provider driver installed on the Neutron controller and all other hosts for which you wantto provision LBaaS services.







Caveats

• vCMP® is unsupported in this release (v 9.0.1).

Configuration



2. Enter the iControl endpoint(s), username, and password for your BIG-IP(s).

• icontrol_hostname: The IP address(es) of the BIG-IP(s) the agent will manage. If you’re usingmultiple devices, provide a comma-separated list containing the management IP address of each device.

• icontrol_vcmp_hostname: Unsupported in this release.

• icontrol_username: The username of the adminstrative user; must have access to all BIG-IP devices.

• icontrol_password: The password of the adminstrative user; must have access to all BIG-IP devices.

Example

################################################################################ Device Driver - iControl® Driver Setting################################################################################# This setting can be either a single IP address or a# comma separated list containing all devices in a device# service group.## If a single IP address is used and the HA model# is not standalone, all devices in the sync failover# device group for the hostname specified must have# their management IP address reachable to the agent.# In order to access devices' iControl® interfaces via# self IPs, you should specify them as a comma# separated list below.#icontrol_hostname = 10.190.7.232 \\ replace with the IP address(es) of your BIG-→˓IP(s)## If you are using vCMP® with VLANs, you will need to configure# your vCMP host addresses, in addition to the guests addresses.# vCMP Host access is necessary for provisioning VLANs to a guest.# Use icontrol_hostname for vCMP guests and icontrol_vcmp_hostname# for vCMP hosts. The agent will automatically determine# which host corresponds to each guest.## icontrol_vcmp_hostname = 192.168.1.245## icontrol_username must be a valid Administrator username# on all devices in a device sync failover group.#icontrol_username = admin## icontrol_password must be a valid Administrator password# on all devices in a device sync failover group.#icontrol_password = admin#3.2. Supported Features 25


3.2.5 Certificate Manager / SSL Offloading

Overview

OpenStack’s ‘Barbican’ certificate manager provides a secure location where users can store sensitive information,such as SSH keys, private keys, certificates, and user passwords (referred to as “secrets ” in OpenStack lingo).

The F5® agent uses Barbican certificates to perform SSL offloading on BIG-IP®. It allows users to either create a newSSL profile, or to designate an existing BIG-IP SSL profile as the parent from which client profiles created for LBaaSobjects will inherit settings.

In general, SSL offloading frees up server and application capacity for handling traffic by shifting authenticationprocessing from the target server to a designated authentication server. As shown in the diagram, once an admin userhas added secrets to a Barbican container, he can use it to create a TLS loadbalancer. After the certificate data isvalidated, the F5® agent configures the loadbalancer on the BIG-IP.

Fig. 3.2: SSL Offloading with OpenStack Barbican, Neutron LBaaSv2, and BIG-IP

Use Case

When you configure Client SSL or Server SSL profiles and assign them to a virtual server, BIG-IP offloads SSLprocessing from the destination server. This not only conserves resources on the destination servers, but also enablesthe BIG-IP to customize SSL traffic processing according to your specifications.

Client SSL is the most common use case; this makes it possible for the BIG-IP to decrypt client requests before sendingthem on to a server, and encrypt server responses before sending them back to the client.


http://developer.openstack.org/api-guide/key-manager/secrets.html

https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/bigip-ssl-administration-12-0-0/5.html#unique_527799714

http://developer.openstack.org/api-guide/key-manager/secrets.html





Prerequisites

• Licensed, operational BIG-IP device.



• F5 LBaaSv2 driver and agent installed on each server for which BIG-IP LTM services are required.

• OpenStack Barbican certificate manager configured and operational.

• Existing BIG-IP SSL profile (optional).

Caveats

None.

Configuration



2. Provide the Keystone authentication data for your environment.

• auth_version: Keystone version (v2 or v3)

• os_auth_url: Keystone authentication URL

• os_username: OpenStack username

• os_password: OpenStack password

• os_tenant_name: OpenStack tenant name (v2 only)

• os_user_domain_name: OpenStack domain in which the user account resides (v3 only)

• os_project_name: OpenStack project name (v3 only; refers to the same data as os_tenant_namein v2)

• os_project_domain_name: OpenStack domain in which the project resides

Example

#cert_manager = f5_openstack_agent.lbaasv2.drivers.bigip.barbican_cert.→˓BarbicanCertManager \\ DO NOT CHANGE## Two authentication modes are supported for BarbicanCertManager:# keystone_v2, and keystone_v3### Keystone v2 authentication:## auth_version = v2# os_auth_url = http://localhost:5000/v2.0# os_username = admin# os_password = changeme# os_tenant_name = admin### Keystone v3 authentication:#auth_version = v3os_auth_url = http://localhost:5000/v3os_username = adminos_password = changemeos_user_domain_name = defaultos_project_name = adminos_project_domain_name = default#





3. Set the BIG-IP parent SSL profile.

• f5_parent_ssl_profile: The parent SSL profile on the BIG-IP® from which the agent SSL profileshould inherit settings

Example

# Parent SSL profile name## A client SSL profile is created for LBaaS listeners that use TERMINATED_HTTPS# protocol. You can define the parent profile for this profile by setting# f5_parent_ssl_profile. The profile created to support TERMINATED_HTTPS will# inherit settings from the parent you define. This must be an existing profile,# and if it does not exist on your BIG-IP® system the agent will use the default# profile, clientssl.#f5_parent_ssl_profile = clientssl#

3.3 F5 OpenStack LBaaSv2 User Guide

This guide provides instructions for installing and using the F5® OpenStack LBaaSv2 service provider driver andagent (also sometimes referred to as the ‘F5 LBaaSv2 plugin’).

3.3.1 Release

Release 9.0.1

3.3.2 Compatibility

This release is compatible with OpenStack Mitaka. For more information, please see the F5® OpenStack Releases,Versioning, and Support Matrix.

3.3.3 Overview

The F5® OpenStack LBaaSv2 service provider driver and agent (also called, simply, ‘F5 LBaaSv2’) make it possibleto provision F5 BIG-IP® Local Traffic Manager (LTM®) services in an OpenStack cloud.

How the plugin works

The F5 LBaaSv2 plugin consists of an agent and a service provider driver (also just called ‘driver’, for short). Thedriver listens to the Neutron RPC messaging queue. When you make a call to the LBaaSv2 API – for example,neutron lbaas-loadbalancer-create – the F5 LBaaSv2 service provider driver picks it up and directs itto the agent.

The F5 agent manages services on your BIG-IP. When it first receives a task from the F5 driver, it starts and commu-nicates with the BIG-IP(s) identified in the agent configuration file. Then, it registers its own named queue. The F5driver assigns all lbaas tasks in the Neutron messaging queue to the agent’s queue. The F5 agent makes callbacks




https://f5.com/products/modules/local-traffic-manager



to the F5 driver to query additional Neutron network, port, and subnet information; to allocate Neutron objects (forexample, fixed IP addresses); and to report provisioning and pool status.

3.3.4 Before You Begin

In order to use F5® LBaaSv2 services, you will need the following:


• Licensed, operational BIG-IP® device or device cluster; can be deployed either as an OpenStack instance (BIG-IP VE) or external to the cloud (VE or hardware).

Important: You must have the appropriate license for the BIG-IP features you wish to use. Forexample, the use of GRE or VxLAN tunnels requires an active BIG-IP SDN Services License.

• Basic understanding of OpenStack networking concepts.

• Basic understanding of BIG-IP Local Traffic Management

• F5 service provider package installed on Neutron controller.

Install the F5 Service Provider Package

Install the F5 LBaaSv2 service provider package before you install the F5 LBaaSv2 driver. If the F5 service providerpackage isn’t present on your Neutron controller, the F5 LBaaSv2 driver will not work.

Download the F5 LBaaSv2 service provider package and add it to the python path for neutron_lbaas.

1. Download from GitHub

$ curl -O -L https://github.com/F5Networks/neutron-lbaas/releases/download/v8.0.1/→˓f5.tgz

2. Install the service provider package.

1. CentOS:$ sudo tar xvf f5.tgz -C /usr/lib/python2.7/site-packages/neutron_lbaas/drivers/

2. Ubuntu:$ sudo tar xvf f5.tgz -C /usr/lib/python2.7/dist-packages/neutron_lbaas/drivers/

Install the F5 Agent

See the F5 Agent documentation for installation instructions.

The F5 agent should, at minimum, be installed on your Neutron controller. You can also install it on any host fromwhich you want to use F5 LBaaSv2 to provision BIG-IP services.

3.3.5 Install the F5 LBaaSv2 Driver

Tip:

3.3. F5 OpenStack LBaaSv2 User Guide 29

https://f5.com/products/how-to-buy/simplified-licensing





• You must have both pip and git installed on your machine in order to use these commands.

• It may be necessary to use sudo, depending on your environment.

To install the f5-openstack-lbaasv2-driver package for the v 9.0.1 release:

$ sudo pip install git+https://github.com/F5Networks/f5-openstack-lbaasv2-driver@v9.→˓0.1

3.3.6 Upgrading the F5 LBaaSv2 Components

If you are upgrading from an earlier version, F5® recommends that you uninstall the current version, then install thenew version.

Warning: Using pip install --upgrade to upgrade the F5 LBaaSv2 agent can impact packages that areused by other OpenStack components. We strongly urge all users to follow these instructions instead.

To upgrade, perform the following steps on every server on which the F5 agent is running.

Make a copy of the F5 agent configuration file

The existing configuration file in /etc/neutron/services/f5/ will be overwritten when you install the new package.

$ cp /etc/neutron/services/f5/f5-openstack-agent.ini ~/

Stop and remove the current version of the F5 agent

Debian/Ubuntu

$ sudo service f5-oslbaasv2-agent stop$ pip uninstall f5-openstack-agent

Red Hat/CentOS

$ sudo systemctl stop f5-openstack-agent$ sudo systemctl disable f5-openstack-agent$ sudo pip uninstall f5-openstack-agent

Install the new version of the F5 agent

Follow the agent installation instructions to install the version to which you’d like to upgrade.




Restore the F5 agent configuration file

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

$ cp ~/f5-openstack-agent.ini /etc/neutron/services/f5/f5-openstack-agent.ini

3.3.7 Configure Neutron for LBaaSv2

You will need to make a few configurations in your Neutron environment in order to use the F5® OpenStack LBaasv2driver and agent.

First, you’ll need to set F5 Networks® as the Neutron LBaaSv2 service provider driver. Then, add the LBaaSv2 pluginto the list of service plugins in the Neutron configuration file.

Set ‘F5Networks’ as the LBaaSv2 Service Provider

Edit the service_providers section of /etc/neutron/neutron_lbaas.conf as shown below to set‘F5Networks’ as the LBaaSv2 service provider.

$ vi /etc/neutron/neutron_lbaas.conf...[service_providers]service_provider = LOADBALANCERV2:F5Networks:neutron_lbaas.drivers.f5.driver_→˓v2.F5LBaaSV2Driver:default...

Note: If there is an active entry for the F5® LBaaSv1 service provider driver, comment (#) it out.

Add the Neutron LBaaSv2 Service Plugin

Edit the [DEFAULT] section of the Neutron config file – /etc/neutron/neutron.conf.

1. Add the lbaasv2 service plugin as shown below.

$ vi /etc/neutron/neutron.conf...[DEFAULT]service_plugins = [already defined plugins],neutron_lbaas.services.→˓loadbalancer.plugin.LoadBalancerPluginv2...

2. Remove the entry for the LBaaSv1 service plugin (lbaas).

Restart Neutron

Use the command appropriate for your OS to restart the neutron-server service.

$ sudo service neutron-server restart \\ Ubuntu$ sudo systemctl restart neutron-server \\ CentOS



3.3.8 Configure the F5 OpenStack Agent

Overview

To use the F5® OpenStack agent, edit the agent configuration file as appropriate for your environment.

Example:

$ sudo vi /etc/neutron/services/f5/f5-openstack-agent.ini

All of the agent’s functions are described in detail in the configuration file. Please see Supported Features for a list ofthe features supported in 9.0.1, with configuration examples for each feature.

Start the F5® OpenStack Agent

Once you have configured the F5® agent as appropriate for your environment, use the command(s) appropriate foryour OS to start the agent.

Debian/Ubuntu

$ sudo service f5-oslbaasv2-agent start

RedHat/CentOS

$ sudo systemctl enable f5-openstack-agent$ sudo systemctl start f5-openstack-agent

Stop the F5® OpenStack agent

If you need to stop the F5® agent, run the command appropriate for your OS.

Debian/Ubuntu

$ sudo service f5-oslbaasv2-agent stop

RedHat/CentOS

$ sudo systemctl stop f5-openstack-agent.service

See also:

• F5 BIG-IP LTM Product Support

• F5 BIG-IP User Guides


https://support.f5.com/kb/en-us/products/big-ip_ltm.html

https://support.f5.com/kb/en-us/search.res.html?productList=big-ip_ltm&versionList=11-6-0&searchType=advanced&isFromGSASearch=false&query=&site=support_internal&client=support-f5-com&prodName=BIG-IP+LTM&prodVersText=11.6.0&docTypeName=Manual&q=&submit_form=&product=big-ip_ltm&pubDateFilter=all&productVersion=11-6-0&updatedDateFilter=all&documentType=manualpage&includeArchived=false


3.3.9 F5 OpenStack LBaaSv2 Deployments

This section features common BIG-IP® deployments that can be managed in OpenStack with F5® LBaaS.

Managing BIG-IP Clusters with F5 LBaaS

Overview

The F5® LBaaSv2 agent and driver can manage BIG-IP® device service clusters, providing high availability, mirror-ing, and failover services within your OpenStack cloud.

The F5 agent applies LBaaS configuration changes to each BIG-IP device in a cluster at the same time, in real time.It is unnecessary to use BIG-IP’s ‘configuration synchronization mode’ to sync LBaaS objects managed by the agentacross the devices in a cluster.

Clustering provides a greater degree of redundancy than a standalone device offers. It helps to avoid service interrup-tions that could otherwise occur if a device should go down. F5 LBaaSv2 can manage BIG-IP Sync-Failover devicegroups when set to use either the pair or the scalen High Availability mode.

Example: BIG-IP scalen cluster

Prerequisites

• Basic understanding of BIG-IP® device service clustering.


https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/bigip-device-service-clustering-admin-12-0-0/6.html#unique_1589362110





• Licensed, operational BIG-IP device service cluster.

Tip: If you do not already have a BIG-IP cluster deployed in your network, you can use the F5BIG-IP: Active-Standby Cluster Heat template to create a two-device cluster.


• Administrator access to both BIG-IP devices and OpenStack cloud.


Caveats

• The F5 agent can manage clusters of two (2) to four (4) BIG-IP devices. Active-standby mode can only be usedwith two (2) devices; scalen is used with clusters of more than two devices.

• The administrator login must be the same on all BIG-IP devices in the cluster.

Configuration



2. Set the HA mode to pair or scalen.

# HA mode## Device can be required to be:## standalone - single device no HA# pair - active-standby two device HA# scalen - active device cluster##f5_ha_type = pair##

3. Add the IP address for each BIG-IP device, the admin username, and the admin password to the Device Driver- iControl® Driver Setting section of the config file. Values must be comma-separated.

#icontrol_hostname = 10.190.7.232,10.190.4.193#icontrol_username = admin#icontrol_password = admin#

Further Reading

See also:


http://f5-openstack-heat.readthedocs.io/en/latest/templates/supported/ref_f5-plugins_active-standby.html

http://f5-openstack-heat.readthedocs.io/en/latest/templates/supported/ref_f5-plugins_active-standby.html



• BIG-IP Device Service Clustering – Administration Guide

Managing Multi-Tenant BIG-IP Devices with F5 LBaaS

Overview

BIG-IP® devices allow users to create and customize partitions for which specific features that meet a tenant’s needscan be enabled. This type of configuration, called multi-tenancy, allows a greater degree of flexibility in allocatingnetwork resources to multiple individual projects. 1

Example: Multi-tenant BIG-IP and F5 LBaaS

Prerequisites





• Knowledge of OpenStack Networking concepts.

• Knowledge of BIG-IP system configuration, local traffic management, & device service clustering.

Caveats

When using BIG-IP Virtual Edition (VE) with the Linux bridge or Open vSwitch Neutron core plugins, F5 LBaaS canbe deployed in two ways:

1 In OpenStack, the terms ‘tenant’ and ‘project’ are used interchangeably.








1. Global Routed Mode: BIG-IP VE is connected only to provider networks; all pool member L3 addresses mustbe routable using cloud infrastructure routers.

2. L2 Segmentation Modes using GRE or VxLAN tunnels: BIG-IP VE has a data connection to a provider networkwhich can route IP packets to the local_ip VTEP addresses of the compute and network nodes through acloud infrastructure router.

Configuration



2. Configure the L2 Segmentation Mode Settings as appropriate for your environment.

• Device VLAN to interface and tag mapping

• interface_name: The name of a BIG-IP interface or LAG trunk

• tagged: Value must be True or False; indicates whether or not VLAN tagging should beenforced by the BIG-IP.

• VLAN device and interface to port mappings

• Device Tunneling (VTEP) selfips (if using VxLAN or GRE tunnels)

• f5_vtep_folder: This is the name of the BIG-IP folder or partition in which the ‘VTEP‘_(VxLAN tunnel endpoint) resides; the default partition is ‘Common’.

• f5_vtep_selfip_name: The name of the self IP assigned to the VTEP.

• Tunnel Types

• advertised_tunnel_types: The type of tunnel(s) being used to connect the BIG-IP de-vice(s) to controller/compute node(s) in OpenStack; can be GRE or VxLAN. Values should becomma-separated if more than one tunnel type is being used. If you are not using tunnels, leavethis setting blank.

• Static ARP population for members on tunnel networks

• f5_populate_static_arp: Value must be True or False; indicates whether or not staticarp entries are added for pool member IP addresses that are associated with VxLAN or GREtunnel networks.

• l2_population: Value must be True or False; indicates whether or not BIG-IP uses L2population service to update fbd tunnel entries.

Important: You must configure these settings correctly to ensure your tenant networks connect to the right interfaceson the BIG-IP(s) and that traffic is allowed to flow through the corresponding ports.

3.3.10 Troubleshooting

Set Logging Level to DEBUG

To troubleshoot general problems, set the Neutron and the F5® agent debug setting to True.

Extensive logging will then appear in the neutron-server and f5-oslbaasv1-agent log files on their re-spective hosts.



Set the DEBUG log level output for the f5-openstack-agent:

$ vi /etc/neutron/services/f5/f5-openstack-agent.ini

#[DEFAULT]# Show debugging output in log (sets DEBUG log level output).debug = True...

Set the DEBUG log level output for Neutron:

$ vi /etc/neutron/neutron.confDEBUG = T

F5® Agent is not running

If f5-openstack-agent or f5-oslbaasv2-agent doesn’t appear in the Horizon agent list, or when you runneutron agent-list, the agent is not running.

Here are a few things you can try:

1. Check the logs:

$ less /var/log/neutron/f5-openstack-agent.log

2. Check the status of the f5-openstack-agent service:

$ sudo service f5-oslbaasv2-agent status \\ Debian/Ubuntu$ sudo systemctl status f5-openstack-agent.service \\ RedHat/CentOS

3. Make sure you can connect to the BIG-IP® and that the iControl® hostname, username, and password in theconfig file are correct.

4. If you’re using global_routed_mode, comment out (#) the vtep lines (shown below) in the agent configfile.

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

5. If you’re using L2 segmentation, make sure the advertised_tunnel_types setting matches theprovider:network_type.

$ neutron net-show <network_name>+---------------------------+--------------------------------------+| Field | Value |+---------------------------+--------------------------------------+| admin_state_up | True || id | 05f61e74-37e0-4c30-a664-762dfef1a221 || mtu | 0 || name | bigip_external |



| provider:network_type | vxlan || provider:physical_network | || provider:segmentation_id | 84 || router:external | False || shared | False || status | ACTIVE || subnets | || tenant_id | 1a35d6558b59423e83f4500f1ebc1cec |+---------------------------+--------------------------------------+

F5® Agent is not provisioning LBaaS tasks correctly

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

If you see more than one entry for f5-openstack-agent or f5-oslbaasv2-agent and youhaven’t configured your host to use multiple agents, you’ll need to deactivate one of them. Thecommands below may help you to identify which agent to deactivate.

$ neutron agent-list\\ list all running agents

$ neutron agent-show <agent_id>\\ show the details for a specific agent

$ neutron lbaas-loadbalancer-list-on-agent <agent_id>\\ list the loadbalancers on the agent.

$ neutron lbaas-loadbalancer-show <loadbalancer_id>\\ Show the details for a specific loadbalancer

3.4 F5® OpenStack LBaaSv2 Coding Example

We’ve provided some code examples below to help you get started with the F5® OpenStack LBaaSv2 agent and driver.This series demonstrates how to configure basic load balancing via the Neutron CLI. To access the full Neutron LBaaScommand set, please see the OpenStack CLI Documentation. LBaaSv2 commands all begin with lbaas.

3.4.1 Create a load balancer

Use the command below to create a load balancer, specifying the load balancer name and its VIP subnet.

$ neutron lbaas-loadbalancer-create --name lb1 private-subnet

3.4.2 Create a listener

Use the command below to create a listener for the load balancer specifying the listener name, load balancer name,protocol type, and protocol port.

$ neutron lbaas-listener-create --name listener1 --loadbalancer lb1 --protocol HTTP --→˓protocol-port 80


http://docs.openstack.org/cli-reference/neutron.html


3.4.3 Create a pool

Use the command below to create a pool for the listener specifiying the pool name, load balancing method, listenername, and protocol type.

$ neutron lbaas-pool-create --name pool1 --lb-algorithm ROUND_ROBIN --listener→˓listener1 --protocol HTTP

3.4.4 Create a pool member

Use the command below to create a member for the pool, specifying the subnet, IP address, and protocol port.

$ neutron lbaas-member-create --subnet private-subnet --address 172.16.101.89 --→˓protocol-port 80 pool1

3.4.5 Create a health monitor

Use the command below to create a health monitor for the pool specifying the delay, monitor type, number of retries,timeout period, and pool name.

$ neutron lbaas-healthmonitor-create --delay 3 --type HTTP --max-retries 3 --timeout→˓3 --pool pool1

3.4.6 Create a tls load balancer

The example command below shows how to create a listener that uses the TERMINATED_HTTPS protocol. You’llneed to specify the protocol (TERMINATED_HTTPS); port; and the location of the Barbican container where thecertificate is stored.

$ neutron lbaas-listener-create --name listener2 --protocol TERMINATED_HTTPS --→˓protocol-port 8443 --loadbalancer lb1 --default-tls-container-ref http://localhost:→˓9311/v1/containers/db50dbb3-70c2-44ea-844c-202e06203488

Important: You must configure Barbican, Keystone, Neutron, and the F5® agent before you can create a tls loadbalancer.

See the OpenStack LBaaS documentation for further information and configuration instructions for the OpenStackpieces.

The necessary F5® agent configurations are described in Certificate Manager / SSL Offloading.

3.5 Glossary

active-active Both BIG-IP devices in a pair are in an active state, processing traffic for different virtual servers orSNATs. If one device fails over, the remaining device processes traffic from the failed device in addition to itsown traffic.

3.5. Glossary 39

http://docs.openstack.org/developer/barbican/api/quickstart/containers.html

https://wiki.openstack.org/wiki/Network/LBaaS/docs/how-to-create-tls-loadbalancer

https://f5.com/products/big-ip


active-standby Only one of the two BIG-IP devices is in an active state – that is, processing traffic – at any giventime. If the active device fails over, the second device enters active mode and processes traffic that was originallytargeted for the primary device.

cluster

clustered

clustering

device cluster

device service cluster

device service clusters

device service group

DSC

DSG Two (2) or more BIG-IP devices configured to use high availability features, providing synchronization andfailover of BIG-IP configuration data among multiple BIG-IP devices on a network. A clustered BIG-IP devicecan synchronize some or all of its configuration data among several BIG-IP devices; fail over to one of manyavailable devices; mirror connections to a peer device to prevent interruption in service during failover.

device BIG-IP hardware or virtual edition (VE).

failover

fail over

fails over Failover occurs when one device in an active-standby pair becomes unavailable; the secondary deviceprocesses traffic that was originally targeted for the primary device.

high availability

highly available

HA The ability of a BIG-IP device to process network traffic successfully. An HA device is generally part of a devicecluster.

mirror

mirroring A BIG-IP system redundancy feature that ensures connection and persistence information is shared toanother device in a device service cluster; mirroring helps prevent service interruptions if/when failover occurs.

multi-arm

multiple-arm

multi-arm mode

multiple-arm mode Multi-arm mode is a network topology wherein servers/clients connect to the BIG-IP via differ-ent interfaces; two or more VLANs can be used to handle management and data traffic.

one-arm

one-arm mode One-arm mode is a network topology wherein servers/clients connect to the BIG-IP via a singleinterface; a single VLAN handles all traffic.

overcloud BIG-IP virtual edition (VE) deployed as an OpenStack instance.

pair Two (2) BIG-IP devices configured to use the active-standby HA mode.

scalen Two (2) or more BIG-IP devices configured as an active device cluster.











SSL offloading SSL offloading relieves a Web server of the processing burden of encrypting and/or decrypting trafficsent via SSL, the security protocol that is implemented in every Web browser. For more information, see the F5Glossary.

standalone A single BIG-IP device; no HA.

undercloud BIG-IP device (hardware or VE) deployed outside of OpenStack.

3.5. Glossary 41

https://f5.com/glossary/ssl-offloading

https://f5.com/glossary/ssl-offloading



Index

Aactive-active, 39active-standby, 40

Ccluster, 40clustered, 40clustering, 40

Ddevice, 40device cluster, 40device service cluster, 40device service clusters, 40device service group, 40DSC, 40DSG, 40

Ffail over, 40failover, 40fails over, 40

HHA, 40high availability, 40highly available, 40

Mmirror, 40mirroring, 40multi-arm, 40multi-arm mode, 40multiple-arm, 40multiple-arm mode, 40

Oone-arm, 40one-arm mode, 40overcloud, 40

Ppair, 40

Sscalen, 40SSL offloading, 41standalone, 41

Uundercloud, 41

43

F5 OpenStack LBaaSv2Documentation - Read the Docs · 3.3 F5 OpenStack LBaaSv2 User Guide ... This...

Documents

Transcript of F5 OpenStack LBaaSv2Documentation - Read the Docs · 3.3 F5 OpenStack LBaaSv2 User Guide ... This...