Previous page Section 5.1.1. DiaPeerDef Section 5.1.2. RelayAlgorithm (44 / 95)   Table of Contents Section 6. Configuring <MessageLog FILECARRIER> Next page

5.1.2. RelayAlgorithm Previous topic Parent topic Child topic Next topic

This parameter defines the how Diameters requests should be relayed to the peers. At least one DiaPeerDef parameters is required. Some load balancing relay algorithms support multiple destinations.
The following algorithms are currently supported:
  • FailOver
    Messages are sent to one peer only. If the peer becomes unreachable, the next configured peer is used. When a failed peer becomes available, it's used again.
  • HashBalance
    Messages are distributed between all configured peers. If a peer is unavailable, the messages are distributed between the remaining peers. Diameter Session-Id attribute is used as the distribution key.
FailOver can use run-time information about peers for selecting the next hop. For example when a peer advertises its supported applications, Peer-Auth-Application-Id can be used to select peers based on the applications they currently advertise.
HashBalance adds to its targets only those DiaPeerDef clauses that can be found during Radiator startup. Using DiaPeerDef-Identifier is recommended. Here's an example:

Example

# Balance load to multiple Diameter peers based on Diameter Session-Id attribute
RelayAlgorithm HashBalance

# Balance to peers defined with these Identifier values
DiaPeerDef DiaPeerDef-Identifier=aaa-server1
DiaPeerDef DiaPeerDef-Identifier=aaa-server2
DiaPeerDef DiaPeerDef-Identifier=aaa-server3
DiaPeerDef DiaPeerDef-Identifier=aaa-server4
Previous page Section 5.1.1. DiaPeerDef Section 5.1.2. RelayAlgorithm (44 / 95)   Table of Contents Section 6. Configuring <MessageLog FILECARRIER> Next page