Subscriber Edge on Commodity Servers
Broadband Gateway · CGNAT · QoS · Protection
Broadband Gateway · CGNAT · QoS · Protection
Compliance · Abuse Response · Subscriber Disputes
"Who Was Behind That Address?" — Answer With a Name
A request arrives. It contains a public IP address, a port and a timestamp, and it expects an answer within a deadline. If hundreds of your subscribers share that address — as they must, once you run out of public ones — then the address alone identifies nobody. Our flow records solve this by carrying the subscriber's account name inside the record itself, so the answer is a lookup rather than an investigation.
Address sharing is not optional any more. But the obligation to say which customer did something at a given second did not go away when the addresses ran out — it just got much harder to meet.
Account
name
name
carried in every record,
not just an IP address
not just an IP address
160 million+
records produced by a single
node, with no export errors
node, with no export errors
Months
in continuous production
service, not a roadmap item
service, not a roadmap item
Standard
format
format
feeds the collector you
already own
already own
Most flow-export systems were designed when one customer had one public address, and answering "who was this" meant looking up an address in your provisioning system. That assumption is dead. Under address sharing, a public address and a timestamp narrow the field to a few hundred households — which is not an answer you can give a regulator, a court, or a customer accusing you of getting it wrong. What is needed is a record that already knows whose traffic it was at the moment it was written.
1 · Why an address is no longer an answer
WITHOUT SUBSCRIBER IDENTITY
A shortlist, not an answer
Hundreds of
households
households
all sharing the one public address
- You receive an address, a port and a time — and can only say that it was one of a large group.
- Narrowing it down means correlating several systems by hand, under deadline, hoping the clocks agreed.
- Records may not go back far enough, or may have rolled over before the request arrived.
- Every answer carries a risk of naming the wrong customer — which is its own serious problem.
WITH SUBSCRIBER IDENTITY
The record already says who
One account
named in the record at the time it was written
- The subscriber's account name is written into the record as it is created — not reconstructed afterwards.
- The shared public address and port are recorded alongside the customer's own address, in the same record.
- Start and end times are on the record, so a timestamped request maps directly onto it.
- Answering becomes a query against your collector, not a forensic exercise across three systems.
The correlation problem, stated plainly. Everything needed to answer the question exists somewhere in most networks — the address assignment is in one system, the translation is in another, the account is in a third. The difficulty is never that the data is absent; it is that joining three systems by timestamp, under a legal deadline, is slow and easy to get wrong. Putting the identity into the record removes the join entirely.
2 · What each record carries
Every exported record describes one conversation and carries the context needed to attribute it — the customer, the addresses on both sides of the translation, and when it happened.
Subscriber account nameThe identity they authenticated with — the same one on the bill
The address you gave themTheir own address inside your network
The shared public address and portWhat the rest of the internet saw instead
Their equipment identityHardware address of the device that connected
Where they connectedThe access port and network segment they arrived on
Who they were talking toRemote address, port and protocol
When it started and endedSo a timestamped request lands on the right record
How much passedVolume in each direction, for dispute and capacity work
What that looks like when you query it ILLUSTRATIVE LAYOUT
| Subscriber account | Their address | Seen publicly as | Talking to | Started | Ended |
|---|---|---|---|---|---|
| a.mensah@example-isp.net | 100.64.18.204 | 203.0.113.44:41022 | 198.51.100.9:443 | 14:22:07 | 14:24:51 |
| l.novak@example-isp.net | 100.64.22.11 | 203.0.113.44:41023 | 192.0.2.77:443 | 14:22:09 | 14:23:02 |
| r.silva@example-isp.net | 100.64.31.90 | 203.0.113.44:41024 | 198.51.100.140:993 | 14:22:14 | 14:41:38 |
Illustrative only — account names and addresses above are fictional and use ranges reserved for documentation. Note that all three subscribers share the same public address and are separated only by port and time. That is precisely the situation the account-name column exists to resolve. Exact presentation depends on the collector you use.
3 · The three questions this is actually for
1 · LAWFUL REQUEST
A deadline you cannot miss.
- An authority provides an address, a port and a time, and expects a subscriber identified within a fixed period.
- The record names the account directly, so the response is prepared from one query.
- Less risk of an incorrect identification, and a defensible account of how the answer was reached.
2 · ABUSE COMPLAINT
Someone else's network complaining about yours.
- A third party reports scanning, spam or attack traffic from one of your public addresses.
- You can identify the specific customer instead of contacting everyone behind that address.
- Faster containment protects the reputation of the whole address pool — and everyone sharing it.
3 · CUSTOMER DISPUTE
"That wasn't me."
- A subscriber challenges a usage charge, a policy action or a suspension.
- Records tied to their account settle it with evidence rather than assertion.
- Equally, they let you find quickly that the customer was right — which is worth just as much.
The commercial case is the boring one. Nobody buys a subscriber edge for its record-keeping. But a compliance obligation you cannot meet is a licence problem, an abuse complaint you cannot action gets your address ranges blocklisted, and a dispute you cannot evidence is a refund. These are unglamorous costs that recur — and they are avoided by a capability you either have on day one or spend a project retrofitting.
4 · In production, not on a roadmap
This is the point at which most feature pages become aspirational. So, specifically: this is deployed and running on operator networks today, and has been for months.
CONTINUOUS SERVICE
Months, not demos.
- One production node has been exporting continuously for more than two months without interruption.
- The longest-running deployment has been in service for close to six months.
- Deployed across several operator networks.
VOLUME AND RELIABILITY
Over 160 million records.
- A single node has produced more than 160 million records in that period.
- Zero export errors and no gaps in the record sequence.
- Verified as actively producing new records at the time of writing, not a stalled counter.
YOUR EXISTING TOOLS
A standard format.
- Records are exported in the industry-standard flow format your collector already understands.
- Ships to your own collector, on your own infrastructure, under your own retention policy.
- Nothing leaves your network, and there is no vendor cloud in the path.
5 · What the common alternatives give you
Subscriber-identified flow export is unusual, and worth checking carefully in any competing proposal. The gap is generally not that a vendor exports nothing — it is that what they export does not say who, or requires additional hardware to say it.
| Approach | What you get | What it costs you when a request arrives |
|---|---|---|
| BNGSOFT | The subscriber's account name inside the record, together with both sides of the translation. | A query. |
| Flow export without subscriber identity | Addresses and ports, but no account. Some platforms do not support flow export on subscriber traffic at all. | Manual correlation across several systems, against the clock. |
| Identity available, but on separate hardware | Attribution is possible, but only via an additional service card or appliance. | Extra hardware to buy, power, license and keep in step. |
| Translation logging only | A log of address translations, without the account or the conversation context. | Answers which address, still not which customer, and can be very large. |
How to test any vendor's answer, including ours. Ask for one exported record, printed. Then ask which field on it names the customer. If the answer involves joining it to another system, or fitting an extra card, that is the cost you will pay on every request for the life of the contract — and it is far easier to find out now than during your first real deadline.
6 · Scope — what to confirm before you rely on it
We would rather set this out plainly than have it surface during a compliance audit.
ENABLED PER DEPLOYMENT
It is switched on deliberately.
- Record export is configured as part of a deployment; it is not silently on everywhere by default.
- That is intentional — it produces personal data, and it should be a decision you make, with a retention policy attached.
- Confirm during design review that it is included in your build.
CHECK THE FIT TO YOUR DESIGN
Not every configuration is covered.
- Attribution covers the address-translation design it is deployed with; it is not a blanket claim across every possible configuration in the product family.
- Where a node uses a different translation design, tell us during design review and we will confirm coverage before you commit.
- Ask us for the specific answer for your topology, not a general one.
Handling personal data responsibly. These records identify individual subscribers by name, and should be treated as personal data: stored on your own infrastructure, access-controlled, retained for a defined period consistent with your obligations, and no longer. Nothing is exported outside your network by the product, and the retention decision is yours alone.
7 · What it is worth
Subscriber attribution · operator value
Meet the deadline you are held toLawful requests get a precise, defensible answer inside the required period, without an emergency engineering effort each time.
Name the right customerThe identity is captured when the traffic happens, which materially reduces the chance of misidentifying a subscriber — the error with the highest consequences.
Protect your address reputationAbuse traced to one customer in minutes rather than days keeps the shared address pool — and everyone else on it — off blocklists.
Settle disputes with evidenceUsage and policy challenges are resolved from records rather than negotiated, and you can confirm quickly when the customer is right.
No additional hardwareAttribution comes from the same server that gates your subscribers, not a separate card or appliance to purchase and maintain alongside it.
Your data, your infrastructureRecords go to a collector you own and control, in a standard format, under your retention policy. No vendor cloud in the path.
The bottom line
Once your subscribers share public addresses, an address and a timestamp stop being an answer. Our records carry the subscriber's account name alongside both sides of the translation and the times it happened — so a lawful request, an abuse complaint or a billing dispute is resolved by a query, not an investigation.
It is running on operator networks now, has produced more than 160 million records from a single node without a single export error, and feeds the collector you already own — with no extra hardware and nothing leaving your network.
About these figures. The production figures in section 4 were taken on the day of publication from operator networks running this capability. The volume figure — more than 160 million records with no export errors and no gaps in the record sequence — comes from a single production node that had at that point been exporting continuously for more than two months; the export was confirmed to be actively producing new records at the time of checking, by sampling the record count twice and observing it advance. The longest-running deployment observed had been in continuous service for close to six months. The capability is deployed on several operator nodes; it is enabled as part of a deployment rather than being active by default everywhere, and both the collector it exports to and the retention applied to the records are the operator's own. The record contents described in section 2 reflect the fields the export actually carries. The table in section 2 is marked ILLUSTRATIVE LAYOUT: the account names and addresses shown are fictional and use address ranges reserved by standards bodies for documentation purposes; no real subscriber data appears anywhere in this document, and none was reproduced in preparing it. Presentation of records depends on the collector used. Section 5 describes categories of alternative approach rather than any named product; where a specific competing platform is being evaluated, ask us for the sourced comparison, which cites vendor documentation directly. Coverage of a particular address-translation design should be confirmed for your topology during design review — see section 6. Records produced by this capability identify individual subscribers and constitute personal data; retention periods and access controls are the operator's responsibility under the applicable regime.