BQN Docs

Introduction to Policies

To manage in a flexible way the product many features, the BQN uses policies. Policies define the actions to perform on the traffic (e.g., traffic optimization, rate limitation, generation of metrics, etc.), along with the action parameters (e.g., a speed limit).

There are three kinds of policies:

• Flow policies, to act on IP flows (for example, a TCP connection or a UDP flow).
• Rate policies, associated with subscriber sessions.
• Monitoring policies, also associated with subscriber sessions.

A subscriber session is defined as all the traffic from the same IPv4 address on the access side, or, in the case of IPv6, from the same /64 subnet. See What is a BQN Subscriber for more details.

Every flow is assigned a flow policy. Every subscriber is assigned a rate policy and a monitoring policy. Because a subscriber has many flows, the flows may be assigned to different flow policies.

Through flow policies we control the following functionalities:

• TCP Optimization (TCPO).
• Shaping per subscriber: limit to the combined speeds of all the flows assigned to the flow policy, for that subscriber. For example, if the limit is 12 Mbps, four flows of the same subscriber can have 3 Mbps each.
• Shaping per flow: speed limit of a flow assigned to the flow policy. For example, a limit of 5 Mbps prevent any flow under that policy to exceed those 5 Mbps.
• Total blocking of the traffic under this policy.
• Blocking only incoming connections from Internet of specific traffic types.
• Quota counting: decide this traffic volume counts when checking the volume quota.
• Quota limitation: what to do when the quota is reached, whether traffic is blocked or slow down to some specified speed.
• Flow relative priority.

Through rate policies, we control the following functionalities:

• Limit the total network speed of a subscriber.
• ACM optimization.
• Limit of concurrent flows per subscriber.

Through monitoring policies, we control the following functionalities:

• The amount of sampling when collecting DPI information for a subscriber (whether automatic or base on some explicit sampling percentage).

Policies are defined as part of the BQN configuration, along with rules and profiles that decide what policy to apply depending on the traffic characteristics.

Additionally, rate policies can managed from an externals ystem, creating them dynamically and assigning them to the subscribers. The BQN supports many APIs to integrate with external systems:

• RADIUS
• BQN REST
• Integrations with many billing vendors.

The rate policies from an external system always take precedence over those rate policies configured in the BQN, that are used as a fallback (i.e. for those subscribers without a policy assignment from the external system).

‍

What is a BQN Subscriber

‍

For the BQN product, a subscriber session is all traffic of a distinctive IP address on the access side: one single IPv4 address or one IPv6 subnet. For example, a policy with rate limits will apply those limits to the total throughput of that distinctive IP address.

If there is a NAT between the BQN server and the real subscribers, subscribers whose IP addresses are translated to the same IP address would be considered as the same subscriber.

The default IPv6 subnet is /64 (to change it, go to Administration->General Settings and edit the field IPv6 prefix for subscribers).

A new subscriber session is identified when the first packet from an access IP address is received. This is when the subscriber rate and monitoring rules are evaluated, to choose which policies to apply.

‍

Check a Subscriber Status

You can check the rate policies applied to a subscriber in Status->Subscribers->Subscriber Attributes. It lists the subscribers, with the applied policy in RATE-POLICY column.

The ASSIGNED-BY column, indicates the origin of the policy: BQN configuration, radius, BQN rest API or billing system.

The list of groups this subscriber belongs to are listed in SUBSCRIBER-GROUPS.

If the subscriber has a quota, QUOTA column will show enabled, which is also a link to the quota status page.

Clicking on the subscriber IP address or Subscriber ID leads to the Subscriber dashboard (see Network Visibility, Subscriber Dashboad for more information).

At the top of the page, there are fields to filter the subscribers by policy, source of the policy assignment or IP address.

You can dig in the active flows of a subscriber in Status->Flows->Details, which shows the policy applied to each flow in FLOW-POLICY column,  along with other information:

Status->Subscribers->Subscriber Attributes contains the information that were in Status->Radius/REST/Billing->Subscribers in previous versions.

‍

Check a Policy

Given a policy, it is possible to see how many subscriber IP addresses are under each policy going to Status->Policies.

To check flow policies, go to Status->Policies->Flow Policies:

A click on a policy name leads to the policy definition and a click on the FLOWS counter shows a list of flows associated to that policy.

To check rate policies, go to Status->Policies->Rate Policies:

SUBS-PROVISIONED says how many subscribers are associated to that policy. SUBS-ACTIVE shows how many of them are active (they are running traffic). If the policy definition is configured in the BQN locally, CONFIGURED is “yes”. For policies created dynamically via API (RADIUS, REST, Billing) it will show “no”. BLOCK “no” means that the policy does not block traffic and "yes" the opposite. The table also shows the policy rate limits in downlink and uplink directions and whether it has the ACM active or not.

A click on a policy name leads to the policy definition and a click on the SUBS-ACTIVE counter shows a list of subscribers associated to that policy.

To check rate policies, go to Status->Policies->Monitoring Policies:

A click on a policy name leads to the policy definition anda click on the ACTIVE-SUBSCRIBERS counter shows a list of subscribers associated to that policy.

‍

Status->Policies->Rate Policies combines the information that were in Status->Radius/REST/Billing->Policies and Status->Policies in previous versions.

Status->Policies->Flow Policies and Status->Policies->Monitoring Policies contain the information that were in Status->Policies in previous versions.

‍

Disable policy speed limits

During testing or for any other reason, it is possible to disable speed limit enforcement globally in the node, regardless of the limits specified by the policies.

Go to Configuration->Optimization Settings. The three speed limit types are the following:

• Individual flow shaping (per flow): limits the speed of one single traffic flow. The limits are defined in flow policies (downlink and uplink shaping per flow).
• Aggregated flow shaping (per subscriber): limits the combined speed of all traffic flows of the same subscriber meeting the policy. The limits are defined in flow policies (downlink and uplink shaping per subscriber).
• Subscriber rate limiting: limits the combined speed of all traffic of the subscriber. The limits are defined in rate policies (maximum subscriber downlink/uplink speeds).
• Subscriber group rate limiting: limits the combined speed of all traffic of all subscribers in the group. The limits are defined in rate policies (maximum subscriber downlink/uplink speeds).

‍

<div class="paragraph-highlight red">Please, bear in mind that while enforcement of speed limits are disabled, speeds may go and will most likely go above those limit. For example, if subscriber rate limit is disabled, subscriber plans will not be enforced.</div>

‍

Subscriber Group policies

‍

In addition to policies per flow and subscriber, it is possible to define policies per subscriber group. Some examples follow:

• A subscriber group is defined with allsubscribers in the same access point and then a policy associated. The overall traffic of those subscribers will not exceed the access point capacity, mitigating the congestion.
• A subscriber group is defined for every pair of IPv4 and IPv6 addresses of the same subscriber, with a rate limit equal to that subscriber plan. This is the way to implement dual stack in the BQN product.

More details can be found in Subscriber GroupRate Limiting.