# F5XC load-balancing algorithm chooser

> A short questionnaire recommends an F5XC origin-pool load-balancing algorithm - with the BIG-IP equivalent, caveats, and where to set it - and explains the XC model where consistent hashing IS the persistence method.

- Tool: https://ronutz.com/en/tools/f5xc-lb-algorithm-chooser
- Family: Networking

---

## What it does

This tool is a guided chooser for the F5 Distributed Cloud (XC) origin-pool load-balancing algorithm. Answer three questions - whether sessions need to stick to the same origin, what identifies a session (source IP, a cookie, a custom header, or "it varies per route"), and whether the origin pool is dynamic - and it recommends one of XC's algorithms, names the BIG-IP equivalent, lists the caveats that apply to your answers, and tells you where to set it. Everything runs in your browser.

## The XC persistence model, for BIG-IP people

This is the point the tool exists to make. On BIG-IP, the load-balancing method (Round Robin, Least Connections, and so on) and the persistence profile (Source Address Affinity, Cookie) are two independent settings on the virtual server. XC folds them together. The consistent-hashing algorithms - Source IP Stickiness, Cookie Based Stickiness, and Ring Hash - are not just distribution methods; each one is also, by definition, the persistence method. Choosing one gives you both at once. The non-hash algorithms - Round Robin, Least Active Request, Random - do not persist at all. There is no separate persistence profile object to attach.

## The seven algorithms

Round Robin sends requests to origins in turn. Least Active Request sends each request to the origin with the fewest in-flight requests, which suits uneven request costs or long-lived connections. Random picks an origin at random and is statistically even across large pools. Source IP Stickiness, Cookie Based Stickiness, and Ring Hash are the consistent-hashing family - they hash the source IP, a cookie, or a hash policy you define (typically a session-ID header), and keep a client on the same origin. Load Balancer Override is the escape hatch - it defers the choice to the HTTP load balancer so you can set stickiness per route or per domain.

## Why the caveats matter

The recommendation is only as good as the fit, so the tool surfaces the traps. Hashing on source IP concentrates clients that share an IP (behind NAT or a proxy) onto one origin, making load uneven. Cookie stickiness needs a name, TTL, and path, and only holds if the client returns the cookie. A custom-header hash needs a value that is stable per session, not per request. And for a dynamic pool - Kubernetes pods scaling up and down - consistent hashing is the right family, because it remaps the fewest clients when membership changes.

## Standards and references

- [F5 Distributed Cloud: Create HTTP Load Balancer (origin-pool load-balancing algorithm options)](https://docs.cloud.f5.com/docs-v2/multi-cloud-app-connect/how-to/load-balance/create-http-load-balancer) - Round Robin, Least Active Request, Random, Source IP Stickiness (hash of source IP), Cookie Based Stickiness (hash of cookie), Ring Hash, Load Balancer Override
- [DevCentral: What is the Ring Hash load-balancing algorithm?](https://community.f5.com/kb/technicalarticles/what-is-the-ring-hash-load-balancing-algorithm/329600) - consistent hashing IS the persistence method; hashes source IP, cookie, or a custom header; tolerates pool churn with minimal remapping; low client diversity on source IP causes uneven load
- [DevCentral: Setting up persistence in F5 XC (Load Balancer Override, per-route Load Balancing Control)](https://community.f5.com/kb/communityarticles/setting-up-persistence-in-f5-xc/306913) - set algorithm to Load Balancer Override, then choose Cookie (name/TTL/path) or Source IP stickiness per route under Advanced Options > Load Balancing Control
- [F5 Distributed Cloud: Load Balancing and Service Mesh (scheduling algorithms)](https://docs.cloud.f5.com/docs-v2/platform/concepts/load-balancing-and-mesh) - round robin, weighted least request, random, ring-hash as the scheduling algorithms

## Related reading

- [XC Load-Balancing Algorithms and Persistence, for BIG-IP People](https://ronutz.com/en/learn/f5xc-lb-algorithms-and-persistence.md): On BIG-IP the load-balancing method and the persistence profile are two separate knobs; on XC they are one. Why the consistent-hashing algorithms (Source IP, Cookie, Ring Hash) ARE the persistence method, what you can hash, when to use the non-hash algorithms, and how Load Balancer Override gives per-route persistence.