Guide That Contains This Content
[+] Expand All
[-] Collapse All

    Using Load Balancers in Contrail 3.0 and Greater

    As of Contrail Release 3.0, new LBaaS features are available in the following:

    Invoking LBaaS Drivers

    The provider field specified in the pool configuration determines which load balancer drivers are selected. The load balancer driver selected is responsible for configuring the external hardware or virtual machine load balancer.

    Current supported load balancer drivers include:

    • HAProxy
    • A10 Networks
    • F5 Networks

    Starting with Contrail 3.0, the Neutron LBaaS plugin creates required configuration objects (such as pool, VIP, members, and monitor) in the Contrail API server, instead of within the Neutron plugin context, as in previous releases.

    This method of configuration has the following benefits:

    • Configuration objects can be created in multiple ways: from Neutron, from virtual controller APIs, or from the Contrail UI.
    • The load balancer driver can make inline calls, such as REST or SUDS, to configure the external load balancer device.
    • The load balancer driver can use Contrail service monitor infrastructure, such as database, logging, and API server.

    The following figure provides an overview of the LBaaS components as of Contrail 3.0.

    Using a Service Appliance Set as the LBaaS Provider

    In OpenStack Neutron, the load balancer provider is statically configured in neutron.conf, which requires restart of the Neutron server when configuring a new provider. The following is an example of the service provider configuration in neutron.conf.

    service_provider = LOADBALANCER:Opencontrail:neutron_plugin_contrail.plugins.opencontrail. loadbalancer.driver.OpencontrailLoadbalancerDriver:default

    In Contrail Release 3.0 and greater, the Neutron LBaaS provider is configured by using the object service-appliance-set. All of the configuration parameters of the LBaaS driver are populated to the service-appliance-set object and passed to the driver.

    During initialization, the service monitor creates a default service appliance set with a default LBaaS provider, which uses an HAProxy-based load balancer. The service appliance set consists of individual service appliances for load balancing the traffic. The service appliances can be physical F5 Networks devices or virtual machines.

    Sample Configuration: Service Appliance Set

    The following is a sample configuration of the service appliance set for the LBaaS provider:

      "service-appliance-set": {
        "fq_name": [
        "service_appliance_driver": "",
        "parent_type": "global-system-config",
        "service_appliance_set_properties": {
          "key_value_pair": [
              "key": "sync_mode",
              "value": "replication"
              "key": "global_routed_mode",
              "value": "True"
        "name": "f5"

    Sample Configuration: Single Service Appliance

    The following is a sample configuration of a single service appliance:

      "service-appliance": {
        "fq_name": [
        "parent_type": "service-appliance-set",
        "service_appliance_ip_address": "<ip address>",
        "service_appliance_user_credentials": {
          "username": "admin",
          "password": "<password>"
        "name": "bigip"

    Understanding the Load Balancer Agent

    The load balancer agent is a module in the service monitor. The service monitor listens on the RabbitMQ configuration messaging queue (vnc_config.object-update) to get configuration objects. The dependency tracker triggers changes to all related objects, based on configuration updates.

    The dependency tracker is informed to notify the pool object whenever the VIP, member, or health monitor object is modified.

    Whenever there is an update to the pool object, either directly due to a pool update or due to a dependency update, the load balancer agent in the service monitor is notified.

    The load balancer agent module handles the following:

    • Loading and unloading LBaaS driver-based service appliance set configuration.
    • Providing the abstract driver class for the load balancer driver.
    • Invoking the LBaaS driver.
    • Load balancer-related configuration.

    F5 Networks Load Balancer Integration in Contrail

    Contrail Release 3.0 implements an LBaaS driver that supports a physical or virtual F5 Networks load balancer, using the abstract load balancer driver class, ContrailLoadBalancerAbstractDriver.

    This driver is invoked from the load balancer agent of the contrail-svc-monitor. The driver makes a BIG-IP interface call to configure the F5 Networks device. All of the configuration parameters used to tune the driver are configured in the service-appliance-set object and passed to the driver by the load balancer agent while loading the driver.

    The F5 load balancer driver uses the BIG-IP interface version V1.0.6, which is a Python package extracted from the load balancer plugin provided by F5 Networks. The driver uses either a SOAP API or a REST API.

    F5 Load Balancer Global Routed Mode

    The F5 load balancer driver is programmed in global routed mode using a property of the service-appliance-set.

    This section describes the features and requirements of the F5 load balancer driver configured in global routed mode.

    The following are features of the global routed mode.

    • All virtual IP addresses (VIPs) are assumed to be routable from clients and all members are routable from the F5 device.
    • All access to and from the F5 device is assumed to be globally routed, with no segregation between tenant services on the F5 device. Consequently, do NOT configure overlapping addresses across tenants and networks.
    • The F5 device can be attached to the corporate network or to the IP fabric.

    The following are requirements to support global routed mode of an F5 device used with LBaaS:

    • The entire configuration of the F5 device for Layer 2 and Layer 3 is preprovisioned.
    • All tenant networks and all IP fabrics are in the same namespace as the corporate network.
    • All VIPs are in the same namespace as the tenant and corporate networks.

    Traffic Flow in Global Routed Mode

    This section describes and illustrates the behavior of traffic flow in global routed mode.

    The information in this section is based on a model that includes the following network topology:

    Corporate Network --- DC Gateway (MX device) --- IP Fabric --- Compute nodes

    The Corporate Network, the IP Fabric and all tenant networks use IP addresses from a single namespace, there is no overlap of the addresses in the networks. The F5 devices can be attached to the Corporate Network or to the IP Fabric, and are configured to use the global routed mode.

    The role of the MX Series device is to route post-proxy traffic, coming from the F5 device in the underlay, to the pool members in the overlay. In the reverse direction, the MX device takes traffic coming from the pool members in the overlay and routes it back to the F5 device in the underlay.

    The MX device is preprovisioned with the following:

    • VRF connected to pool network 2
    • ability to route traffic from inet.0 to the pool network

    The MX routes the traffic from inet.0 to public VRF and sends traffic to the compute node where the pool member is instantiated.

    The F5 device is preprovisioned with following:

    • publish route to attract VIP traffic
    • pool network subnet route that points to the MX device

    The F5 device is responsible for attracting traffic destined to all the VIPs, by advertising a subnet route that covers all VIPs using IGP.

    The F5 device load balances among different pool members and sends traffic to the chosen member.

    The global routed traffic flow is shown in the following figure.

    A similar result can also be achieved on the switch to which the F5 is attached, by publishing the VIP subnet in IGP and using a static route to point the VIP traffic to the F5 device.

    The MX should attract the reverse traffic from the pool members going back to the F5.

    Routing Traffic to Pool Members

    For post load balancing traffic going from the F5 device to the pool members, the MX Series device needs to attract traffic for all the tenant networks.

    Routing Reverse Traffic from Pool Members to the F5 Device

    The MX should attract the reverse traffic from the pool members going back to the F5.

    Initial Configuration on an F5 Device

    • The operator is responsible for ensuring that the F5 device attracts traffic to all VIP subnets by injecting the route for the VIP subnet into IGP. Alternately, the switch to which F5 is connected can advertise the VIP subnet route and use the static route to send VIP traffic to the F5 device.
    • In the global routed mode, the F5 uses AutoMap SNAT for all VIP traffic.

    Initial Configuration on an MX Series Device Used as DC Gateway

    • The operator must identify a super-net that contains all tenant network subnets (pool members across multiple pools) and advertise its route into corporate and fabric networks, using IGP (preferred) or static routes.
    • The operator must add a static route for the super-net into inet.0 with a next-hop of public.inet.0.
    • The operator must create a public VRF and get its default route imported into the VRF. This is to attract the return traffic from pool members to the F5 deice (VIP destination).

    Configuration on MX Device for Each Pool Member

    • For each member virtual network, the operator adds a policy to connect the member pool virtual network to the public virtual network.
    • As new member virtual networks are connected to the public virtual network by policy, corresponding targets are imported by the public VRF on MX. The Contrail Device Manager generates the configuration of import, export targets for public VRF on the MX device.
    • The operator must ensure that security group rules for the member virtual network ports allow traffic coming from the F5 device.

    Example: Creating a Load Balancer

    Use the following steps to create a load balancer in Contrail Release 3.0 and greater.

    1. To configure a service appliance set, use the script in /opt/contrail/utils to create a load balancer provider. With the script, you specify the driver and name of the selected provider. Additional configuration can be performed using the key-value pair property configuration.

      /opt/contrail/utils/ --api_server_ip <ip address>--api_server_port 8082 --oper add --admin_user admin --admin_password <password> --admin_tenant_name admin --name f5 --driver "" --properties '{"use_snat": "True", "num_snat": "1", "global_routed_mode":"True", "sync_mode": "replication", "vip_vlan": "trial2"}'

    2. Add the actual device information of the load balancer.

      /opt/contrail/utils/ --api_server_ip <ip address>--api_server_port 8082 --oper add --admin_user admin --admin_password <password> --admin_tenant_name admin --name bigip --service_appliance_set f5 --device_ip --user_credential '{"user": "admin", "password": "<password>"}'

    3. Refer to the load balancer provider while configuring the pool.

      neutron lb-pool-create --lb-method ROUND_ROBIN --name web_service --protocol HTTP --provider "f5" --subnet-id <subnet id>

    4. Add members to the load balancer pool. Both bare metal webserver and overlay webserver are allowed as pool members. The F5 device can load balance the traffic among all pool members.

      neutron lb-member-create --address <ip address>--protocol-port 8080 --weight 3 web_service

      neutron lb-member-create --address <ip address> --protocol-port 8080 --weight 2 web_service

    5. Create a VIP for the load balancer pool.

      neutron lb-vip-create --name httpserver --protocol-port 80 --protocol HTTP web_service --subnet-id <subnet id>

    6. Create the health monitor and associate it with the load balancer pool.

      neutron lb-healthmonitor-create --delay 3 --type HTTP --max-retries 3 --timeout 3

      neutron lb-healthmonitor-associate <nnnnn-nnnnn-nnnn-> web_service

    Modified: 2016-12-15