In the billing users are divided into the following classes:

Each user in the billing system can have one or several user accounts.

A User account is a system object that contains information about the user's financial status. All services that are provided to the user, both separate and as part of a tariff plan, are linked to the user's account through service and tariff links.

Account may get blocked, which suspends all services attached to it. There are three types of blocking in the UTM 5+:

Additional parameters for each blocking type can be set in the Charge policy settings. For example, recalculate the periodic fee when blocking is activated.

A service is a system object that defines tariffing rules.

The services are connected to the user's account via service links. Service links can be created one by one or in groups as part of a tariff plan.

In the billing services are divided into two sorts and eight types.

Sorts of services:

Service types:

The service costs are specified excluding taxes.
Tax rates, including the value-added tax (VAT) and sales tax, are specified separately in the user account properties and considered in all charge-offs.
All types services, except for One-time services, have parameters of start date and end date of the service. The start date is the date when the service provision and fee charges start. The end date is the date when the providing of service stops, together with the charge-offs for the service. At this date the service is removed, if it is not attached to any service link.
Such types of services as IP traffic, Dial-up, Hotspot, Telephony and IPTV have a periodic cost component as one of their parameters. The corresponding charge-offs are made in the same way as for a periodic service, but in reports they are displayed as charges for services of corresponding types.

A Service templates are used to create services that are part of the tariff plans, and in case of automatic change of tariff plans at the time of closing the account period. The template is not a service, but a parent entity for the tariff plan services.
You can create one template for each type of service in advance, for example, a service template for the services with periodic charges, for the Internet traffic using a real IP address, and set the frequently used parameters for this type of service in the appropriate template. These parameters will be copied by default to the derived tariff plan services, once those are created.

A Traffic class is a marker that determines to which traffic category it belongs. Classification of traffic is necessary to be able to charge it at different costs.

Traffic is checked against all classes in the decreasing order by ID until first match. If no match has been found, the traffic is attributed to the class with ID=0 (unclassified).

Traffic belongs to the class in the following cases:

A Traffic subclass is a set of attributes that determine whether a traffic class belongs to that class. Traffic is assigned to a subclass based on a set of attributes present in traffic data. The data contained in NetFlow packets (source and destination address and port) as well as the address of the NetFlow provider (IP router) can be used as attributes.

Traffic belongs to the subclass in the following cases:

An Accounting period is a period of time to which various periodic activities are related, such as charge-off for periodic services.

Accounting periods are used for billing users at the same time, for example, from the first day of a month till the first day of the next month.

When an accounting period is closed, the following steps are performed:

The new period starts exactly at the end of the previous accounting period. The end time is set automatically depending on the type of period. The period type (i.e. its duration) as well as the number of charges-off per week remain unchanged. All service and tariff links referring to the previous accounting period are linked to the new period.

A Time range is a period or a combination of periods of time. Time ranges are used for services that are available only in certain periods of time, or services whose cost depends on time.

A Coefficient scheme is a sequence of coefficients, applied to the periodic service fee. The scheme provides the possibility to change the service cost according to the set schedule.
For example, the cost of service in the first month is 50%, from the second to sixth month is 100%, the seventh month is 75%, and then all the time 100%. In this case, two coefficients should be included in the scheme: 0.50 for the first month and 0.75 for the seventh month. In those periods when the coefficients from the scheme are not valid, the cost of service is 100%.

To connect the scheme of coefficients to the service is possible while creating or editing the service.

It is possible to make changes in the coefficients scheme: add and delete coefficients, change their period of validity and values. The updated coefficient scheme will be used for new service links and will not affect any of existing service links.

A Currency is the billing unit.
The billings operates with internal conditional units. The currencies are only used for payment processing and billing. When making payments, currencies are converted to internal units. On the other hand, when a bill is issued, the internal units are converted to some currency.

Each currency is associated with the rate, interest (artificial correction to the rate) and history of rate changes during the whole period of billing. The history of exchange rate since the system’s deployment is also available in order to perform financial operations post factum. It is possible to update the rate online.

Each user (a customer) is associated with some preferred currency for billing. By default, the associated user currency is determined by the value of the system parameter ISO code of the system currency. NetUP UTM 5+ provides an opportunity to change the currency assigned to the user to any other one registered in the billing at any time. As a result of the currency change, all bills will be displayed in the new currency, regardless of the date when they were generated by the system, before or after the currency change.

A Tariff plan is a bundle of services provided as a package. Attaching the tariff plan to a user, you can activate the whole package or exclude some services, as well as adjust some service settings.

The tariff plan is attached to a user account via a tariff link and tariff plan services attached via service links. Attaching the tariff plan you must select an accounting period, at the end of which the plan can be prolonged for the next period or replaced by another compatible tariff plan.

Tariff plans are compatible if they have one-to-one correspondence between their services. This means that the new tariff has only one service corresponding to the service from the previous tariff. In this case, the billing can change the tariff plan and save useful information from service links (for example, IP addresses in IP traffic service) without any operator intervention.

To make your tariff plans compatible, add to them services that are created with the same service templates. You can modify parameters of the service created by the template while adding this service to the tariff plan. Modifying will not edit the template. Any changes will affect only the service you add.

For example, a user has tariff plan #1, which includes service A, and it is expected that the user will switch to tariff plan #2 from the beginning of the next accounting period. The tariff plan #2 includes service B. In order for the correct transfer of all parameters of the service A to the service B, it is necessary that both services are produced from a common template.

Incompatible tariff plans can also be switched, but services that have no match in the tariff plan of the next accounting period will be deleted.

A Charge policy is a set of rules that are used when charging a user account. These rules are applied when a customer for some reason didn’t receive the service for some part of the accounting period.
For example, when a service was attached to a user in the middle of an accounting period, so the user will receive the service only for the rest of the accounting period, or when a user uses voluntary blocking, because the user does not want to receive the services for a while.
In such cases, the charge policy permits a recalculation of the service cost and charging a smaller amount or a refund if a charge-off has already been made. The recalculation is made proportionally to the part of the accounting period when the service was provided or will be provided in fact.

Besides the cost recalculation, the charge policy permits to recalculate the volume of provided services. For example, it is possible to recalculate the amount of prepaid traffic for the service that provides Internet access, or to recalculate the amount of free minutes for a telephony service.

Recalculation of the periodic part of the service cost and refunds are regulated by the following rules:

The time and date of the service link creation may not match the current time and date and may be set in the future or in the past. If the date and time of the service link creation is set in the past, the current date and time is used instead.
This means that Recalculated price = (Full price for accounting period) × l1/L, if the starting date has been set in the future.
Otherwise Recalculated price = (Full price for accounting period) × l2/L.

The same rules are used to recalculate the amount of prepaid traffic or prepaid calls duration.

Besides in the charge policy settings you can set the moment when a repay should be made:

For example, if the user blocking was activated when the accounting period has not yet ended and the funds for services during this accounting period have already been charged-off in full, then it’s necessary to return part of the funds to the user.

There are three types of blocking in the UTM 5+:

For each blocking type in the charge policy, you can set the following options:

When recalculating the amount of prepaid traffic, prepaid calls or the periodic fee, it decreases corresponding to the part of the accounting period during which the account was blocked. Therefore if a user account is blocked and then is unblocked in the next accounting period, recalculation will take place twice.

Periodic fee charges for several services are done in an arbitrary order. If a charge-off leads to the system blocking of some user account, the rest charges are made according to the charge policy settings for the system blocking.

There are several ways to make a payment:

To divide payments by types, the billing uses payment methods.
The methods are combined into a corresponding reference book and by default it contains: cash payment, wire transfer, card payment, credit. You can add additional methods to the reference book.

The amounts of Credit type payments are displayed in a separate column on the user's personal account page. For such payments, the obligatory parameter is the Expiration date on which they are undone.

For example, a user has a negative balance – “-100 rubles”. The administrator gave this user a credit in the amount of 200 rubles for 3 days. In this case, the user has 3 days to recharge his balance, during which he will not be blocked, but will be able to use all already paid services and even connect some new services to the amount of 100 rubles. If the amount of services exceeds 100 rubles, the user's personal account will be blocked until his balance is positive or until a new credit is granted. If the user activates services during the credit period, the cost of services is charged from the balance. So the user will eventually pay the total amount for all services, but not the credit amount.

Also in the billing it is possible to make payments that allow to top up user's balance temporarily. Such payments are called expiring payments. They are also required to have an expiration date, but all methods can be used except the Credit.

Expiring payments are summed up with the user's balance and displayed in the personal account before the payment expiration date. If the amount of charges for the specified period is less than the amount of the expiring payment, the unused balance of the payment will still be charged off from the user's account when the expiry date comes.
If other payments are received before the expiry date, the combustion of all payments will be postponed until the latest expiry date.

The billing has the special report for tracking expiring payments.

The UTM 5+ has an option of payment rollback. The administrator of UTM 5+ can make a payment rollback via the context menu in the payment report.

Nominally, the rollback is done by making a payment of special method (Rollback) having the opposite sum.

The billing may work with prepaid cards intended for activation via web interface or via the utm5_tray application. A card may have either limited term of use, or an expiration date.

If the card is activated on the login page, a card user is generated by the system. User’s balance is set to the card balance value. User’s login is set to card_NUM, where card is the prefix of card user login and NUM is a number of the card.

If the card has a tariff plan attached to it, the services from this plan will be attached to the user’s personal account. If the card has limited term of use, its balance goes to the user’s account in a form of expiring payment with this term of expiration.

If the card is activated by an already existing user, the card’s balance is added to the user’s account, and the tariff plan associated with the card (if any) is ignored.

In the billing you can generate the following types of documents:

Documents are generated automatically from templates.

Generated documents except for contracts are not stored in system, and are rather generated immediately before use.
User contracts may be generated using a template or uploaded from a file. Each generated or uploaded contract is stored on User => Documents page.

Invoices may be created either automatically or manually. Manual invoices have no effect on the user’s account balance.

One-time services are billed as soon as these services are activated. If the user’s account has its Payment in advance option checked and the service’s charge method is set as At the start of the period, the invoices for the periodic services and for the periodic portion of special services’ price are issued at the beginning of an accounting period. Otherwise they are issued at the end of an accounting period.

Items in the automatic invoices are aggregated by tariff links (with the exception of telephony services, if any, which remain separated from the rest) and by accounting periods. Charges for the new services (those added during the current period) are also not aggregated and stay in a separate invoice, if Payment in advance is checked.

After having been generated from a template, an invoice may be edited for printing, but the changes can not be saved.

Invoices with negative VAT rate are hidden in the report.

The Core is the main module responsible for the database access. The core provides access to it and processes incoming information according to the internal rules (such as tariffication, periodic write-offs). The core structure allows to use all provided resources evenly in case of high loads.

The billing core can interact with various routers and traffic information providers, as well as work over the NXT protocol with external applications. NXT (NetUP XML Transaction) is an application layer protocol that uses TCP as the transport protocol and SSL to encrypt data and authenticate the sender. A transaction is the basic data exchange unit. Each transaction may be addressed to one or more system components and includes a set of events intended for processing by the receiving component.

Besides the core, the billing includes auxiliary utilities responsible for the work via the RADIUS protocol, import of log files, low-level operations via the URFA protocol, interaction with payment systems and user web interface operation maintenance. Read more about the utilities in the corresponding sections.

The URFA (UTM Remote Function Access) module provides access to the billing core. It authorizes users according to CHAP scheme and provides the work of a remote user. The protocol supports data transmission and function calls.
URFA checks up whether a certain user has access to the function called, and on positive check allows the user to start the data exchange. Otherwise the access is rejected.
Each session is given a 128-bit replication-free system ID number (SID). SID can be used repeatedly to gain access to the system. In case of error when the session is restored, the SID will be deleted and the user will have to enter his login and password once more. The SID is related to the user's IP address and is automatically deleted after a certain downtime. An option of session restore is available, which requires the system user’s rights.

System users have negative user ID. By default, the billing has the following system users:

A system user has the following properties:

The access rights of a system user are determined by the system group where the user belongs. If a system user is a member of more than one system group, that user has summary privileges for all groups that they belong to. All calls for forbidden operations are registered in the system core journal. By default, the billing has the following system groups:

Depending on the class, a user has some list of permitted functions:

Only system users are allowed to communicate over Stream, NXTv1 and NXTv2 protocols.

If a system component needs to log a message, it goes to the logging module and sends it an event level and message text.
There are following event levels:

The logging module puts the text to the appropriate log stream. The selection of the stream depends on the module settings and the event level. The logging stream is associated with the file specified in the module settings. By default all streams are associated with the standard error stream. There are following log streams:

Some components may activate the built-in mechanism of log file rotation. At that, after logging an event the module checks file size against some specified threshold. If the file size exceeds the threshold, the file is closed and renamed to include a certain suffix. If the file quantity is limited, the suffix is " .0 “. If the file quantity is unlimited, the suffix is " .<timestamp> ", where <timestamp> is the Unix Time Stamp of file closing time. If a file with such suffix already exists, the suffix is incremented. After that the number of files is also checked and older files are removed if the number exceeds the limit.

Logging settings for each particular module are described in more detail later on.

The versatile nature of the billing system allows integrating it into existing or intended network infrastructure in various ways:

You can get more details about all modules and billing features from our managers, who will help you to figure out what modules should be used to perform your tasks.

UTM 5+ contains an integration module intended to work with Rentsoft system, which is a distributor of software and digital content.
The charges for the subscription are made along with the charges for the Internet services. Services provided by Rentsoft are not included in the list of UTM 5+ services. The corresponding charges, however, are registered and gathered in a Custom charges report. The invoices for these charges are issued immediately upon the charge-off.
For more details on the possible settings and parameters of the integration module, see: rentsoft.ru/provider/new/netup_netup300/

Step #1. Install the UTM 5+ package

The installer will create /netup/ directory to store program data, configuration and log files. It will also create the following startup scripts:

Step #2. Check and edit the core configuration file

Go to the /netup/utm5/ directory, open the utm5.cfg file and check the parameters which are responsible for database interaction.

If you already have a database, specify its parameters (type, name, login/password, encoding, etc.) in the configuration file so that the core will connect to it at the first launch.

If you do not have a database, then at the first launch of the core it will be automatically created with the parameters specified in the configuration file.

If you want to enable automatic updating of the database structure and indexes at every core launch, enable verify_database and verify_database_index parameters in the configuration file. By default, the first option is enabled and the second option is disabled.

Step #3. Activate the license

After successfully installing the UTM 5+ package, and setting all the required configuration file parameters to appropriate values, copy the reg.sql (license key file) to the /netup/utm5/ directory

Step #4. Run the core

Start the billing core with the following command: /etc/init.d/utm5_core start

When the core is launched, the license will be automatically activated, and then the reg.sql file will be deleted. The core will connect to an existing database or create a new one, according to the parameters in the configuration file.

Step #5. Get ready to launch the user cabinet and connect payment systems.

To be able to install new payment systems and service requests from user cabinet, unpack the utm5_customer_portal.zip archive and run the install.sh file as root.

You can add the utm5_customer_portal to the autorun. To do that, use the command:
systemctl enable utm5-customer-portal.service

To start, you need to execute the following command:
systemctl start utm5-customer-portal.service

Step #6. Check and edit the customer portal configuration file

Go to the /netup/utm5/ directory, open the customer_portal_config.env file and check parameters.

Step #1. Install nginx on your server

Use the command:
sudo apt install nginx

Step #2. Edit the configuration file

Go to the directory: /etc/nginx/sites-enabled/default

Replace the content with:

Step #3. Unpack the utm5_http.zip archive to the /var/www/utm directory

Download the archive in your personal cabinet and run the following commands:

Step #4. Restart nginx

sudo service nginx stop
sudo service nginx start

Step #5. Make sure that the web interface and the user cabinet are available

Enter <your server address>/admin in your browser, for example, 10.1.5.229/admin. If the browser displays a login page, you did everything correctly.

Enter <your server address>/cabinet in your browser, for example, 10.1.5.229/cabinet. If the browser displays a login page, you did everything correctly.

Step #1. Install Docker and Docker-compose

Run the command:

apt install docker docker-compose -y

Step #2. Create docker-compose.yml file.

Save to this file the following configuration:

Step #3. Run docker-compose

Run the command:
docker-compose up

Step #4. Connect to the billing using the web interface

Enter <your server address>/admin in your browser, for example, localhost/admin. If the browser displays a login page, you did everything correctly.

Step #5. Make sure the user cabinet is available

Enter <your server address>/cabinet in your browser, for example, localhost/cabinet. If the browser displays a login page, you did everything correctly.

The URFA request handler (UTM Remote Function Access) is a server that invokes remote procedures.
It receives connections of clients and executes requested commands in the core. This component serves mainly as an organizer of the user and administrator interfaces.

The NetFlow buffer receives traffic data in NetFlow format version 5.7, 9, and 10 (IPFIX). Devices that do not support statistics delivery via these protocols must rely on some auxiliary utility to convert their output into compatible format.

The Traffic classifier sorts traffic by class according to the parameters specified in billing settings.
Traffic information for one customer, that hasn’t been tariffed, is stored in the primary store. After tariffication this information is extracted from the primary store and is placed to the secondary store. The customer's account is charged for the cost of the traffic stored in the secondary store when the cost of the traffic exceeds a certain amount, when it reaches the storage time limit, when the price of the traffic changes (e.g. when the traffic price depends on the amount consumed), when the core receives a SIGHUP signal and when an accounting period is being closed.

Tarifficator and classifiers are responsible for tariffication of all services, including IP traffic services. They convert the number of services provided by the operator into money equivalent, with all the dependencies specified by the billing administrator.

The Journaling module records all UTM 5+ events in log files, which allows administrators to diagnose and get information about failures.

The DBA (Database access) module converts internal data requests to external database requests.

Data is received via NetFlow buffer and URFA request handler. Input data are read from the database when the system is launched.

NetFlow data go to the business module where they are processed and all necessary charge-offs are calculated. At peak workloads NetFlow can be buffered to reduce possible losses. Raw NetFlow data are stored in files. A module that stores this data is created in a separate thread at startup and, if possible, with high priority.

The location of the UTM 5+ core executable file is /netup/utm5/bin/utm5_core
On the command line, you can specify the following parameters:

There are three ways to run the utm5_core:

By default, the UTM 5+ core uses this configuration file – /netup/utm5/utm5.cfg

Config files have the following format: parameter=value.
A sequence of symbols before the equals sign is treated as parameter’s name, while the one after it stands for the parameter’s value.
Whitespaces count.
Empty lines are ignored.
A line starting with # is a comment.

The Dynashape module is intended to regulate channel bandwidth (shaping) depending on the time and volume of traffic consumed by a user. The system core composes the firewall rules according to the settings, and passes them for execution to the external software. The development of shaping control executables for the particular networking configuration to the administrator’s area of responsibility.

The IP telephony module is intended for processing authorization requests and consumed services accounting for voice gateways, gatekeepers and voice proxy servers. It supports both traditional and IP telephony. The data to be accounted for may be based either on UTM 5+ RADIUS server requests (see Services ⇒ RADIUS) or on CDR files parsed by the utm5_send_cdr utility (see Utilities ⇒ Text files import).

UTM5 has two options for activating the prepaid Internet cards and receiving the dial-up service: guest access and conventional access with automatic registration of users. After registration the user enters the system with one’s own access parameters. After registration the user enters the system with one’s own access parameters. In the second case the user enters card number and a pin code as a login and password for dial-up connection, and then is automatically registered and gets access to the Internet right at once.

For automatic registration of users using the options above, you have to generate the tariff plan and connect the dial-up service to the user with the corresponding connection cost.

On creating the tariff plan you have to generate the prepaid cards pool and bind it to the tariff plan.

This module provides the possibility to register new users in the system and make the first payment for the connected services via web-interface.

To connect the Captive Portal:

By default the module's web interface is available at the following address: your.server/captive-portal/, where your.server is the name of your UTM 5+ server.

This link opens a registration page where a users has to enter the details: email, name and password. Once the details have been entered, the user should click the Next button to go to the page with available tariff plans.

When the tariff plan has been chosen, the user should click the Next button once more. As result, the user will see the info message about redirecting to the Payment Express to pay the fee. To make the payment, the user should click Register and proceed. After that a page for credit card data entry will be opened and user registration data will be transferred to the UTM 5+ database.

The user can make a payment:

If for some reason the payment process has not been completed, the user can log on to your.server/cabinet using the email and password specified at the registration.

After payment, the module will work in the standard way (see Hotspot).

The Hotspot module is intended to provide Internet access paid by the hour. User authorization is performed using RADIUS protocol or via the user Web interface.

When using web interface for authorization, after entering card number and PIN, the page will update periodically to keep the server aware that the service is still being provided. If the refresh does not happen in due time because the user has closed the authorization page, the session expires. When the session is either expired or explicitly closed by the user selecting Close in the menu, the Internet access is blocked and the user is charged for the session’s duration. The expiration may also occur due to running out of money.

To set the lifetime of a hotspot session, go to the Settings ⇒ Systems ⇒ Other in the web interface and specify the amount of seconds for Hotspot session timeout from the moment of last refresh.

To use the hotspot module, add a tariff plan containing the hotspot service. You can set different cost of the service for different time ranges, as well as create a list of allowed networks to login from, and the number of simultaneous sessions for the given login.

To use the hotspot module along with prepaid cards, it is necessary to create a pool of cards and connect them to the tariff plan containing the hotspot service. After getting a card, a user should first register it in the Auto register user section of the web interface and obtain a login and password. They are subsequently used for authorization on the Enter (hotspot) page.

If you need billing on traffic for hotspot users, use hotspot service together with IP traffic service. Check the Dynamic IP address allocation option in the properties of both services. User authorization on the UTM 5+ web interface would require the login and password stored in the properties of the hotspot service link.

This module allows to integrate billing with NetUP IPTV system. Due to this module UTM 5+ gets an opportunity to add services of watching TV channels and charge users for using these services. It is also possible to create service links for services of this type and, based on them, manage access to watching TV channels (deactivate access if the personal account is blocked, grant access if it’s paid for).

It is possible to integrate UTM 5+ with IPTV systems of other companies. In this case, the interaction can be done through RFW events and third-party scripts.

The integration module interacts with IPTV middleware. In order to let the module connect to NetUP IPTV Core, the DNS server on UTM 5+ server should be able to resolve IPTV domain names. All the other billing systems interacting with the IPTV cluster core must be disabled.

NetUP IPTV system uses access cards for user authorization. The card is a mandatory condition to access IPTV services. The integration module allows to create access cards and generate activation codes.

Client's TV channel access is managed by interacting with the NetUP IPTV Middleware system. When UTM 5+ needs to grant access to media content, e.g. when an IPTV service is attached to user’s personal account, it sends a request to IPTV middleware to grant access to certain media content to access card owner for an unlimited period of time. When it needs to prevent a user from accessing the content (e.g. when user switches tariff plan), UTM 5+ requests from IPTV middleware to set access end time for user’s access card to that media content to current time, which means that the content becomes no longer available.

To connect a NetUP IPTV, follow these steps:

You can see the example of creating a NetUP IPTV service and connecting it to the user in the Quick Start section.

Basically, a template is an *.odt document that may contain variables E.g. user name, account balance, etc). During the generation of the document, the variables will be replaced with the corresponding values. For a complete list of variables, see Templates variables.

See Quick Start for an example of working with a document template and how to use an alternative document number.

Depending on the template type, it may include variables from the following groups:

For a description of variables and iterated variables, see below.

The RADIUS server interacts with the UTM 5+ core via the Stream protocol, and with access servers (hereinafter – NAS) via the RADIUS protocol according to the following standards: RFC 2865, 2866 and 5176.

The Remote Authentication Dial In User Service (RADIUS) protocol provides authorization, authentication, and accounting between the NAS and the Authorization Server (RADIUS server).

If the NAS interacts via the RADIUS protocol, it does not keep the user base. To connect the user, the NAS sends an Access-Request to the RADIUS server.
If the RADIUS server permits a connection, it responds with an Access-Accept, otherwise it send an Access-Reject to the NAS. If the RADIUS server needs more information, it sends an Access-Challenge request to the NAS.

If the NAS is configured to send connection information, after establishing the connection, the RADIUS server sends an Accounting-Request that contains information about starting the session. Depending on the configuration, the NAS may also send additional periodical Accounting-Request containing current status info on the connection.

When a connection is broken, NAS must send a summarizing Accounting-Request, given that some Accounting-Request for this connection have already been sent before.

On receiving an Accounting-Request, the RADIUS server creates, changes or deletes an object associated with the connection. Depending on the request contents, some additional actions may be performed to maintain the delivered information on the connection.

After successfully handled an Accounting-Request, the RADIUS server sends to NAS a confirmation(Accounting-Response).
On failure, no response is sent.
Packets from an unknown (not registered) NAS are ignored.

RADIUS service and NAS exchange RADIUS packets via UDP. To receive Access-Requests, the RADIUS server usually uses port 1812 and port 1813 to receive Accounting-Requests.

Generally a RADIUS packet contains the following fields:

Each RADIUS attribute contains specific information on a request or a response.

Generally, a RADIUS attribute looks as follows:

Some of the attributes may be included in a packet more than once. In this case their interpretation depends on the attribute type. Order of attributes is important.

Additional attributes set in NAS, services and service links settings are also included in the packet. Attributes set in NAS settings are added first, then go the attributes from the services settings and then the attributes from the service link settings. The UTM 5+ allows to perform certain actions when adding an attribute like replace or remove an attribute added earlier. That is, the attributes from service link settings have the highest priority.

From this point on, the RADIUS attributes are referred by common name followed by the typeID in parentheses. For example, User-Name (1).

There is a certain attribute type Vendor-specific (26) designed to store extended vendor-specific data.

These data are interpreted as follows:

From this point on, the vendor-specific attributes are referred by common name followed by the semicolon-separated Vendor-Id and Vendor-Type in parentheses. For example, Cisco-AVPair (9;1).

The DHCP allows you to associate a static IP address or a dynamic address pool with a MAC address, switch or a certain switch port. It receives messages and processes them according to RFC 2132.

The server uses data from the database, communicates with the UTM 5+ Core via the Stream protocol and is able to receive messages about changes in the database and the need to update certain information.

By default the server works in not authoritative mode That can be set up in the configuration file (is_authoritative parameter).

RFW is a daemon that executes the commands issued by the UTM 5+ core. RFW is intended for controlling the external software, including firewalls, routers, shapers, etc.

Workflow description:

On startup the RFW authorizes in the system using the parameters given in its configuration file. For successful authorization the RFW must be registered in the list of firewalls (see Admin interface: Firewall list). The amount of RFWs in the system is unlimited.

RFW establishes permanent connection with the core using the Stream protocol and awaits for commands issued by the core on some events. Commands for particular events are assigned in the administrator’s interface on Settings: Firewall rules.

The commands are executed either on the same server where RFW is running (if the firewall type is set to Local), either remotely over rsh, if it was set to Cisco (rsh).

If the RFW is not connected to the core, the commands are cached for 24 hours. On reconnection of RFW to the core some commands may be executed according to the given synchronization parameters (see ); if the reconnection was without any flags, all cached rules will be sent to the affector. Also, an arbitrary command may be assigned for execution on RFW startup by the firewall_flush_cmd parameter.