Docs / dflux EdgeGuard
ContactGet started

Routing engine

The routing engine picks a producer (SBI) or peer (Diameter) for each request that survived the filter chain. It supports content-based matching, SUPI ranges, time windows, weighted targets, and sticky sessions — all hot-reloadable.

When routing runs

Routing runs after the request filter chain returns "allow". The engine evaluates the configured routing rules in priority order, resolves the matched rule's target to a single producer (SBI) or Diameter peer, and hands the request to the forwarder. A routing rule may also carry a failover producer list that the forwarder falls back to if the primary attempt fails — see Failover.

Match conditions

A routing rule's condition block can constrain on:

  • Path patterns (path_patterns) and methods for SBI.
  • NF type — target_nf_types / source_nf_types to route by the requesting or destination NF.
  • SUPI range (supi_ranges) — route by subscriber identity range. Useful for sending a slice of subscribers to a dedicated UDM cluster.
  • Slice and DNN — snssais, dnns, visited_plmns, and api_versions.
  • Header and body match — header_match and body_field_match for content-based routing.
  • Time window (time_windows) — match only during a window (e.g., a maintenance window or off-peak hours).
  • Diameter matchers — diameter_apps, command_codes, origin/destination realms and hosts, and imsi_ranges.

Targets

A matched rule's target resolves to a single producer. A target can carry:

  • nf_type — when set without explicit producers, the request falls through to the producer pool for that NF type.
  • producers — an explicit list of producer addresses, each with an optional weight for weighted-random selection.
  • weighted_targets — a percentage split for canary and blue/green rollouts — see below.
  • sticky_key / sticky_ttl — session affinity — see Sticky sessions.
  • failover — a fallback producer list — see Failover.

Weighted targets

When a target lists weighted_targets, the proxy selects one address per request, weighted-randomly by the percentage on each entry. Each weight is 1–100 and the set must sum to 100. Common patterns:

  • Canary: a 95 / 5 split between the production target and the canary target.
  • Blue/green: shift the split toward the new target over successive edits, e.g. 90 / 10 then 50 / 50 then 10 / 90. Weight changes hot-reload, no restart.
Draining a producer is a separate operation
Weighted-target weights cannot be set to 0 (validation requires each weight in 1–100). To take a producer out of rotation, use the producer-pool drain operation on the admin API rather than zeroing a routing weight — see Admin API → Producers and profiles.

Sticky sessions

For workloads where the same subscriber must keep landing on the same producer (session state, idempotency tokens), set sticky_key on the target together with a sticky_ttl. The sticky key is configurable — one of supi, gpsi, imsi, session_id, origin_host, or request_id. On the first request for a given key value, the engine picks a producer normally and caches that producer under the key value; subsequent requests with the same value reuse the cached producer until the entry expires.

Stickiness is a TTL cache
The mapping is a per-key TTL cache, not consistent hashing. An entry lives for sticky_ttl after it is set, then expires and the next request re-resolves a producer. Sticky lookups bypass the primary/failover path for the duration of the TTL.

Failover

A routing rule's target.failover carries an ordered list of fallback producers. When the primary attempt fails, the forwarder retries against those producers in order, bounded by max_retries. This applies to both SBI and Diameter and is independent of Diameter realm-peer selection performed by the relay.

Failover triggers on more than transport failure. The default is transport-only, but a failover target can also retry on application-level responses: trigger_on_status lists HTTP status codes (SBI) and trigger_on_result_code lists Diameter Result-Code / Experimental-Result-Code values that should be treated as a retryable failure.

Rule evaluation order

Routing rules are evaluated in priority order; the first matching rule wins. If no rule matches, the proxy falls back to the producer pool (NRF-discovered producers for the request's NF type, weighted by their NRF profile). If neither produces a target, the request is rejected with the appropriate protocol-level error.