Cloud Docs Home > F5 OpenStack LBaaSv2 Index

Troubleshooting¶

Tip

If you can’t find objects on your BIG-IP that you created using F5 LBaaSv2, check your partition. By default, all objects are created in a partition that is named with the OpenStack tenant ID and the preface ‘Project_’.

Example: Project_9572afc14db14c8a806d8c8219446e7b

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 respective hosts.

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

$ sudo 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:

$ sudo vi /etc/neutron/neutron.conf
[DEFAULT]
...
# Print debugging output (set logging level to DEBUG instead of default WARNING level).
debug = True

F5 agent is not running¶

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

Here are a few things you can try:

Check the logs:

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

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

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

Make sure you can connect to the BIG-IP® and that the iControl® hostname, username, and password in the Agent Configuration File are correct.
If you’re using global_routed_mode, comment out (#) the vtep lines (shown below) in the Agent Configuration File.
# #f5_vtep_folder = 'Common' #f5_vtep_selfip_name = 'vtep' #

If you’re using L2 segmentation, make sure the advertised_tunnel_types setting from the Agent Configuration File matches the provider:network_type displayed for the network in Neutron. If it doesn’t, the network may be configured incorrectly.

$ 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¶

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 you haven’t configured your host to use multiple agents, you’ll need to deactivate one of them. The commands 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 load balancer

Make sure you’re not running LBaaSv1 and LBaaSv2 at the same time.

In the Neutron configuration file (/etc/neutron/neutron.conf), remove the entry for the lbaasv1 plugin, if it exists.

Correct

service_plugins = router,lbaasv2
\\ OR \\
service_plugins = router,neutron_lbaas.services.loadbalancer.plugin.LoadBalancerPluginv2

Incorrect

service_plugins = router,lbaas,lbaasv2

In the Neutron LBaaS configuration file (/etc/neutron/neutron_lbaas.conf), remove or comment out (#) the entry for the F5 LBaaSv1 service provider driver.

[service_providers]
service_provider = LOADBALANCERV2:F5Networks:neutron_lbaas.drivers.f5.driver_v2.F5LBaaSV2Driver:default
# 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:default
# service_provider = LOADBALANCER:F5:f5.oslbaasv1driver.drivers.plugin_driver.F5PluginDriver:default
# service_provider = LOADBALANCER:Haproxy:neutron_lbaas.services.loadbalancer.drivers.haproxy.plugin_driver.HaproxyOnHostPluginDriver:default
# service_provider = LOADBALANCER:radware:neutron_lbaas.services.loadbalancer.drivers.radware.driver.LoadBalancerDriver:default
# service_provider = LOADBALANCER:NetScaler:neutron_lbaas.services.loadbalancer.drivers.netscaler.netscaler_driver.NetScalerPluginDriver
# service_provider = LOADBALANCER:Embrane:neutron_lbaas.services.loadbalancer.drivers.embrane.driver.EmbraneLbaas:default
# service_provider = LOADBALANCER:A10Networks:neutron_lbaas.services.loadbalancer.drivers.a10networks.driver_v1.ThunderDriver:default
# service_provider = LOADBALANCER:VMWareEdge:neutron_lbaas.services.loadbalancer.drivers.vmware.edge_driver.EdgeLoadbalancerDriver:default

# LBaaS v2 drivers
# service_provider = LOADBALANCERV2:Octavia:neutron_lbaas.drivers.octavia.driver.OctaviaDriver:default
# service_provider = LOADBALANCERV2:radwarev2:neutron_lbaas.drivers.radware.v2_driver.RadwareLBaaSV2Driver:default
# service_provider = LOADBALANCERV2:LoggingNoop:neutron_lbaas.drivers.logging_noop.driver.LoggingNoopLoadBalancerDriver:default
# service_provider = LOADBALANCERV2:Haproxy:neutron_lbaas.drivers.haproxy.plugin_driver.HaproxyOnHostPluginDriver:default
# service_provider = LOADBALANCERV2:A10Networks:neutron_lbaas.drivers.a10networks.driver_v2.ThunderDriver:default
# service_provider = LOADBALANCERV2:brocade:neutron_lbaas.drivers.brocade.driver_v2.BrocadeLoadBalancerDriver:default
# service_provider = LOADBALANCERV2:kemptechnologies:neutron_lbaas.drivers.kemptechnologies.driver_v2.KempLoadMasterDriver:default

VxLAN traffic is not reaching BIG-IP¶

Make sure the vtep endpoint identified in the Agent Configuration File is set to ‘Allow All’.

The default setting for port lockdown behavior does not include VxLAN traffic. Setting the vtep to ‘Allow All’ will ensure that VxLAN traffic from the OpenStack cloud is not blocked by the BIG-IP.

Check the VxLAN port binding.

If you’re using the default Open vSwitch (ovs) core plugin, you can run the command ovs-vsctl show to view a list of configured bridges and associated ports. As shown in the example below, there should be a remote_ip address for a VxLAN tunnel that corresponds to the self IP identified in the Agent Configuration File.

Example: The code blocks below demonstrate that the ovs br-tun interface contains a port on which the remote_ip address matches that of the vtep self IP.

[user@host-19 ~(keystone_user)]$ sudo ovs-vsctl show
f08cd9da-cf33-4bc6-bdd2-960caed1136c
Bridge br-ex
    ...
Bridge br-tun
    fail_mode: secure
    Port "vxlan-c9001901"
        Interface "vxlan-c9001901"
            type: vxlan
            options: {df_default="true", in_key=flow, local_ip="201.0.20.1", out_key=flow, remote_ip="201.0.25.1"}
    Port br-tun
        Interface br-tun
            type: internal
    Port "vxlan-0a020264"
        Interface "vxlan-0a020264"
            type: vxlan
            options: {df_default="true", in_key=flow, local_ip="201.0.20.1", out_key=flow, remote_ip="10.2.2.100"}
    Port patch-int
        Interface patch-int
            type: patch
            options: {peer=patch-tun}
    Port "gre-c9001901"
        Interface "gre-c9001901"
            type: gre
            options: {df_default="true", in_key=flow, local_ip="201.0.20.1", out_key=flow, remote_ip="201.0.25.1"}
    Port "vxlan-c9001801"
        Interface "vxlan-c9001801"
            type: vxlan
            options: {df_default="true", in_key=flow, local_ip="201.0.20.1", out_key=flow, remote_ip="201.0.24.1"}
    Port "gre-c9001801"
        Interface "gre-c9001801"
            type: gre
            options: {df_default="true", in_key=flow, local_ip="201.0.20.1", out_key=flow, remote_ip="201.0.24.1"}
Bridge br-int
    ...
ovs_version: "2.5.0"

root@(localhost)(cfg-sync Standalone)(Active)(/Common)(tmos.net)# list self vtep
net self vtep {
    address 10.2.2.100/16
    allow-service all
    traffic-group traffic-group-local-only
    vlan external
}

F5 agent doesn’t apply Enhanced Service Definitions to BIG-IP virtual server¶

If you configured an Enhanced Service Definition (ESD) and the F5 agent didn’t apply the ESD to your BIG-IP:

Check your JSON with a JSON linter. The F5 OpenStack agent ignores invalid JSON files.
Check the log file for invalid tags. [1]
If your agent recently restarted, make sure the ESD JSON file is in the /etc/neutron/services/f5/esd/ directory. ESDs only remain in F5 agent memory while the agent is running. Removing the ESD JSON file from /etc/neutron/services/f5/esd/ directory will cause a loss of the ESD if the agent restarts. For this reason, we recommend that you leave all ESD JSON files in place as long as you need them to remain active.

[1]	Logging level must be set to DEBUG.