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. This announcement is in compliance with the OpenStack community deprecation of the OpenStack Neutron LBaaS version 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 the Openstack Ocata release in April 2017.
For additional information, please refer to the F5 End of Life policy.
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.
The F5® LBaaSv1 plugin supports the following Neutron network topologies which require dynamic L2 and L3 provisioning of BIG-IP® devices.
Fig. 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 LBaaSv1 services.
Global routed mode uses BIG-IP® AutoMap SNAT® for all VIPs. Because no explicit SNAT pools are defined, you should 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 |
+--------------------------------------+--------------------------------------+
Fig. 6 L2 Adjacent Mode
Important
L2 adjacent mode is the default mode.
In L2 adjacent mode, the F5® agent provisions L2 networks – including VLANs and overlay tunnels – by associating a specific BIG-IP® device with each tenant network that has a VIP or pool member. L3 addresses for BIG-IP® SelfIPs and SNATs are dynamically allocated from Neutron tenant subnets associated with LBaaSv1 VIPs or members. VIP listeners 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 pass through another L3 forwarding device. Instead, traffic flows are restricted to direct L2 communication between the cloud network element and the BIG-IP®.
+--------------------------------------+--------------------------------------+
| Topology | f5-oslbaasv1-agent.ini setting |
+======================================+======================================+
| L2 Adjacent mode | f5_global_routed_mode = False |
+--------------------------------------+--------------------------------------+
Fig. 7 One-arm Mode
In a one-arm deployment, BIG-IP® has a single (hence, one-arm) connection to the router. VIPs and members are provisioned from a single Neutron subnet. Use of SNATs is required; you can opt to either allocate SNAT addresses automatically, 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, |
| | n number of SNAT addresses will be |
| | allocated from the member subnet per |
| | active traffic group. |
+--------------------------------------+--------------------------------------+
Fig. 8 Multiple-arm Mode
Multiple-arm mode is, essentially, multiple one-arm deployments. In each arm, VIPs and members are provisioned from a specific Neutron subnet.
+--------------------------------------+--------------------------------------+
| Topology | f5-oslbaasv1-agent.ini setting |
+======================================+======================================+
| Multiple-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, |
| | n number of SNAT addresses will be |
| | allocated from the member subnet per |
| | active traffic group. |
+--------------------------------------+--------------------------------------+
Fig. 9 Gateway Routed Mode
In gateway routed mode, the F5® agent attempts to create a default gateway forwarding service on the BIG-IP® for member Neutron subnets.
+--------------------------------------+--------------------------------------+
| Topology | f5-oslbaasv1-agent.ini setting |
+======================================+======================================+
| Gateway routed mode | f5_global_routed_mode = False |
| | f5_snat_mode = False |
| | |
+--------------------------------------+--------------------------------------+
Fig. 10 Device VLAN to interface and tag mapping
In order to establish connectivity between a BIG-IP® and VLAN, you need to map an interface on the BIG-IP® to an interface on the physical network. In the example below, the BIG-IP interface 1.1 is mapping to the eth0 interface on the hypervisor on which it’s running; in turn, eth0 maps to the bridges that provide connectivity from the compute node to 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’s good practice to include a default mapping, for cases where the provider:physical_network
does not match any configuration settings. A default mapping simply uses the word ‘default’ instead of a known provider:physical_network
attribute.
###############################################################################
# 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
#
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’s tunneling_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 access are only built to Open vSwitch agents hosting Members. When using the ML2 population service, you can also elect 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
The necessary ML2 port binding extensions and segmentation model are defined by default with the community ML2 core 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 the Open vSwitch agents to inform them of BIG-IP® device VTEPs. This allows tenant guest virtual machines or network node 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 are listed 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 |
| topic | f5-lbaas-process-on-agent |
+---------------------+-----------------------------------------------------------------------+