CGNAT Per-Subscriber X-Ray · one command · full NAT picture · Symptom → Cause → Action

CGNAT Operations Brief · Per-Subscriber Health

A customer calls. One command tells you exactly what's happening in their NAT.

CGNAT troubleshooting usually means guessing: which public IP are they on? Is it port exhaustion? How many sessions? The answers are in the data plane — but assembling them takes digging through multiple tables. BNGSOFT's per-subscriber CGNAT X-Ray surfaces the complete NAT picture for any one subscriber in a single read-only command: bngxdpctl check sub <ip|ifname|username>. Public IP and pool, NAT type, port-block budget used, active sessions, per-subscriber alloc-fail and drop counters — and a Symptom → Cause → Action verdict. Support sees the full picture in seconds instead of minutes.

1 command

complete NAT picture

public IP, pool, NAT type, port budget, sessions, drop counters

Seconds

not minutes

look up by IP, interface name, or username — no table spelunking

Verdict

Excellent → Problem

Symptom → Cause → Action, per subscriber, from real data-plane counters

Read-only

safe any time

no config change, no session disruption — run during a live call

A subscriber complains about gaming lag, streaming failures, or "internet broken." The answer is in the CGNAT data plane. Now you can read it in one command, while the subscriber is still on the line.

What the command shows

Every field comes from live data-plane state — not cached, not estimated. The output is built for a first-line support agent who needs an answer fast, and for a senior engineer who needs the raw counters.

Sample output — bngxdpctl check sub 100.72.14.53

========= CGNAT Subscriber Health ========= subscriber : 100.72.14.53 (ppp143 / alice@isp.net) NAT assignment public IP : 49.238.60.114 pool 0 slot 3 NAT type : full-cone pool status: healthy Port-block budget blocks used: 3 / 8 (256 ports each) ports in use: 768 / 2048 block-limit hits: 0 Sessions active : 214 alloc fails: 0 drops: 0 Verdict EXCELLENT — NAT healthy, port budget well within limits No action required. ===========================================

A healthy subscriber. Port blocks 3 of 8 used (37%), zero alloc-fails, zero drops. The verdict says Excellent — support can close the ticket or look elsewhere for the complaint.

The same command — subscriber under port pressure

========= CGNAT Subscriber Health ========= subscriber : 100.72.18.201 (ppp809 / bob@isp.net) NAT assignment public IP : 49.238.60.114 pool 0 slot 3 NAT type : full-cone pool status: healthy Port-block budget blocks used: 7 / 8 (256 ports each) △ 88% — approaching limit ports in use: 1792 / 2048 block-limit hits: 12 in last 5 min Sessions active : 498 alloc fails: 8 drops: 3 Verdict DEGRADED — port budget >85%, allocation failures recorded symptom : some new connections may be refused or silently dropped cause : subscriber is consuming near the per-sub port-block ceiling action : consider raising per-sub block quota, or investigate session-leak (e.g. P2P client not closing connections) ===========================================

Port budget at 88%, 12 block-limit hits, 8 alloc-fails — the subscriber is hitting their port ceiling. The verdict names the cause and suggests the next move. No guessing required.

The four verdicts

EXCELLENT

All counters healthy, port budget comfortable, zero fails or drops

GOOD

Budget used, no active failures — normal for a heavy user

DEGRADED

Port budget >85% or isolated alloc-fails — monitor, may need action

PROBLEM

Active alloc-fails and/or drops, sessions refused — action required now

Every verdict below Excellent carries a Symptom, a Cause, and a suggested Action — not raw numbers for the operator to interpret.

What each field means

Field	What it tells you
Public IP + pool	Which shared address the subscriber is NATted behind, and which pool it belongs to — the first question support always asks
NAT type	Full-cone or symmetric — matters for gaming, VoIP, and peer-to-peer applications
Port blocks used	How many of the subscriber's allocated port blocks are in use, expressed as N/max — warns at >85%
Block-limit hits	How many times the subscriber tried to open a new port block and hit the ceiling — a non-zero value here is the symptom of port exhaustion

Field	What it tells you
Active sessions	How many live NAT flows this subscriber currently has open
Alloc fails	Port-mapping allocation failures — new connections that could not be NATted
Drops	Packets dropped due to NAT resource exhaustion for this subscriber
Pool status	Whether the pool IP this subscriber is assigned to is healthy, pressured, or degraded at the pool level

Why this matters in support

Without this command, a support agent answering "games are lagging" on a CGNAT network has to guess: Is it port exhaustion? Is it the public IP being blocked? Is the CGNAT even working? The guessing takes time and rarely produces the right answer on the first call.

Common complaint

"Games won't connect / lag spikes"

Check sub: NAT type is symmetric → explain the limitation, discuss static IP option
Or: block-limit hits > 0 → port exhaustion is the cause, clear answer

Common complaint

"Some websites give CAPTCHAs constantly"

Pool status shows pressured → may be a pool reputation issue, not this sub's fault
Alloc-fails zero → the subscriber's own NAT is healthy, investigate pool level

Common complaint

"Internet broken intermittently"

Drops > 0 + blocks at ceiling → port exhaustion, not the upstream or CPE
All counters zero → CGNAT is not the problem, look elsewhere

Read-only, safe any time. The command reads live data-plane state without modifying anything. Run it while the subscriber is still on the phone, during a live incident, or as part of a routine diagnostic sweep. No sessions are disrupted, no configuration is changed.

Lookup by IP, interface, or username

Support teams work in different ways — some look up by IP address, some by line interface name, some by username from the CRM. The command accepts all three:

# Any of these resolves to the same subscriber record: bngxdpctl check sub 100.72.14.53 # by private IP bngxdpctl check sub ppp143 # by interface name bngxdpctl check sub alice@isp.net # by username

First call resolution: the support agent uses whatever identifier the customer gives them — no translation step, no table join required.

Part of the broader Check-Engine

Per-subscriber CGNAT health is one component of the BNGSOFT Check-Engine — the whole-box diagnostic that runs correlated checks across license, RADIUS, upstream, data-path, CGNAT pool health, QoS, edge security, and NIC statistics in one pass. The check sub subcommand focuses the lens onto a single subscriber when a ticket is open.

Built on data already in the XDP data plane. bngxdpd tracks per-subscriber port-block allocation, session counts, alloc-fails, and drops natively as part of CGNAT operation. This command surfaces that data for operator visibility — there is no separate instrumentation layer, no additional overhead, and nothing new to configure.

From "I don't know" to "here's exactly what's happening" — in one command

CGNAT is opaque by design: subscribers share addresses, and the internal NAT state is not visible to the end user. The per-subscriber X-Ray makes it visible to the operator — instantly, precisely, and safely — so support teams can answer the question a subscriber is actually asking: what is happening to my connection?

It runs on the same XDP data plane that handles line-rate forwarding — no new services, no external appliances, no added latency. Safe to run any time. Ships as part of bngxdpd.

Want a demo? We'll run it live against a test subscriber, show the verdict flip from Excellent to Degraded, and walk through the support workflow.

Honest framing: This is an operations brief; no throughput or price figures are claimed. The bngxdpctl check sub command reads live per-subscriber CGNAT state from the bngxdpd data plane: public IP and pool assignment, NAT type (full-cone / symmetric), port-block usage (blocks used / max, with a >85% warning threshold), block-limit hit counter, active session count, per-subscriber alloc-fail counter, per-subscriber drop counter, and pool-level health status. The Excellent / Good / Degraded / Problem verdict and Symptom → Cause → Action text are generated from those live counters. The command is read-only and makes no changes to configuration or session state. Sample outputs shown are representative of the format; counter values are illustrative. Related briefs: Check-Engine, Self-Healing CGNAT, Abuser Auto-Isolation, CGNAT Arena Engine.