Subscribe to the Blog

Get articles sent directly to your inbox.

Everyone has an IT Horror Story of taking parts of, or the entire network in many cases, down by accident. When an issue like this occurs it is important to understand the symptoms, and ensure it never happens again. With Indeni our customers are able to turn the tribal knowledge around network outages into code, and automatically check for the symptoms if / when they happen again in the future.

Here are some of the top best practices to keep your F5 load balancers up and running:

1. Cluster configuration not synced

It is normally desirable for clusters to have their configuration synced. Else, changes made on one node in a cluster might not be active in the event of a fail over. This might cause disruption. For devices that support full configuration synchronization, Indeni will alert if the configuration is out of sync.
View remediation steps

2. Configuration changed on standby member

Tracking the state of a cluster member is important. If a cluster member which used to be the active member of the cluster no longer is, it may be the result of an issue. In some cases, it is due to maintenance work (and so was anticipated), but in others it may be due to a failure in the firewall or another component in the network. Generally, making configuration changes to the standby member of a device is not recommended. Indeni will alert if this happens.
View remediation steps

3. Preemption enabled

Preemption, or auto failback as F5 calls is, is a function in clustering which sets a primary member of the cluster to always strive to be the active member. The trouble with this is that if the active member that is set with preemption on has a critical failure and reboots, the cluster will fail over to the secondary and then immediately fail over back to the primary when it completes the reboot. This can result in another crash and the process would happen again and again in a loop. It is generally a good idea not to have the preemption feature enabled. Preemption is generally a bad idea in clustering, although sometimes it is the default setting. Indeni will alert if it’s on.
View remediation steps

4. Model mismatch

Two or more devices which operate as part of a single cluster must be running on the same hardware. Indeni will identify when two devices are part of a cluster and alert if the model of device in use is different.
View remediation steps

5. Non-identical HA-Group configuration

HA-groups are one of the ways to determine if an F5 cluster should fail over or not by keeping track of trunk health and/or specific pool statuses. Should a link in a trunk fail, or a pool member stop responding this could trigger a fail-over. To minimize the risk of flapping an active bonus is highly recommended. Since this configuration is not synchronized it is ideal for it to be identical in all units of the cluster. Even more so, since F5’s recommended way of manually failing over a cluster with ha-groups is to change the weight of the ha-group members. This is easily forgotten once done, which in turn could lead to the system not failing over when components fail. Indeni will identify when two F5 devices are part of a device group and alert if the HA-group configuration is different.
View remediation steps

Want more best practices? Join the F5 Networks discussion on Indeni Crowd or Download Indeni today.