Frequently Asked Questions (FAQ)

Index


What is Cloud Failover Extension?

Cloud Failover (CFE) is an iControl LX Extension delivered as a TMOS-independent RPM file. Installing CFE on BIG-IP provides L3 failover functionality in cloud environments.

Cloud Failover Extension is:

but it is NOT:

  • created to include a graphical interface (GUI)

When is CFE a good fit and when it is not?

Cloud Failover is a good fit where:

  • You are using an HA Pair in an Active/Standby configuration.
  • You require a simple method to deploy and upgrade an HA solution without having to deploy a cloud native template.

Cloud Failover may not be a good fit where:

  • You are using more than one traffic group. For example, devices are in Active/Active or Active/Active/Standby configuration.

Where can I download CFE?

Cloud Failover Extension is available on GitHub in the Releases section under Assets.


Which TMOS versions does CFE support?

Cloud Failover Extension supports TMOS 14.1.x and later.


Does CFE support IPv6?

  • IPv6 route failover is currently supported for AWS only. To see an example confguration for AWS that enables IPv6 route failover, see Example Declarations.
  • IPv6 IP address failover (for addresses in traffic-groups like VIPS, SNATS, and NATs) is not yet supported for any clouds.

How can I track new CFE features?

See the Releases section on GitHub to keep up to date with CFE features and enhancements. You can also track changes to this documentation in the Document Revision History.


Can I use CFE with Application Services Extension (AS3)?

Yes, Cloud Failover Extension can be used with AS3 declarations. AS3 leverages tenant partitions and some previous failover solutions did not support inspecting tenant partitions.


Does it matter if I use CFE in same network or across network?

Cloud Failover Extension is agnostic to same-network and across-network topologies.


Does CFE support AWS Same-AZ failover?

Yes, Cloud Failover Extension supports AWS Same-AZ failover. See the AWS section for more details.


Does CFE eliminate the delay time observed with previous failover templates when calling the Azure APIs?

To failover cloud resource objects such as private IP addresses and route tables, CFE does make calls to the Azure APIs. These calls may vary significantly in response time.


Do I always have to tag my resources?

Yes. Even when you only have routes to update during failover (for example, there are no Elastic IPs to re-map) you still have to tag the NICs on the VMs associated with the IPs in your CFE configuration.


How does CFE work on an existing BIG-IP cluster using legacy failover scripts installed by Cloud Templates?

As of CFE version 1.1, CFE disables the existing failover scripts installed by the Cloud Templates transparently to the user. If you are using an older version of CFE and would like to have legacy scripts automatically disabled, you should Update Cloud Failover Extension. Otherwise you will have to manually comment out the older failover scripts that the template installs:

  • In /config/failover/tgactive and /config/failover/tgrefresh comment out the failover.js script with /config/cloud/cloud-libs/XXXXXX/failover.js.
  • After you POST the declaration, CFE will write out a new line that looks like this: curl -u admin:admin -d {} -X POST http://localhost:8100/mgmt/shared/cloud-failover/trigger.

What information does CFE store?

Cloud Failover Extension stores the BIG-IP failover IP address and routes in the cloud storage JSON file (example below). For this reason, make sure your cloud store does not have public access.

{
    "taskState": "SUCCEEDED",
    "message": "Failover Completed Successfully",
    "timestamp": "2019-09-25T23:44:44.381Z",
    "instance": "failover0.local",
    "failoverOperations": {
        "routes": {},
        "addresses": {}
    }
}

Does CFE collect telemetry data?

F5 collects non-personal telemetry data to help improve the Cloud Failover Extension. You can see an example of the payload that is sent below. To disable this feature, run the command tmsh modify sys software update auto-phonehome disabled.

{
    "documentType": "f5-cloud-failover-data",
    "documentVersion": "1",
    "digitalAssetId": "xxxx",
    "digitalAssetName": "f5-cloud-failover",
    "digitalAssetVersion": "1.0.0",
    "observationStartTime": "xxxx",
    "observationEndTime": "xxxx",
    "epochTime": "123581321",
    "telemetryId": "xxxx",
    "telemetryRecords": [
        {
            "environment": "azure",
            "Failover": 1,
            "platform": "BIG-IP",
            "platformVersion": "14.1.0.5",
            "featureFlags": {
                "ipFailover": true,
                "routeFailover": false
            }
        }
    ]
}

Why does CFE no longer default to a tag on the route for next hop address discovery?

Specifying the f5_self_ips tag on the route object itself creates a circular dependency in some scenarios, especially when using declarative configuration tools like Terraform. For backwards compatability this option is still available, however, F5 recommends alternate approaches, such as providing the next hop addresses (a self IP for each BIG-IP in the cluster) in the Cloud Failover Extension configuration payload. See Example Declarations for an example using the original route tag discovery method.


Does CFE configuration persist after a reboot?

Yes, when configuration is provided using the CFE declare API endpoint it will be saved to the persistent BIG-IP configuration store which is loaded on reboot.


How do I report issues, feature requests, and get help with CFE?

You can use GitHub Issues to submit feature requests or problems with Cloud Failover Extension, including documentation issues.