This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
radiusdesk:profiles:fup [2023/01/02 12:05] admin [FUP Implementation] |
radiusdesk:profiles:fup [2023/01/02 13:59] (current) admin [Introduction] |
||
---|---|---|---|
Line 1: | Line 1: | ||
====== Fair Usage Policy (FUP) ====== | ====== Fair Usage Policy (FUP) ====== | ||
===== Introduction ===== | ===== Introduction ===== | ||
- | * From January 2023 RADIUSdesk now also includes a dynamite | + | * From January 2023 RADIUSdesk now also includes a powerful |
- | * We worked with our clients to come up with a innovative and flexible implementation that packs a punch. | + | * We worked with our clients to come up with an innovative and flexible implementation that packs a punch. |
* This document will start with a high level discussion about the various FUP requirements met with this implementation. | * This document will start with a high level discussion about the various FUP requirements met with this implementation. | ||
* It will then go on to do a hands-on FUP profile. | * It will then go on to do a hands-on FUP profile. | ||
Line 25: | Line 25: | ||
* The edit option of a profile includes **FUP**. | * The edit option of a profile includes **FUP**. | ||
{{: | {{: | ||
+ | * There are two sections for a FUP based profile. | ||
+ | * The first section specifies the basic speed when no limits are imposed. | ||
+ | * The second section contains a list of restriction FUP components to apply. | ||
+ | |||
+ | ==== Basic Speed Limit - No limits imposed | ||
+ | {{: | ||
+ | |||
+ | ==== FUP Components to apply ==== | ||
+ | {{: | ||
+ | * In the screenshot above we see two stage throttling. | ||
+ | * When the user's total usage reached 100Gb we will half its bandwidth. (reduce to 50Mb/s) | ||
+ | * Then when the user reaches a usage of 200Gb we will reduce its bandwidth further. (reduce to 25Mb/s) | ||
+ | * The FUP component is composed of the following items. | ||
+ | * Descriptive name. | ||
+ | * **If condition**. Options include **Time of day**, **Daily usage**, **Weekly usage**, **Monthly usage**. | ||
+ | * For **Time of day** there will be a start time and end time. | ||
+ | * For **data usage** there will be an amount of data. | ||
+ | * **Action**. When the trigger has been reached we can **block the traffic**, **decrease the speed** or **increase the speed**. | ||
+ | * An optional IP Pool that should be used if the component is triggered. | ||
+ | * You can combine various type of FUP components together. | ||
+ | * The logic that applies them will use the following rules. | ||
+ | * Blocking traffic will take preference. | ||
+ | * Components that decrease the speed will use the slowest (biggest decrease percentage) | ||
+ | * Components that increase the speed will use the slowest (smallest increase percentage) | ||
+ | * This essentially means the strictest component' | ||
+ | |||
+ | ===== Important points on FUP ===== | ||
+ | * For FUP to work correct there are two important items which has to be in place and work. | ||
+ | ==== Timezone setting on RADIUS Client ==== | ||
+ | * To determine the exact start of day, week or month the timezone that a RADIUS Client is deployed in needs to be specified. | ||
+ | * If this is not set it will fall back to the timezone that the RADIUSdesk installation is set to. | ||
+ | |||
+ | ==== Ability to disconnect a RADIUS user from RADIUSdesk ==== | ||
+ | * In order for the system to detect and activate an FUP restriction it needs to disconnect an active session of a user. | ||
+ | * The RADIUS Client should then re-authenticate the client where the restriction will be applied. (This is standard procedure for PPPoE connections) | ||
+ | |||
+ | ===== Nuts and bolts of FUP ===== | ||
+ | * This section will be for the readers that likes to know how everything works and fits together. | ||
+ | * When you use the FUP editor for a RADIUS Profile a few things happens behind the scenes. | ||
+ | * The system creates a Profile Component with naming the convention starting with **FupAdd_< | ||
+ | * This Profile Component contains one or more of the following FreeRADIUS custom check attributes. | ||
+ | <code bash> | ||
+ | ATTRIBUTE Rd-Fup-Bw-Up | ||
+ | ATTRIBUTE Rd-Fup-Bw-Down | ||
+ | ATTRIBUTE Rd-Fup-Comp-Count | ||
+ | ATTRIBUTE Rd-Fup-Profile-Id | ||
+ | ATTRIBUTE Rd-Fup-Burst-Limit | ||
+ | ATTRIBUTE Rd-Fup-Burst-Time | ||
+ | ATTRIBUTE Rd-Fup-Burst-Threshold 3172 integer | ||
+ | ATTRIBUTE Rd-Fup-Ip-Pool | ||
+ | </ | ||
+ | * FreeRADIUS is configured to use a combination of **unlang** and a Perl module to formulate the reply to an Access Request that a RADIUS Client will sent to the FreeRADIUS server. | ||
+ | * The Perl module will look for any entries in the **profile_fup_components** DB table that is associated with the RADIUS Profile. | ||
+ | * It will then try and determine which restriction to apply, if any. | ||
+ | * The Perl module can be found in /// | ||
+ | * It connects to the database and the credentials to connect with to the database is also specified inside this file. | ||
+ | * Should there a FUP component to be applied to a user, we will keep track of it in the **applied_fup_components** table. | ||
+ | * We then run a cron script **cd / | ||
+ | * If they are different we send a disconnect request to all the RADIUS Clients for that username (All the RADIUS Clients where the user might be connected to) | ||
+ | * This should initiate a re-authentication which will bring the applied FUP component in sync with the current active FUP component. | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||