This Wiki is available to view at but still under maintenance. PLEASE DO NOT EDIT THE WIKI UNTIL FURTHER NOTICE. We are attempting to restore missing edits which took place between Monday 8 and Thursday 11 April 2019, therefore the site is likely to be taken off line at any time. Updated 20:43 CEST 16 April 2019.
Child pages
  • radiator-flr
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

Operating a federation-level RADIUS server (FLR)

Federation-level servers (FLRs) are used to connect eduroam Identity Providers and eduroam Service Providers with each other, and also provide an uplink from the federation to all other eduroam federations.They are managed by National Roaming Organisations (NROs). The NRO may outsource the operation to a third-party, but will remain responsible.

Since the concept of an eduroam federation geographically usually maps to a country, FLRs are central to the deployment of eduroam in a country; there is conceptually only one FLR per country - but for resiliency reasons, it is recommended to provide multiple instances in a failover setup.

An eduroam federation comes with administrative requirements as well as technical ones. The exact requirements may differ between world regions. This document uses the European definitions and documents; which are believed to provide a good initial insight for the world-wide eduroam community. Readers from outside the GEANT service region should consult the responsible regional operator for their world region for further details after reading this document.

Administrative prerequisites

Operating a federation involves managing and supervising eduroam Identity Providers, eduroam Service Providers, as well as keeping authentication logs, fulfilling uptime requirements, etc. Prospect federation operators should read and understand the requirements in DS5.1.1 ("eduroam Service Definition and Implementation Plan") at, particularly sections 4.1.4 ("Roles and Responsibilities - NROs") and section 6 ("Requirements on Confederation Members").

Hardware requirements

RADIUS is a very lightweight protocol, and does not require expensive hardware setups. Even the busiest eduroam federations operate their server on a single contemporary hardware or Virtual Machine, without experiencing overload conditions.

As with every other professionally-operated service though, you should keep in mind that service uptime is paramount, and plan your procurement accordingly. Examples:

  • In the case of virtual machines, use an underlying infrastructure which enables you to migrate machines without VM downtime, if possible.
  • In the case of physical machines, use hot-pluggable parts where possible; and ideally, keep either spare hardware parts at hand or a set up a decent service contract.

eduroam Europe is in the process of migrating to RADIUS/TLS for its federation servers. In the course of this process, hardware requirements for the servers may change. This section will be updated as necessary.

Software requirements and setup

eduroam does not prescribe any particular RADIUS implementation. The technical requirements for eduroam however narrow the set of usable RADIUS server implementations, and the observed deployment of eduroam federation-level servers shows patterns regarding implementation popularity.

This section will present a few typical implementation setups. Note, however, that a federation is free to use a different implementation so long as the implementation can satisfy the eduroam technical requirements.

The sections for each implementation are accompanied by a skeleton configuration file, which should be usable almost as-is. However, please read and try to understand the entire corresponding section before applying the template - the information presented is valuable for daily operation and troubleshooting.


Radiator is perhaps the most popular server software in eduroam federations. The config file and examples below assume deployment on a UNIX-like platform, such as Linux or FreeBSD. Radiator can also be used on Windows; in which case you will have to adapt some path names etc.

Base configuration / logging / F-Ticks

Radiator expects the configuration to be in file /etc/radiator/radius.cfg.

The parameter LogDir defines the directory in which start-up logs and PID file reside. DbDir defines the path to Radiator's data files, such as dictionaries.

LogDir    /var/log/radiator
DbDir     /usr/share/radiator

The logs during normal operation are defined separately in <Log> stanzas. The verbosity of logging depends on the Trace level in the configuration: Trace 3 logs are recommended for normal operation, while Trace 4 logs provide verbosity for debugging, if needed. You can define several <Log> instances with different destinations. Let's define logging to syslog with verbosity level 3, and logging to a file for debugging purposes with verbosity level 4. We also define that the log file name changes on a daily basis to enable easy deletion of old files:

      Facility      local7
      LogIdent   log-syslog
     Trace        3

<Log FILE>
      Filename   /var/log/radiator/radiator.%Y%m_%d.log_
      LogIdent   log-file
     Trace        4

 You can also log authentication events in one line per authentication separately. The eduroam statistics system, F-Ticks, makes use of that feature. The F-Ticks logging facility is defined as follows:

<AuthLog SYSLOG>
        Identifier TICKS
        LogSuccess 1
        LogFailure 1
        LogSock udp
        SuccessFormat F-TICKS/eduroam/1.0#REALM=%R#VISCOUNTRY=%{eduroam-SP-Country}#VISINST=%{Operator-Name}#CSI=%{Calling-Station-Id}#RESULT=OK#
        FailureFormat F-TICKS/eduroam/1.0#REALM=%R#VISCOUNTRY=%{eduroam-SP-Country}#VISINST=%{Operator-Name}#CSI=%{Calling-Station-Id}#RESULT=FAIL#

Here, you need to adapt LogHost to the eduroam F-Ticks logging server (whose address you'll receive from eduroam operations), and the attribute marked with read. Its contents will become clearer later in the configuration file.

It is also useful to log each authentication locally, with more detail than is needed for F-Ticks. We suggest using the following log definition – it generates one single line of log output per authentication, which is very parser-friendly if logs need to be evaluated later: 

<AuthLog SYSLOG>
        Identifier            defaultAuthLog
        Facility              local7
        LogIdent              radiator
        FailureFormat         Access-Reject for %u (User-Name=%{Reply:User-Name}) at Proxy=%c (CSI=%{Calling-Station-Id}NAS=%{NAS-Identifier}/%N)
        SuccessFormat         Access-Accept for %u (User-Name=%{Reply:User-Name}) at Proxy=%c (CSI=%{Calling-Station-Id}NAS=%{NAS-Identifier}/%N) EAP=%{HexAddress:EAP-Message}
        LogSuccess            1
        LogFailure            1

You may also want to configure SNMP access to your server. SNMP allows remote monitoring of activity on a RADIUS server with tools such as RADAR from OSC (, or drawing simple graphs of activity by rgraph from CESNET (

      ROCommunity xxxxxxxxxxxxxxxxxxxxxxxxx
      Managers        localhost

Next, the ports Radiator will use to listen for Authentication and Accounting requests must be defined. The port numbers 1812 and 1813 were assigned to the RADIUS protocol by IANA. Note: Exceptionally, you may come across very old RADIUS equipment which uses non-standard ports 1645 and 1646. Please see the Radiator documentation how to handle these, or consider upgrading the corresponding equipment.

AuthPort    1812
AcctPort    1813
Client definition

In the client section, all possible peers from which the FLR server is going to accept requests, are listed. I.e. it includes all eduroam SPs in the federation and the uplink to the other federations (in Europe, to the ETLR servers).

For RADIUS, individual clients with their IP address have to be listed and a "secret" has to be assigned to them. As this secret is the only thing that protects the communication between the RADIUS servers from eavesdropping, it must be cryptographically strong (suggested: exactly 16 characters) and well protected.

The clients should also be tagged with the attribute Operator-Name. which takes the format "1<domainname>", and for F-Ticks classification reasons, also with the country the eduroam SP is located in (or UNKNOWN for clients whose geographic location isn't known).

Example: you have an eduroam SP which operates on the address and have negotiated the shared secret "adf7856asdcvxb5p" with it. The SP is based in Antarctica, and uses the domain name "". You want it to show up in log files as "icecold-radius".

# my eduroam SP in Antarctica

      Secret           adf7856asdcvxb5p
      Identifier       icecold-radius

The clients for your uplink to ETLRs will look similar to the following. Note they are tagged with Country=UNKNOWN because requests coming from these countries can originate from all over the world (they connect all other federations). For the same reason, it also does not make sense to set the Operator-Name attribute.

      Secret           (as negotiated with eduroam OT)
      AddToRequest     eduroam-SP-Country=UNKNOWN

<Client localhost>
      Secret         mysecret
      DupInterval 0

It is necessary to mark each host by a unique identifier, which is later used to prevent loops in the hierarchy (note that this identifier is for local use only, therefore select an identifier that is meaningful to your implementation). and are the European top-level RADIUS servers.

Handling empty realms

Theoretically, empty realms should not reach a National RADIUS Proxy, but if they do this code will prevent the National RADIUS Proxy from sending these empty realms to the international top-level proxy servers. A reply will be added to the rejected requests explaining the reason for rejection. Replace <TLD> with the federation top-level domain you are authoritative for.

<Handler Realm=/^$/>
      StripFromReply         Reply-Message
      AddToReply              Reply-Message="Misconfigured client: empty realm! Rejected by <TLD>."
      AuthLog defaultAuthLog

Proxying to an organisation with one RADIUS Server

In the case in which an organisation has only one server, configuration is relatively easy:

<Handler Realm=/^orgA\.tld$/i,
      <AuthBy RADIUS>
                RetryTimeout             3
                Retries                       1
                FailureBackoffTime    0


                <Host radius.orgA.tld>
                          AuthPort           1812
                          AcctPort           1813
                          Secret               xxxxxxxxxxxxxxxxxxxxxxxxx

      AuthLog defaultAuthLog

Realms should be pattern matched case-insensitive, because users sometimes type their realms using upper case letters.

The configuration directive "Client-Identifier=/^(?!radius.orgA.tld$)/" blocks RADIUS packets from radius.orgA.tld with realm orgA.tld from entering this Handler.

If such a packet is received it will be rejected by the handler matching realm=/.*\.tld$/i. This prevents loops between the national proxy and the server of orgA.tld.

Servers to proxy should never be marked as dead, because in doing so Radiator will not try to communicate with them until BackoffTime expires, even if that server is already live again.

Proxying to multiple RADIUS servers

Top-level RADIUS servers (confederation or federation) are duplicated for better reliability of the eduroam service, as required in the policy document [GN2DJ513,2]. Also some organisations have multiple RADIUS servers for the same reason. To use multiple servers in eduroam, a special setup has to be used. Standard detection of "dead" hosts based on timeout will not work here; timeouts might be caused by the infrastructure behind the direct peer of RADIUS server, so the server cannot assume that its peer is off-line. But if it really is down, a switch to the backup server must be performed. Unfortunately the RADIUS protocol does not provide a clear way to do that.

The problem can be solved by using a special configuration developed at CESNET and described in the article "Dead-realm marking feature for Radiator RADIUS servers" ( realm.html).

The idea behind the dead-realm marking is quite simple. Instead of marking the server dead for all realms (as in dead-host marking) just the particular realm on the host is marked dead and requests are routed to another configured host.

The variable dr_timeout controls how long a realm will be marked dead on a particular host. 3600 seconds is the suggested value. Much lower values will cause the system to check the dead primary server too often. Higher values can be considered if the backup server is equally as powerful as the primary server.

_StartupHook sub        

Unknown macro: {   require "/etc/radiator/"; }

DefineFormattedGlobalVar    dr_timeout 3600

Following the two AuthBy sections are definitions of the servers, which will be used as a pool for destinations defined later.

NoReplyHook and ReplyHook are necessary for the dead-realm marking feature, a Perl implementation is available online at A copy version 2.0 of this implementation is in the ZIP file which accompanies this document.

NoReplyHook is called when no reply is received from the RADIUS server after two attempts within six seconds. In this case the processed packet is ignored, the realm is marked as dead on this server and when a subsequent packet with the same realm is received it will be forwarded to the other defined server.

ReplyHook is called when a response from the server is received; if the realm is marked as dead it will be unmarked and thereby identified as live.

                RetryTimeout                         3
                Retries                                   1
                FailureBackoffTime               0


                                AuthPort               1812
                                AcctPort               1813
                                Secret                  xxxxxxxxxxxxxxxxxxxxxxxxx

_               NoReplyHook sub

Unknown macro: { DeadRealm}

_               ReplyHook sub

Unknown macro: { DeadRealm}



             RetryTimeout                        3
             Retries                                  1
             FailureBackoffTime              0


                               AuthPort            1812
                               AcctPort            1813
                              Secret                xxxxxxxxxxxxxxxxxxxxxxxxx

_             NoReplyHook sub

Unknown macro: { DeadRealm}

_             ReplyHook sub

Unknown macro: { DeadRealm}


Handling unknown realms in the own federation

After the last connected realm, it makes sense to reject all known-bad realms and all unknown realms which end in the own federation's top-level domain. One such invalid realm is seen quite often due to supplicant misconfiguration: (this is the default realm in an unconfigured Intel PRO/Set Wireless supplicant). The following stanza rejects this realm with an appropriate error message and blindly acknowledges all Accounting requests.

<Handler Realm=/myabc\.com$/i>
                           StripFromReply   Reply-Message
                          AddToReply         Reply-Message=" Misconfigured client: default realm of Intel PRO/Wireless supplicant! Rejected by <TLD>."
                         AuthLog defaultAuthLog

Add the following stanza after the last valid realm to catch and reject all unknown realms that end in the own TLD:

<Handler Realm=/.*\.tld$/i>
                         StripFromReply    Reply-Message
                         AddToReply         Reply-Message=" Misconfigured supplicant or downstream server: uses non-existing realm in <TLD> federation!"
                         AuthLog defaultAuthLog


The following directive (DefineFormattedGlobalVar) defines the variable dr_TOPLEVEL_server_list and assigns a list of servers responsible for the handler marked as TOPLEVEL to this variable.

DefineFormattedGlobalVar          dr_TOPLEVEL_server_list __,

The handler with the filter Realm=/.+$/ will receive any request that will not be caught by more specific filters before (Realm=/^orgA.tld$/i, Realm=/.\.tld{*}$/, Realm=/$/). In this example it will be all requests that belong to other TLD's than the ones defined on this server – requests that have to be forwarded to top-level servers.

RequestHook will use the value of Identifier (= TOPLEVEL) defined in this handler to search the variable dr_TOPLEVEL_server_list holding the list of servers. It will forward the request to a server not marked dead, or if all are marked dead the one with the oldest dead-realm mark.

<Handler Realm=/.+$/>                    Client-Identifier=/(?!$)/>

           Identifier TOPLEVEL

           <AuthBy INTERNAL>
_                             RequestHook sub

Unknown macro: { DeadRealm}

              AuthLog defaultAuthLog


      Secret          xxxxxxxxxxxxxxxxxxxxxxxxx

      Secret          xxxxxxxxxxxxxxxxxxxxxxxxx

  • No labels