BQN Documentation
Close icon

This section describes some examples of BQN usage.

Implementing Subscriber Rate Plans

The objective is to apply the speed limits in each subscriber’s data plan.

The BQN applies these limits betterthan a conventional shaping element because, for TCP traffic (the most common),it does not need to discard packets. Furthermore, it uses independent queues per flow and that makes application latencies independent of each other, which greatly improves the experience of interactive applications. The following picture shows the queue structure, with a queue per flow and policy control at flow and subscriber levels.

The easiest way to implement Rate Plans is to use the RADIUS Interface, REST API or Billing Systems (see thec orresponding sections). Rate policies will then be assigned by an external system to each subscriber. The external system can directly create those policies, or it can assign rate policies configured from the BQN GUI.

If an external system cannot be used,you can create one rate policy for each plan, an access profile with all the subscriber IP addresses (or ranges) assigned to that plan, and then a rule linking the corresponding access profiles and rate policies.

In the following example, we create three subscriber rate policies: rate-10Mbps, rate-20Mbps and rate-30Mbps:

We define access profiles with the IP ranges of the subscribers assigned to each policy:

And we link profiles and policies in a rule tree:

It is also possible to define such rules just for one test IP address that is used during a proof-of-concept to see the BQN performance as a bandwidth manager:

Limiting the Speed of Some Applications

The goal is to reduce the network peak throughput to mitigate the congestion at the peak hour. To that end, a DPI profile is defined (video in the example) to identify the applications to limit. This example makes use of video streaming predefined signatures. To include them, in Add DPI profile, select Add Predefined Signatures and choose the Video Streaming predefined signature.

Also, a throughput profile is createdwith the traffic load from which to start limiting (above-5Gbps in this example). Then, a subscriber flow policy (flow-10Mbps in the example) is created with a downlink limit (Downlink shaping per Subscriber) set at 10 Mbps. Finally, the DPI profile, the throughput profile and the subscriber flow policy are tied together in a subscriber flow rule.

Limiting the Speed of Some Applications with NAT

The goal is to reduce the network peak throughput to mitigate the congestion at the peak hour. In this scenario there is a NAT between the BQN server and the end subscribers and, therefore, a shaping per subscriber is not possible.

We will use the same Throughput and DPI profiles of the previous example, but we will use aper-flow shaping policy.

Services not limited by the Subscriber Rate

The goal is to preserve the quality of experience of some services by granting throughput to them even when the subscriber rate plan is fully used. An example could be a Voice over IP (VoIP) service hosted by the ISP. The policy is limited to subscribers with gold plans. It is created with an Internet profile (voip) with the IP address and port of the ISP-hosted VoIP service, a policy-rate profile and a flow policy (with Skip subscriber rate limitation selected to On). Next, the Internet profile and the policy-rate profiles are linked to the policy by a subscriber flow rule.

Blocking Applications

In this scenario, some application sneed blocking, for example, servers that are sources of attacks. To do this, an Internet profile is created (malicious-apps in the example) to identify the IP addresses to block. Next, a subscriber flow policy is defined with block action (with name flow-block in this example) and, finally, the Internet profile and the subscriber flow policy are combined in a subscriber flow rule.

Note: the Bequant product is designed to improve the quality of networks, not to block specific content, so its predefined DPI signatures are not guaranteed to match all flows for a specific content. Also, the flow blocking option may not be available in certain countries due to export restrictions.

Exclude Traffic from TCP Optimization

The objective is that the BQN will not optimize certain traffic. For example, some subscribers. To that end, an access profile is defined (subs-no-tcpo in the example), with the subscriber IPa ddresses to exclude.  Next, a subscriber flow policy is defined with optimization set to off (flow-no-tcpo in the example) and, then the access profile and the subscriber flow policy are combined in a subscriber flow rule.

This setup is equivalent to the IP address black list in BQN Release 3 software.

Another example would be to use an Internet profile to exclude some applications per TCP port.

Prioritize Teleconference Traffic

Needs BQN R4.25 or later.

To treat teleconference traffic with higher priority than the rest, you need to define a DPI and Internet profiles.  Zoom, Microsoft Teams and Google Meet are supported. The following image shows the rules:

The policy is defined with a priority higher than zero:

A sample configuration is available here, with the full list of IP addresses and ports of the teleconf-ip-ports profile and the list of DPI signatures of the teleconf-tcp profile. Save the file to your local machine using the browser Save As… option and apply it going to Administration->Backup->Load and selecting the Merge option.

Sample set of flow policy rules

Needs BQN R4.25 or later.

The following is an example of a complete set of rules that apply reasonable bandwidth management criteria, in particular:

  • Teleconference traffic is prioritized.
  • Software updates have lower priority and, duringpeak time, even less.
  • Speed tests are given full subscriber rate limit.
  • Video streaming is preventing from taking thefull rate limit.

Looking at the policies:

The policy flow-teleconf is set to 1 priority, higher than default (0) and even higher than flow-updates-offpeak (-1) and flow-updates-peak(-2). That means that teleconference traffic has the biggest priority and software updates have the lowest priority (even lower during peak traffic time periods).

Speedtest is limited to the full plan speed (100%), and itis allowed to reach that speed even when, combined with other traffic, exceeds the plan limit (Skip Rate “yes”).

The flow-video policy limits video streaming to 90% of the rate limit. The rationale is to leave some bandwith for other services. Also, the speed of a single flow is limited to 10 Mbps.

In addition to having lower priority, SW downloads are restricted to 90% of the rate plan and 80% during peak hours.

Feel free to adjust the speed limit percentages and relative priorities to your particular case.

A sample configuration is available here. Save the file to your local machine using the browser Save As… option and apply it going to Administration->Backup->Load and selecting the Merge option.

IPv4/IPv6 Dual Stack

Dual stack in this context is to subject the IPv4 and IPv6 traffic of the same subscriber to a shared rate limit.The BQN product supports IPv4/IPv6 dual stack in RADIUS and in several billing systems, but it is always possible to support dual stack using BQN REST API.  Dual stack is implemented creating one subscriber group per subscriber, with the IPv4 and IPv6 addresses as members, and the subscriber rate policy as the group policy.

For example, for a subscriber X with IPs 10.0.0.1 and 2001:abcd:ef00:1001::/64and rate policy "Plan-100Mbps":


curl -i -k -u myuser:mypw 
--request POST \
--urlhttps://some.bqn.net:3443/api/v1/subscriberGroups/DS-Customer-X \
--header 'accept: application/json' \
--header 'content-type: application/json' \
--data '
{ 
  "subscriberMembers": [ "10.0.0.1", "2001:abcd:ef00:1001::" ],
  "policyRate": "Plan-100Mbps"
}'

A subscriber group will be created with name “DS-Customer-X”. The rate policy "Plan-100Mbps" must have been created using the REST API or configured directly in BQN subscriber rate policies.

Note that, for IPv6 addresses, the subnet mask is implicit in the “subscriberMembers” list. This implicit prefix is configured in Administration->GeneralSettings and it is 64 by default.

If some subscribers have IPv6 subnets with a different prefix than the rest, it is supported. Use the “subscriberRanges” field:


curl -i -k -u myuser:mypw 
--request POST \
--urlhttps://some.bqn.net:3443/api/v1/subscriberGroups/DS-Customer-Y\
--header 'accept: application/json' \
--header 'content-type: application/json' \
--data '
{ 
  "subscriberMembers": [ "10.0.0.1"],
  "subscriberRanges": [ "2001:abcd:ef20::/48" ],
  "policyRate": "Plan-250Mbps"
}'

As with other REST API operations, you can modify the group with a PUT:


curl -i -k -u myuser:mypw 
--request PUT \
--urlhttps://some.bqn.net:3443/api/v1/subscriberGroups/DS-Customer-X \
--header 'accept: application/json' \
--header 'content-type: application/json' \
--data '
{ 
  "policyRate": "Plan-500Mbps"
}'

Captive portal

We discussed captive portals in the context of quota management. In this example, we will use that mechanism to implement generic captive portal redirections. By generic we mean that an external system will be able to enable or disable captive portal redirections per subscriber, using the BQN REST API.

First, we define rules to exclude captive portal traffic from the quota blocks and from subscriber group limits:

We configure the captive portal in the Quota options:

We need profiles to characterize two traffic types:

  • Captive portal traffic: we use DPI profile in the example, but if the IP address of the captive portal is known, an Internet profile can also be used.
  • DNS traffic to resolve the captive portal address: we use an Internet profile.

We associate those profiles with a policy not subject to quota blocking, so the captive portal traffic will go through:

We will use a subscriber group where we will place those subscribers with the captive portal enabled, for example captive-group.

Now, all we need to do to enable the captive portal is to place the subscriber in the captive group and set a quota of zero:


curl -i -k -u myuser:mypw --request PUT \
     --url https://some.bqn.net:3443/api/v1/subscribers/10.0.0.1 \
     --header 'accept: application/json' \
     --header 'content-type: application/json' \
     --data '
{
  "quota": {"volume": 0},
  "subscriberGroups": ["captive-group"]
}
'

Note that the assignment must be done based on the subscriber IP address (10.0.0.1 in this example).

To disable the captive portal in that subscriber, remove the quota and the membership to the group:


curl -i -k -u myuser:mypw --request PUT \
     --url https://some.bqn.net:3443/api/v1/subscribers/10.0.0.1 \
     --header 'accept: application/json' \
     --header 'content-type: application/json' \
     --data '
{
  "quota": {"volume": null},
  "subscriberGroups": []
}
'

Docs styling tags
[.p-highlight] Lorem ipsum... [.p-highlight]

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.

[.p-highlight-blue] Lorem ipsum... [.p-highlight-blue]

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.

[.p-highlight-red] Lorem ipsum... [.p-highlight-red]

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.

Preview for the single [.c-highlight]word mono-spaced[.c-highlight] styling.
Preview for the single word mono-spaced styling.
previous
NEXT