Define reusable per-device download and upload limits, attach them safely, and verify Linux traffic control.

A bandwidth profile contains only technical rate limits. It does not select a network, DHCP pool, package duration, or price. A service class references the profile, and a business package references the service class.

Bandwidth profile → Service class → Business package → Authorized account → Edge enforcement

1. Create a profile

Open Bandwidth, then choose New bandwidth profile.

Bandwidth profiles are reusable technical limits. Enter rates in decimal kilobits per second.

Complete these fields:

Field	Meaning
Name	Operator-facing purpose, such as `Guest 10 Mbps`
Download (kbps)	Maximum traffic delivered from the edge to one authorized device
Upload (kbps)	Maximum traffic sent by that device toward the edge/WAN
Status	`active` makes the profile selectable for new service-class policy; `disabled` retains existing references safely
Tenant	The policy owner; profile and service class must belong to the same tenant

Rates are decimal kilobits per second:

Desired rate	Enter
2 Mbps	`2000` kbps
5 Mbps	`5000` kbps
50 Mbps	`50000` kbps

Leave one direction blank to keep that direction unlimited. At least one direction must have a limit.

2. Attach it through a service class

Profiles do nothing by themselves. Open Service Classes, create or edit a class, and select the bandwidth profile. Then select that service class from a package in the Business Portal. Existing active accounts keep their snapshotted effective class until their entitlement is changed or activated again.

3. Enable edge enforcement

Open the agent and enable Bandwidth control. NOC automatically keeps Firewall on, because firewall sets identify the authorized IPs belonging to each service class.

At the edge, URUFI installs:

per-device HTB shaping on the client interface for download;
an IFB path for upload shaping;
rate-derived burst and cburst values;
fq_codel below the rate class for fair queueing and latency control.

This state is applied as part of the network transaction. A failed traffic-control apply does not become the new last-known-good revision.

4. Verify the real rate

Use a sustained client transfer or iperf3, not only a short browser gauge. On the edge, identify the active client interface (ufv100 for VLAN 100, or the native LAN interface) and its IFB, then inspect both directions:

sudo tc -j -details class show dev ufv100 | python3 -m json.tool
sudo tc -s class show dev ufv100
sudo tc -s qdisc show dev ufv100
sudo tc -s qdisc show

For 5000 kbps, tc -j reports approximately 625000 bytes per second because the kernel JSON uses bytes/second. Multiply by eight to compare with bits/second.

Speed-test websites can under-report shaped links because of test duration, parallel connections, latency, browser behavior, or the remote server. Kernel counters under a sustained transfer are the authority for whether the configured edge cap is working.

A cap is a ceiling, not a guarantee

A 5 Mbps profile prevents a device from exceeding roughly 5 Mbps. It cannot create 5 Mbps when the WAN, test server, Wi-Fi link, CPU, or VM path delivers less.

Common problems

Symptom	Check
No HTB qdisc on the client interface	Bandwidth control enabled, service class assigned, account authorized, and network converged
`shaper_qdisc_conflict`	Another manager owns the root qdisc; remove that external policy or choose one owner
Correct download, no upload class	IFB support and the URUFI-created `uifb...` device
Rate changes do not affect an active user	The account may still carry the previous effective service-class snapshot
Browser result is lower than the class rate	Compare sustained kernel counters or `iperf3` before changing the profile

Next step

Compose the bandwidth profile and firewall scope into a service class.

Create bandwidth profiles