Load-Balancer / Bonded-Account Detection

A common way ISPs lose revenue on speed-tiered plans is account bonding: a customer buys two, three, or more separate accounts and aggregates them behind a single load-balancing router (typically MikroTik PCC) to get the combined bandwidth of all of them for the price of the cheapest tier. Load-Balancer Detection identifies these clusters so you can act on them.

The design principle is precision over recall: it only groups accounts when the evidence is a physical fact about the same device, not a soft behavioural correlation. On dense city networks, behavioural signals (shared destinations, correlated traffic) produce far too many false positives — neighbours naturally share local IPTV/gaming servers and follow the same daily rhythm. So those signals are recorded as evidence only, never as grounds to group on their own.

How to get here

• Sidebar → Reports → Load-Balancer Detection.
• Requires the bonded.view permission.

What it groups on (physically provable)

Two signals are trustworthy enough to group accounts into a suspected bond, because they describe the same physical hardware:

Signal	Why it’s reliable
Same router MAC	Two “different customers” whose sessions originate from the exact same router MAC address are the same device. Hard to fake accidentally.
Consecutive port MACs	CPEs on one load-balancer often carry sequential MACs (…:01, …:02, …:03). Consecutive MACs indicate ports of one device — distinct from the spread-out MACs of unrelated CPEs deployed in a batch.

When accounts share one of these, they’re merged into a bonded group and surfaced for review.

What it records as evidence only (never groups on)

These signals appear on a group as supporting context, but do not by themselves create a group. They are off by default:

• Shared destination IPs / correlated traffic patterns
• Same GPS coordinates or same switch
• Synchronised session timing
• Accounts spread across different resellers

You can opt into using some of these for review, but be aware they generate noise on dense networks.

Caution

Resist the temptation to “tune thresholds” on the behavioural signals to catch more. No threshold separates a real premises bond from city-mates who share a local server and peak-hour rhythm — which is exactly why grouping is anchored on MAC facts, not correlations. Raising sensitivity trades a handful of real hits for a flood of false accusations.

Reading the results

Each detected group lists its member accounts, the signal(s) that bonded them (same-MAC or consecutive-MAC), and any evidence annotations. From there you can investigate and decide on action — typically contacting the customer or consolidating them onto a single appropriate plan.

Group membership is stable across scans because it’s driven by hardware facts, not shifting correlations, so a real bond keeps the same identity scan after scan rather than churning.

Limits and the honest upgrade path

MAC-based detection catches bonds where the load-balancer or CPEs expose a shared or sequential MAC to your BNG. It cannot see a bond hidden behind NAT that presents unrelated MACs.

The genuinely stronger signal is network-emitted circuit identity — DHCP Option 82 / RADIUS NAS-Port-Id from the access layer — which ties a session to a physical port and cannot be spoofed by the customer. Where your access network populates that, it beats any behavioural heuristic. Detection based on smarter behaviour analysis is a dead end by comparison.

Related

• Sharing Detection — the complementary feature for the opposite problem: one account shared across many devices in one household.