====== Configuration ======
{{indexmenu_n>2}}

Policing has two connection options:
   - Individual profile: connects without specifying a profile, an individual profile is created for each subscriber.
   - Named profile: connects with the profile name.
<note important>For BRAS, named profiles must be used **name specified in the Radius-Accept attributes.**</note>

===== Individual Profile =====

An individual configuration file is used to define each bandwidth control policy. This file specifies bandwidth limits for protocol classes (groups). The method is similar to [[dpi:dpi_options:opt_shaping:shaping_settings|overall bandwidth control]]).

[[dpi:dpi_components:platform:subscriber_management|fdpi_ctrl]] utility applies the configured policies to subscribers.

The format of the instruction:
<code>
fdpi_ctrl command --policing policing_description_file [IP_list]
</code>
Instructions' syntax and IP addresses specification methods are described in details here: [[dpi:dpi_components:platform:subscriber_management:subsman_cmd|Control instructions]].

<note tip>Note the use of [[dpi:dpi_components:platform:subscriber_management:subsman_profiles|named policing profiles]]\\
The tariff plan can be set in [[dpi:dpi_options:opt_bandwidth_mgmt:bandwidth_json|JSON format]] as well.</note>

==== Example 1: torrent limiting ====

<note tip>For advanced users: We recommend that you read [[dpi:dpi_options:opt_bandwidth_mgmt:bandwidth_conf|"Outgoing traffic management via feedback"]].</note>

We intend to offer our subscribers the plan for 10 Mb/s with torrent bandwidth limit of 3 Mb/s.

To accomplish the goal we create a class for torrents as described in [[dpi:dpi_options:opt_priority:priority_config|Configuring priorities]]. 
<code>
bittorrent   cs1         
default      cs0
</code>
We're splitting the traffic into 2 classes for this example:

  * cs0 - corresponds to DSCP=0 QOS(IPP)=0 Best Effort
  * cs1 - corresponds to DSCP=8 QOS(IPP)=1 Priority

We're creating the configuration file rateplan_1.cfg. It specifies bandwidth limits for each of 8 protocol classes (groups). We use HTB (the method of borrowing available bandwidth) and specify the bandwidth limit for torrents 3 Mb, but not smaller than 1 Mb. Unlike torrents, other traffic may take the whole available bandwidth.

<code bash>
htb_inbound_root=rate 10mbit 
htb_inbound_class0=rate 8bit ceil 10mbit
htb_inbound_class1=rate 1mbit ceil 3mbit 
htb_inbound_class2=rate 8bit ceil 10mbit
htb_inbound_class3=rate 8bit ceil 10mbit
htb_inbound_class4=rate 8bit ceil 10mbit
htb_inbound_class5=rate 8bit ceil 10mbit
htb_inbound_class6=rate 8bit ceil 10mbit
htb_inbound_class7=rate 8bit ceil 10mbit
htb_root=rate 10mbit 
htb_class0=rate 8bit ceil 10mbit
htb_class1=rate 1mbit ceil 3mbit 
htb_class2=rate 8bit ceil 10mbit
htb_class3=rate 8bit ceil 10mbit
htb_class4=rate 8bit ceil 10mbit
htb_class5=rate 8bit ceil 10mbit
htb_class6=rate 8bit ceil 10mbit
htb_class7=rate 8bit ceil 10mbit
</code>

  * htp_inbound_root, htb_root are the root classes that define the overall bandwidth for inbound and outbound traffic. The bandwidth is distributed within these classes.
  * rate - is the minimal bandwidth
  * ceil - is the maximum bandwidth that can be borrowed from the root class if available
  * class2-7 would not be used as we configure two classes only: 0 and 1.

Here we assign the configured policy to subscribers that use this plan:
<code>
fdpi_ctrl load --policing rateplan_1.cfg --file subscribers_with_rateplan_1.txt
</code>

==== Example 2: maximum speed for peering====

Bandwidth allocation for several classes (for example containing peer-to-peer traffic) can be deduced from the HTB (Hierarchical Token Bucket) hierarchy. It can be done by specifying the keyword **static** in the description. In this case, the restriction for this class will be applied independently regardless to htb_root.
For example under the conditions noted above, we separately limit the class 6 to 100 Mbps.
<code bash>
htb_inbound_root=rate 10mbit 
htb_inbound_class0=rate 8bit ceil 10mbit
htb_inbound_class1=rate 1mbit ceil 3mbit 
htb_inbound_class2=rate 8bit ceil 10mbit
htb_inbound_class3=rate 8bit ceil 10mbit
htb_inbound_class4=rate 8bit ceil 10mbit
htb_inbound_class5=rate 8bit ceil 10mbit
htb_inbound_class6=rate 100mbit static
htb_inbound_class7=rate 8bit ceil 10mbit
htb_root=rate 10mbit 
htb_class0=rate 8bit ceil 10mbit
htb_class1=rate 1mbit ceil 3mbit 
htb_class2=rate 8bit ceil 10mbit
htb_class3=rate 8bit ceil 10mbit
htb_class4=rate 8bit ceil 10mbit
htb_class5=rate 8bit ceil 10mbit
htb_class6=rate 100mbit static
htb_class7=rate 8bit ceil 10mbit
</code>

==== Example 3: assigning policing for multisubscribers ====

Let's assign the plan from the previous example to a subscriber with several IPs.

Check that database support is enabled in DPI **///etc/dpi/fastdpi.conf//**:
<code>
udr=1
</code>
If it is not enabled: we enable it and restart DPI: service fastdpi restart

Reserve for corporative subscriber all his IPs:
<code>
fdpi_ctrl load --bind_multi --user OOO_PizzaJohnes:192.168.0.1-192.168.0.5,192.168.1.10-192.168.1.25
</code>
The subscriber's IP list can be modified [[dpi:dpi_components:platform:subscriber_management:dpi_ipmulti|dynamically]] (i.e. add new IPs and delete it).

Let's assign the bandwidth limits according to the plan:
<code>
fdpi_ctrl load --policing rateplan_1.cfg --login PizzaJohnes_LLC
</code>

<note tip>Setting the schedule for tariff plans: {{youtube>IQa_3T0jJ38?}}</note>