F5 Distributed Cloud (XC) Custom Routes: Capabilities, Limitations, and Key Design Considerations

Have you ever worked with Routes under an F5 Distributed Cloud (XC) Load Balancer?
If yes, you probably already know how challenging they can become to maintain, especially when multiple domains are hosted behind the same Load Balancer.

I recently faced exactly this challenge in a real project, with an additional twist:

• DevOps wanted full automation via Terraform
• SecOps followed a more traditional click-ops approach

The clear requirement was:

The Load Balancer itself must not be managed by Terraform, but routes must be fully automated.

This naturally led us to explore Custom Routes as standalone objects, attached to the Load Balancer, but managed independently.

Architectural Approach

Instead of defining routes directly under the Load Balancer, we used:

Multi-Cloud App Connect → Virtual Host → Routes

These Custom Route objects:

• Are created independently
• Can be fully managed via Terraform
• Are later attached to the Load Balancer, which only references them

Inside a Custom Route object, you can define:

• Path-based routing
• Host matching
• Header matching
• And target an origin backend

At this stage, Custom Routes look like the ideal model for separating responsibilities between:

• Security ownership (Load Balancer, exposure, security policies)
• Application & routing ownership (application paths, environments, services)

From this point onward, however, it becomes clear that this is not just an operations topic, it is a platform design and architectural question with implications for anyone considering Custom Routes, regardless of the DevOps/SecOps split.

What Are Custom Routes?

Rather than defining routing rules directly on a Load Balancer, F5 XC allows you to create standalone Route objects.

These Route objects can then be:

• Attached to one or more Load Balancers
• Managed independently
• Reused across different applications and environments

Within a Custom Route, you can define:

• Redirects
• Direct resposes
• Host-based routing
• Path-based routing
• Header-based matching
• Query-based matching
• Backend forwarding logic

Architecturally, this gives you a more modular routing model and reduces coupling between your applications and the Load Balancer configuration.

Key Architectural Differences from Standard Load Balancer Routes

1. No Direct Origin Pool Usage

With standard XC Load Balancers, routes typically forward traffic directly to an Origin Pool.

With Custom Routes, this is not supported.

Instead, traffic must be defined through:

1. Endpoints
2. Clusters (which group endpoints)
3. Routes which reference the cluster

This adds:

• Extra configuration objects
• More dependency layers
• Stronger inter-object coupling

Functionally it works, but conceptually it feels much closer to a service-mesh style routing model than to a classic LB → pool pattern.

2. Endpoint Network Type – A Critical Design Detail

When creating an Endpoint, you must choose where the backend network resides. One selection is critical:

• ✅ Site Local Network → works
• ❌ Site Local Inside Network → does not work for this scenario

Picking the wrong one leads to silent routing failures with no obvious error message. This is an easy and high-impact misconfiguration trap.

TLS & Certificate Validation – A Major Constraint

3. No “Skip Server SSL Verification” Option

• There is no option to disable backend certificate validation.
• TLS verification is therefore always enforced for Custom Routes.

This leads to the following real-world behavior:

• ✅ Backends using Public CA certificates | You must upload the Public Root CA certificate (unless you enable the hidden JSON-based F5 XC trust bundle option).
• ✅ Backends using Private PKI | You must upload the Private Root CA certificate.
• ⚠ Backends using “self-signed” certificates
        – If you use a self-signed Root CA to issue server certs, this can work if you upload that                 Root CA.
        – A single self-signed server cert with no Root CA will not work.

Important Clarification on Public CAs

With Origin Pools, you can use the F5 XC Root CA to trust Public Certs automatically. With Custom Routes, this option is not available, or better not exposed in the GUI.

You must either:

1. Upload the Public Root CA manually, or
2. Enable the following JSON-only flag on the Cluster:

"use_volterra_trusted_ca_url": true

⚠ This flag is not visible in the GUI and should be used with caution.

Final Assessment

• ✅ Decoupled routing
• ✅ Reusable Route objects
• ✅ Modular architecture

But also:

• ⚠ Mandatory Endpoint + Cluster abstraction
• ⚠ Strict TLS verification
• ⚠ Root CA handling required
• ⚠ JSON-only options

Recommendation

Custom Routes look powerful, but they follow a different architectural philosophy compared to standard XC Load Balancer routes.

Everything described here is based on current behavior I have observed in real deployments, not on official F5 documentation (I haven’t found detailed docs specifically covering these nuances for Custom Routes). Platform behavior may evolve over time, so you should always validate in your own environment.

In other words:

Use Custom Routes consciously and with proper testing, not as a drop-in replacement for standard LB routes.

If anyone in the community has:

• Implemented Custom Routes at scale
• Found cleaner patterns for TLS and CA handling
• Or identified alternative designs for multi-domain routing

I’d be very interested to hear your experiences and best practices.

P.S. The full article was genuinely written by me, only the formatting was assisted by AI.