Managing NAT Bindings per Subscriber
Understand how RADIUS-integrated CGNAT bindings work — linking NAT sessions to subscribers, supporting IPv6, logging subscriber attributes, cleaning up bindings on Accounting-Stop, and filtering sessions by subscriber ID and type.
When you run carrier-grade NAT (CGNAT) with persistent NAT and/or address pooling paired (APP), you can enable subscriber-aware binding management to correlate NAT bindings and sessions with a subscriber identity. The system learns the subscriber identity from RADIUS accounting and, when needed, from observed traffic. The system maintains per-logical-system subscriber entries keyed by subscriber ID and subscriber IPv4 or IPv6 address. It links subscriber entries to persistent NAT bindings and APP mappings and performs deterministic cleanup when subscriber life cycle events occur. For example, the system clears associated sessions and bindings when it receives a RADIUS Accounting STOP. If a STOP message is missing, the system ages out subscriber state based on inactivity timers.
You control how subscribers are identified by configuring an ordered subscriber key list (subscriber-key-list) that can include standard and vendor-specific RADIUS attributes. In dual-stack deployments, the system can correlate subscriber context across IPv4 and IPv6, including handling of Framed-IPv6-Address. To protect resources, you can enforce a global per-subscriber session limit (max-sessions-per-subscriber) that drops excess sessions and tracks the drops. For operations and audit, you can view subscriber status by logical system, filter NAT tables by subscriber ID, and export logs that include subscriber details. You can also control RADIUS attribute verbosity (basic, all, extensive, or custom) and detect when log output is truncated.
Benefits
-
Reduces stale NAT state by clearing a subscriber’s associated sessions and bindings when the system receives a RADIUS Accounting STOP, instead of relying only on NAT timeouts.
-
Improves troubleshooting by letting you trace NAT bindings and session behavior to a specific subscriber identity when multiple users share public addresses.
-
Provides predictable cleanup when accounting messages are incomplete by aging out subscriber-linked NAT state using inactivity timers.
-
Extends subscriber correlation to dual-stack deployments by maintaining subscriber context for both IPv4 and IPv6.
-
Limits per-subscriber resource consumption by enforcing a per-subscriber session cap and tracking drops.
How subscriber correlation works
Subscriber-aware binding management correlates CGNAT state with a subscriber record and uses subscriber life cycle signals to drive cleanup and operational visibility. For each logical system, the system creates a subscriber entry keyed by subscriber ID and the subscriber IPv4 or IPv6 address. RADIUS accounting typically supplies the identity. If traffic arrives before accounting, the system can create a minimal subscriber entry based on what it can infer from traffic. As persistent NAT bindings or APP paired-address mappings are created, the system links those NAT objects to the matching subscriber entry. This linkage lets you query NAT state by subscriber identity instead of only by internal address or public mapping.
Subscriber correlation depends on how you define the subscriber ID. You configure an ordered subscriber key list on the RADIUS profile so the system selects the first attribute present in the accounting message. For example, you can prefer one attribute and then fall back to another when the preferred attribute is not present. In dual-stack deployments, when RADIUS includes both Framed-IP-Address and Framed-IPv6-Address, the system creates separate subscriber entries for IPv4 and IPv6 that share the same subscriber ID. This behavior supports consistent correlation across address families.
Cleanup behavior
Subscriber events can trigger NAT cleanup actions. When the system receives a RADIUS Accounting STOP for a subscriber, it clears NAT bindings referenced by that subscriber, closes associated sessions, and deletes the subscriber entry. When STOP is missing, the system relies on inactivity handling. After sessions and related NAT objects are cleared, the subscriber entry transitions toward inactive and ages out when the subscriber inactivity timer expires. New traffic refreshes the subscriber entry and returns it to an active state.
To protect resources, you can enforce a global per-subscriber session cap. After a subscriber reaches the configured maximum, the system drops new sessions for that subscriber and increments drop counters.
Configuration and operational workflows
Configure the RADIUS profile used by subscriber services to control subscriber identification and logging behavior:
-
Define ordered subscriber keys (up to five) to select the subscriber ID, including vendor-specific attributes when required:
set security subscriber radius-profile <profile-name> subscriber-key-list <attr1> <attr2> ... -
Control which RADIUS attributes the system parses and emits in subscriber-related logs. For custom, specify up to 20 attributes:
set security subscriber radius-profile <profile-name> subscriber-attributes category basic|all|extensive|custom -
Export subscriber logs by enabling the subscriber category on a security log profile:
set security log profile <profile-name> category subscriber -
Enforce a per-subscriber session cap to limit resource consumption and drop excess sessions:
set security subscriber max-sessions-per-subscriber <value>
Use operational commands for verification and troubleshooting:
-
Check subscriber services state and capacity per logical system:
show security subscriber status(scope withroot-logical-system,logical-system <name>, orall-logical-systems-tenants). -
Confirm the active subscriber key list and attribute category, and identify conditions such as log truncation when verbose attributes exceed the maximum message size:
show security subscriber radius-profile <profile-name> -
Filter NAT operational output by subscriber identity to retrieve only bindings or APP mappings linked to that subscriber:
show security nat source persistent-nat-table subscriber type <subscriber-type> id <subscriber-id>andshow security nat source paired-address subscriber type <subscriber-type> id <subscriber-id> -
Inspect subscriber-to-NAT linkage, remaining age-out time, session counts, and deletion-cause counters using Packet Forwarding Engine (PFE) execution commands:
request execute pfe show usp subsandrequest execute pfe show usp subs stats