Diameter Routing Agents in Depth

Introduction¶

As LTE and IMS networks grow, point-to-point Diameter connections between every HSS, MME, PCRF, PGW, OCS, and CSCF become unmanageable. A Diameter Routing Agent (DRA) centralises routing — nodes connect to the DRA, the DRA routes by realm and application. It's the direct analogue of an SS7 STP.

Agent types (RFC 6733)¶

• Relay agent — routes messages based on routing information, does not modify AVPs (except adding Route-Record). Stateless-ish.
• Proxy agent — routes and may modify messages (enforce policy, mediate AVPs, topology hiding). Most DRAs are proxy agents.
• Redirect agent — doesn't forward; replies with a redirect telling the sender where to go directly. Used for discovery.
• Translation agent — converts between Diameter and another protocol (Diameter ↔ MAP, Diameter ↔ RADIUS).

A DRA is typically a proxy agent cluster. A DEA (Diameter Edge Agent) is a DRA at the network border for roaming (S6a/S9/Rx roaming over IPX), adding security, topology hiding, and inter-operator mediation.

The peer table and CER/CEA¶

Each Diameter node has a peer table — the directly-connected peers, their IPs, transport (SCTP preferred, multi-homed; or TCP), and the applications they support.

On connect, peers exchange CER (Capabilities-Exchange-Request) / CEA: Origin-Host, Origin-Realm, Host-IP-Address, Vendor-Id, and the list of Auth-Application-Id / Vendor-Specific-Application-Id each supports (S6a = 16777251, Gx = 16777238, Rx = 16777236, Cx = 16777216, Ro/Gy = 4/16777238…).

DIAMETER_NO_COMMON_APPLICATION (5010) in the CEA = the two ends don't share an application.

The routing table (realm routing)¶

Beyond directly-connected peers, a node routes by Destination-Realm + Application-Id using its realm-based routing table:

Realm                          App-Id     Action    Server / Peer(s)
epc.mnc012.mcc345.3gpp...       S6a        RELAY     hss-cluster (peers: hss1, hss2, hss3)
ims.mnc012.mcc345.3gpp...       Cx         RELAY     hss-cluster
*  (default)                    *          RELAY     dea-1, dea-2   (send unknowns to the edge)

If the message has a Destination-Host AVP, it's routed to that exact host (used for in-session messages that must reach the same server — see binding). Otherwise it's routed by realm + app to a set of candidate servers, then load-balanced.

Load balancing and failover¶

Across the candidate peers for a route:

• Round-robin / weighted — spread new sessions.
• Priority — primary set, failover set.
• Least-load — some DRAs use pending-request counts or advertised load.

Failure detection: DWR/DWA (Device-Watchdog) on idle connections; a peer that misses watchdogs is marked down and traffic reroutes. 3002 DIAMETER_UNABLE_TO_DELIVER when no route/peer is available.

Session binding¶

Some Diameter applications are stateful — Gx (a PCRF session for a PDN connection) and Rx (an IMS session) relate to the same subscriber/PDN and should reach the same PCRF. The DRA maintains a binding table: e.g. key on the subscriber's IP (Framed-IP-Address) or IMSI + APN → the PCRF that handles that session. So the Gx CCR-I picks a PCRF (binding created), and the later Rx AAR for the same session is routed to that PCRF (binding lookup).

Without binding, the Rx request could land on a different PCRF that knows nothing about the Gx session → policy fails.

Topology hiding (DEA)¶

At the roaming edge, the DEA rewrites Origin-Host/Origin-Realm (and Route- Records, and sometimes AVPs revealing internal node names/IPs) so a roaming partner sees only the DEA, not your internal HSS/PCRF topology. On the return path it reverses the mapping.

Verification and troubleshooting¶

ss --sctp -a | grep 3868
tshark -i any -f "port 3868" -O diameter \
  -Y 'diameter.cmd.code in {316 272 265}'   # ULR, CCR, AAR

• Peer stuck DOWN / CER-CEA fails — no common Application-Id (5010), Origin-Host/Realm mismatch vs the peer-table entry, TLS/IPsec not established, or SCTP multi-homing path down. The CEA Result-Code says why.
• DIAMETER_UNABLE_TO_DELIVER (3002) — no route for the Destination-Realm/App, or all candidate peers are down, or a Destination-Host AVP points at an unreachable host.
• DIAMETER_REALM_NOT_SERVED (3003) — realm not in the routing table and no default route. Add the realm or a * default toward the DEA.
• Rx policy fails though Gx works — session binding broken: the DRA didn't create the binding on Gx CCR-I (missing Framed-IP-Address / Subscription-Id), or the Rx AAR key doesn't match. Check the DRA's binding table.
• Uneven PCRF/HSS load — load-balancing algorithm or weights; or session binding pinning many sessions to one server (a subscriber-heavy key).
• Roaming S6a fails at the DEA — topology-hiding rewrote an AVP the HSS rejects, the roaming partner's realm isn't provisioned, or the IPX mediated something. Capture on both sides of the DEA.
• Message loops — Route-Record AVPs accumulate; a node seeing its own Origin-Host in a Route-Record should drop the message (3005 DIAMETER_LOOP_DETECTED). A misconfigured default route pointing back is the usual cause.
• Watchdog storms after a flap — DWR interval too aggressive on a high-RTT or NAT'd link; tune Tw.

Related tools and reading¶

• On-site: Port Checker (3868).
• Related posts: SS7 vs Diameter, Charging systems: online vs offline.