Navigating the Challenges of Interacting with F5 Programmatically

Interacting with the F5 Programatically is an exciting yet challenging journey. During my experience, I faced timeouts that disrupted session stability and hindered effective API communication with F5 devices.

In this blog post, I'll share my journey of overcoming these obstacles while developing a script to generate backups of F5 configurations. Although I focus on timeout challenges in Go, the principles and solutions discussed apply to any programming language. By sharing my insights, I aim to empower you to handle timeouts and generate F5 backups effectively, regardless of your language preference.

In the code examples below, I use the Go and its SDK to interact with the F5 guest, which can be found here.

Challenge 1: Session Timeout

The first timeout issue I encountered was the session timeout. This happened while trying to create a UCS backup of the device's configuration. This task can be quite time-consuming, especially when dealing with large configuration files -my file was over 1GB. The challenge arose when the F5 session would time out before the backup process completed, forcing me to establish a new connection to continue interacting with the F5 device.

Below is the code snippet for reference:

package main

import (
	"log"

	"github.com/e-XpertSolutions/f5-rest-client/f5"
)

func main() {
	device := "https://lab-lb.lab.com"
	username := "username"
	password := "password"

	// Connect to F5 device
	f5Client, err := f5.NewBasicClient(device, username, password)
	if err != nil {
		log.Fatal(err)
	}

	// Start new USC Backup.
	backup, err := f5Client.Backup("backup-go.ucs")
	if err != nil {
		log.Fatal(err)
	}
}

The backup task ran for about 60 seconds before failing. Troubleshooting this issue was quite challenging due to the cryptic and uninformative nature of the error message. Here is the error message I received:

'{"code":400,"message":"remoteSender:x.x.x.x, method:POST","referer":"x.x.x.x","restOperationId":70781606,"kind":":resterrorresponse"}'

After conducting some research, I found a log file on the F5 guest located at /var/log/restjavad.0.log. Within this log file, I discovered the following message, which shed some light on the situation and provided me with additional context:

[WARNING][46083][04 May 2023 01:26:03 UTC][8100/mgmt ForwarderPassThroughWorker] URI:http://localhost:8100/mgmt/tm/sys/ucs/, Referrer:x.x.x.x, Method:POST, Exception:java.util.concurrent.TimeoutException: remoteSender:10.49.62.233, method:POST

With a bit more context and a little more digging I found the solution in the article here.

The Fix

Ultimately, the solution required adjusting the timeout settings on the device itself, which was completely unrelated to the API or the SDK. By increasing the timeout threshold, I was able to allow enough time for the backup process to complete without the session timing out.

Challenge 2 - The API Timeout

In addition to the session timeout, another timeout challenge I encountered was related to the API when attempting to download the UCS file to my local computer.

Below is the code snippet for reference:

	download, err = f5Client.DownloadUCS(file, bkpFile)
	if err != nil {
		log.Fatal("Unable to download UCS file \n", err)
	}
  

Here is the error message received:

2023/05/09 15:23:40 Unable to download UCS file 
cannot retrieve info for ucs file: Get "https://lab-lb.lab.com/mgmt/tm/sys/ucs": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

To troubleshoot this issue, I dived into the source code of the SDK and specifically examined the DownloadUCS process. You can find the relevant code snippet here. What caught my attention were the comments located just below the function definition. I have captured them here for your convenience:

// BigIP 12.x.x only support download requests with a Content-Range header,
// thus, it is required to know the size of the file to download beforehand.
//
// BigIP 13.x.x automatically download the first chunk and provide the
// Content-Range header with all information in the response, which is far
// more convenient. Unfortunately, we need to support BigIP 12 and as a
// result, we need to first retrieve the UCS file size information.

These comments proved to be invaluable in unraveling the inner workings of the DownloadUCS function and understanding the required parameters. They shed light on the underlying logic and gave me a comprehensive understanding of the process. Upon further investigation, I discovered that the DownloadUCS method utilizes a GET request to the endpoint /mgmt/tm/sys/ucs to initiate the UCS file download.

To gain more insight, I decided to manually test this endpoint by accessing it through a browser. Interestingly, I noticed that it took approximately 5 seconds for the endpoint to respond. This observation provided a crucial clue in identifying a potential cause for the API timeout during the UCS file download.

The Fix

To fix this issue, I had to increase the API timeout. I set a timeout value of 10 seconds. The below code shows how I achieved this.

package main

import (
	"log"
	"time"

	"github.com/e-XpertSolutions/f5-rest-client/f5"
)

func main() {
	device := "https://lab-lb.lab.com"
	username := "username"
	password := "password"

	// Connect to F5 device
	f5Client, err := f5.NewBasicClient(device, username, password)
	if err != nil {
		log.Fatal(err)
	}

	// Increase Http Timeout to 10 seconds as some API calls take long to respond
	// Seems like the default is in nano seconds :-@
	f5Client.SetTimeout(10 * time.Second)
}

Conclusion

Interacting with the F5 API can indeed be a challenging endeavor, particularly when faced with timeout issues. Throughout this blog, I have shared my personal experiences and insights to provide you with assistance on your own journey. By addressing session and API timeouts, and understanding how to adjust both code and device settings, you can effectively manage these challenges and streamline your F5 API interactions. Happy coding!