Table of Contents

Rating group, Tethering, Volume Quotas

SSG configuration

To apply the configuration, restart the service:
service fastdpi restart

Protocol grouping principle: DPI marks each new flow with a protocol from the list. The protocols are grouped into traffic classes for applying

Protocols are also grouped into Rating Groups with tethering taken into account. Tethering is determined based on the TTL value in outgoing traffic. The tethering_ttl_allowed = 128:64 parameter specifies the list of allowed TTL values for subscriber traffic that are not considered tethering. Values are separated by ':'. Up to 256 values (0-255) can be specified. This parameter is configured globally on the DPI. Per-subscriber profiling is planned in the roadmap. Rating Groups are used for volume quotas, policing by Rating Group, and performing the block and report actions.

Service 18 defines protocol grouping by traffic classes (cs) and Rating Groups (rg).

Service 20 defines policing, volume quotas, and actions for Rating Groups (rg).

Example of configuring traffic classes and Rating Groups using Service 18

  1. Prepare the example.txt text file:
        http cs0  teth1 rg1
        https cs0  teth1 rg1
        http cs0  teth2 rg2
        https cs0  teth2 rg2
    
        dns  cs1  teth1 rg1
        dns  cs1  teth2 rg2
    
        default cs7 teth0 rg3

    Parameter description:

    • teth0 — no tethering control (default)
    • teth1 — tethering control enabled: tethering detected
    • teth2 — tethering control enabled: no tethering detected

      rgN specifies the Rating Group number:
    • rg0 default (rg is not set)
    • rg1 sets rg=1
      ..
    • rg65535, maximum number of Rating Groups

      :!: In this example, tethering is monitored for the HTTP and HTTPS protocols, and the corresponding rg is assigned depending on the result. Note that the policing class (cs) is the same, but the rg differs depending on the TTL. The same applies to the DNS protocol. For ALL other protocols (default), tethering is not checked and a separate rg is assigned.
  2. Convert the file to the internal format:
    cat example.txt|lst2dscp /tmp/example.bin

    Reverse conversion for verification:

    dscp2lst /tmp/example.bin
  3. Create a Service 18 profile and assign it to the subscriber:
    fdpi_ctrl load profile --service 18  --profile.name test_dscp --profile.json '{ "dscp" : "/tmp/example.bin" }'
    fdpi_ctrl load --service 18  --profile.name test_dscp --login test_subs
  4. Verify the service assignment:
    fdpi_ctrl list --service 18 --login test_subs

The trace_ip trace now includes the rg=N field to determine the DPI behavior for a specific flow.

Example of configuring policing, volume quotas, and actions for Rating Groups (rg) using Service 20

  1. Prepare a text file in which TBF policing, a quota, and an action upon reaching the quota are specified for each Rating Group:
    rg1 tbf rate 1Mbit burst 1Mbit inbound.rate 8Mbit inbound.burst 1Mbit quota 100MB report
    rg2 tbf rate 8Mbit burst 1Mbit inbound.rate 8Mbit inbound.burst 1Mbit quota 1GB block

    :!: This example defines two Rating Groups. rg1 has an upload rate of 1 Mbps, a download rate of 8 Mbps, and a 100 MB quota with the report action when the quota is reached. rg2 has an upload rate of 1 Mbps, a download rate of 8 Mbps, and a 1 GB quota with the block action when the quota is reached.

    report and block are the available actions when the quota is reached:

    • report — report that the quota has been reached, but continue forwarding traffic;
    • block — report that the quota has been reached and block traffic for the corresponding Rating Group
  2. Convert the text file to binary format:
    cat rg.txt | lst2rg /var/lib/dpi/rg.bin

    Reverse conversion for verification:

    rg2lst rg.bin > rg.txt
  3. Create a Service 20 profile and assign it to the subscriber:
    fdpi_ctrl load profile --service 20 --profile.name rg1 --profile.json '{ "rg_list" : "/var/lib/dpi/rg.bin" }'
    fdpi_ctrl load --service 20  --profile.name rg1 --login test_subs