Overview #

This article explains how to migrate an F5 BIG-IP iRule that routes multiple application URIs to the same backend pool into RELIANOID using native HTTP/S farm service matching and regular expression (regex) URI patterns.

The original iRule evaluates the incoming URI and sends traffic matching several application paths to the same backend pool.

Original F5 iRule #

when HTTP_REQUEST 
{
    switch -glob [string tolower [HTTP::uri]] 
    {
         "/firstapp*" {   
             pool "MY_POOL"  
         }

         "/secondapp*" {   
             pool "MY_POOL" 
         }

         "/thirdapp" {   
             pool "MY_POOL" 
         }
    }
}

Migration Goal #

The purpose of this configuration is:

• Match multiple application paths
• Route all matching traffic to the same backend pool
• Simplify application routing logic

RELIANOID Migration Approach #

In RELIANOID, this can be achieved without scripting by using:

• One single HTTP/S service
• URI pattern matching
• Regular expressions (regex)
• Shared backend configuration

This approach is simpler, cleaner, and easier to maintain than multiple conditional iRules.

RELIANOID Configuration #

Navigate to Farms > HTTP/S Farm > Services and Create a new service.

URI Matching Configuration #

In the URL pattern use the regex:

^/(firstapp|secondapp|thirdapp)

Backends configuration #

Add the backend list configuration in the service.

Why This Approach Is Recommended #

Using a single regex-based service provides:

• Cleaner configuration
• Easier maintenance
• Reduced service count
• Better scalability
• Simplified troubleshooting

Instead of managing multiple iRule conditions, the URI logic is centralized in one matching rule.

Validation #

Test with CURL. Example:

curl -k https://example.com/firstapp -v

Or:

curl -k https://example.com/secondapp/api/test -v

Expected result:

• Request is forwarded to the configured backend pool
• Application responds normally

Troubleshooting #

Requests Not Matching #

Verify:

• Regex mode is enabled
• URI pattern is correct
• No hidden spaces or invalid regex syntax

Only Some Applications Work #

Check:

• Regex includes all required application names
• URI capitalization behavior

RELIANOID regex matching is case-sensitive unless configured otherwise.

If case-insensitive matching is needed, use:

(?i)^/(firstapp|secondapp|thirdapp)

Traffic Sent to Default Service #

This usually indicates:

• Regex mismatch
• Service ordering issue
• URI normalization differences

Alternative Approach #

Although multiple services can also be created, this is generally not recommended when:

• All applications share the same backend pool
• Routing logic is identical

A single regex-based service is more efficient.

Best Practices #

• Group similar applications into shared services when possible
• Use regex carefully to avoid unintended matches
• Keep URI matching logic centralized
• Document regex rules for operational visibility

Summary #

F5 iRules performing URI-based pool selection can be migrated into RELIANOID using native HTTP/S service matching with regex patterns.

This approach simplifies configuration while maintaining equivalent application routing behavior.