ON THIS PAGE
 

Understanding RADIUS Profile-Based Server Instances for Multi-Instance Reachability

Understand how RADIUS profile-based server instances let you configure multiple logical RADIUS client instances to the same server address, each keyed by profile name with distinct source-address and routing-instance values, enabling parallel reachability across multiple routing instances.

RADIUS profile-based server instances let you configure multiple logical RADIUS client instances that reference the same RADIUS server IP address or fully qualified domain name (FQDN) while using different source-address and routing-instance values. When you configure system radius-profile <profile-name>, each instance is keyed by profile name instead of server address. This model lets you define parallel reachability paths to a single RADIUS endpoint across management and in-band routing instances (including tenant routing instances) without one configuration overriding another.

Each profile includes per-instance settings such as ports, shared secret, timers, retries, and RadSec (RADIUS over TLS) parameters. The system processes profiles in configuration order, so profile order controls authentication, authorization, and accounting failover behavior. For accounting, use system accounting destination radius profile <profile-name> with the same reachability controls.

Benefits of RADIUS profile-based server instances

  • Uses the same RADIUS server endpoint from multiple routing instances without configuration overrides, supporting separate management and in-band paths to the same AAA infrastructure.

  • Improves reachability by allowing independent paths (different source addresses and routing instances) to the same server, so authentication and accounting can continue if one path becomes unavailable.

  • Reduces workarounds by eliminating the need to create alternate server addresses to represent different logical client instances.

  • Clarifies operational intent by separating per-instance behavior (reachability, timers, shared secrets, and TLS parameters) into distinct profiles.

  • Provides predictable failover behavior because the system tries profiles in configuration order.

Overview

In the address-keyed hierarchy set system radius-server <address>, the server address is the unique key for the server entry. If you repeat the same <address> to change reachability attributes such as source-address or routing-instance, the configuration is merged into a single effective definition. This behavior prevents you from defining parallel paths to the same RADIUS endpoint from different routing instances or with different source IP addresses.

With the profile-based model, you define each logical client instance under a unique profile name (for example, set system radius-profile <profile-name> ...). You associate per-instance reachability and transport parameters—such as source-address, routing-instance, port, secret, timeout, retry, and TLS settings for RadSec—with that profile. Because the profile name is the unique key, multiple profiles can reference the same server address or FQDN while using different source addresses or routing instances. This separation lets you control which routing table is used to reach the server and which local address is used as the client source.

Profile order is part of the design. The system attempts profiles in configuration order, so the sequence determines how the device progresses through preferred instances and failover candidates. Control preference by ordering profiles intentionally.

Configuration model and constraints

For authentication and authorization, configure profiles under set system radius-profile <profile-name> ... and include the per-instance attributes you need, such as source-address <ip>, routing-instance <instance-name>, secret <string>, port <1..65535>, timeout <1..1000>, retry <1..100>, and tls ... for RadSec.

For accounting, configure the corresponding destination under set system accounting destination radius profile <profile-name> .... Specify the server address <address> and accounting settings such as accounting-port, accounting-timeout, and accounting-retry, along with source-address, routing-instance, and tls ... as needed.

Do not mix address-keyed syntax and profile-based syntax for the same function. Use one configuration style per use case.

In practice, you can configure up to ten entries. In the profile-based model, the limit applies to profile names rather than unique server addresses. Each profile represents one logical instance and supports one server address, one source-address, and one routing-instance. To provide multi-instance reachability, define multiple profiles and order them to match the failover sequence you want.