Fair Usage Policy (FUP)

  • As of January 2023, RADIUSdesk now includes a powerful FUP package.
  • In collaboration with our customers, we have developed an innovative and flexible implementation that packs a punch.
  • This document first discusses the various FUP requirements that are met with this implementation.
  • Then we will create a practical FUP profile.
  • Finally, we will show you where you can tweak things if necessary for your specific environment or implementation.
  • In South Africa some of the major ISPs implement multiple layers of service for their FUP.
    • Bandwidth is reduced when a certain amount of data is consumed over the course of a month.
    • A further bandwidth reduction occurs when a second data usage milestone is reached.
    • Finally, when a third milestone is reached, bandwidth is throttled to a trickle.
    • When the new month begins, everything reverts back to normal speed.
  • Another requirement is the ability to assign an IP pool to a specific service level.
    • This is typically the case with ISPs that use Mikrotik PPPoE servers.
    • For example, there is a Premium IP Pool and a Best Effort IP Pool.
    • A user starts in the premium IP pool up to the point where their specified FUP is triggered.
    • After that, they are moved to the best-effort IP pool.
  • Communities using RADIUSdesk wanted to provide more bandwidth to their users between midnight and 7am, as uplink utilization is very low during this time, which can promote more even usage.
  • With these various requirements in mind we formulated the FUP package in RADIUSdesk.
  • To configure the FUP part of a profile, go to RADIUSProfiles.
  • The editing option of a profile contains FUP.

  • There are two sections for a FUP based profile.
    • The first section specifies the base speed if no restrictions are imposed.
    • The second section contains a list of the FUP restriction components to be applied.

  • In the screenshot above we see two stage throttling.
  • When the user's total usage reaches 100Gb, we halve their bandwidth. (reduction to 50Mb/s)
  • If the user then reaches 200Gb usage, we reduce their bandwidth further. (reduce to 25Mb/s)
  • The FUP component is made up of the following elements.
    • Descriptive name.
    • If condition. Options include Time of day, Daily usage, Weekly usage, Monthly usage.
    • For Time of day there is a start time and an end time.
    • For data usage there is a data amount.
    • Action. When the trigger is reached, we can block the data traffic, decrease the speed or increase the speed.
    • An optional IP pool to be used when the component is triggered.
  • You can combine different types of FUP components.
    • The logic it applies uses the following rules.
      • Blocking traffic has priority.
      • Components that reduce the speed use the slowest (largest percentage reduction)
      • Components that increase the speed use the slowest (smallest percentage increase)
    • This essentially means that the strictest action of the component is applied.
  • For FUP to work correctly, two important points must be present and working.
  • To determine the exact start of the day, week or month, the time zone in which a RADIUS client is used must be specified.
  • If this is not the case, it will fall back on the time zone to which the RADIUSdesk installation is set.
  • In order for the system to recognize and activate an FUP restriction, it must disconnect an active session of a user.
  • The RADIUS client should then re-authenticate the client to which the restriction is to be applied. (This is the standard procedure for PPPoE connections)
  • This section is intended for readers who would like to know how everything works and fits together.
  • When you use the FUP editor for a RADIUS profile, a few things happen behind the scenes.
  • The system creates a profile component with a naming convention that starts with FupAdd_<profile_id> and adds this profile component to the profile.
  • This Profile Component contains one or more of the following FreeRADIUS custom check attributes.
ATTRIBUTE Rd-Fup-Bw-Up          3166 integer
ATTRIBUTE Rd-Fup-Bw-Down        3167 integer
ATTRIBUTE Rd-Fup-Comp-Count     3168 integer
ATTRIBUTE Rd-Fup-Profile-Id     3169 integer
ATTRIBUTE Rd-Fup-Burst-Limit    3170 integer
ATTRIBUTE Rd-Fup-Burst-Time     3171 integer
ATTRIBUTE Rd-Fup-Burst-Threshold 3172 integer
ATTRIBUTE Rd-Fup-Ip-Pool        3173 string
  • FreeRADIUS is configured to use a combination of unlang and a Perl module to formulate the response to an access request that a RADIUS client sends to the FreeRADIUS server.
  • The Perl module searches for all entries in the DB table profile_fup_components that are linked to the RADIUS profile.
  • It then attempts to determine which restriction, if any, should be applied.
  • The Perl module can be found in /etc/freeradius/3.0/mods-config/perl/fup.pl
  • It establishes a connection to the database and the login information with which the connection to the database is to be established is also specified in this file.
  • If there is an FBD component that is to be applied to a user, we record it in the applied_fup_components table.
  • We then run a cron script cd /var/www/html/cake4/rd_cake && bin/cake fup that compares the applied FBD component with the currently active FBD component.
  • If they are different, we send a disconnect request to all RADIUS clients for that username (all RADIUS clients the user might be connected to)
  • This should initiate a re-authentication that synchronizes the applied FBD component with the current active FBD component.
  • radius/rad_fup.txt
  • Last modified: 2024/02/13 15:20
  • by system