Skip to main content

CGNAT & VRF Steering

VRF-based traffic steering to an external CGNAT appliance.

Overview

AthenaBNG provides CGNAT VRF steering — automatically classifying subscribers on RFC 6598 (Shared Address Space) IPs and routing their traffic through a dedicated Linux VRF to an external CGNAT appliance for NAT translation. This clean separation lets the BNG focus on subscriber management while a purpose-built appliance handles high-performance NAT.

Built-in Deterministic CGNAT — Coming Soon

A future release will include built-in nftables-based deterministic CGNAT with per-subscriber public IP and port range allocation. The VRF steering architecture described here will remain supported.

How It Works

Traffic Flow

Subscriber (100.64.x.x — RFC 6598)

BNG checks subscriber IP against source_range
├─ If in CGNAT range:
│ ├─ nftables marks packet with fwmark
│ ├─ ip rule steers into CGNAT VRF routing table
│ └─ VRF default route sends to CGNAT appliance
└─ If public IP:
└─ Route normally via default table

VRF Steering

AthenaBNG manages the full CGNAT VRF lifecycle:

  1. VRF creation — Creates a Linux VRF device and routing table
  2. Interface binding — Moves the handoff interface into the VRF
  3. Policy routing — Adds ip rule add fwmark <mark> table <N>
  4. Default route — Installs a default route in the VRF via the CGNAT gateway
  5. Packet marking — nftables marks subscriber traffic for VRF steering
  6. Subscriber classification — Sessions with IPs in source_range are flagged for CGNAT

We recommend NFware vCGNAT as the external NAT translation appliance:

  • Deterministic NAT — Predictable public IP + port mapping for lawful intercept compliance
  • High performance — Millions of concurrent NAT sessions with DPDK acceleration
  • Logging — Full translation logging for regulatory compliance
  • ALG support — SIP, FTP, and other Application Layer Gateways
  • REST API — Programmatic pool and mapping management

NFware vCGNAT runs on commodity x86 hardware — deploy on a second server or as a VM.

Any CGNAT appliance that accepts routed traffic on a handoff interface will work (e.g. Linux nftables on a dedicated server, Juniper MX with MS-MPC, A10 Thunder CGN).

Configuration

cgnat:
enabled: true
vrf_name: "cgnat"
vrf_table: 100
handoff_interface: "eth3"
handoff_gateway: "10.99.0.1"
source_range: "100.64.0.0/10"
fwmark: "0x64"

See CGNAT Configuration for full parameter reference.

RFC 6598 Shared Address Space

The default CGNAT source range (100.64.0.0/10) is defined in RFC 6598:

  • Range: 100.64.0.0 to 100.127.255.255
  • Purpose: Carrier-Grade NAT (CGN) address space
  • Size: 4,194,304 addresses
  • Usage: RADIUS assigns addresses from this range to subscribers requiring CGNAT

Monitoring

View CGNAT Configuration

abng> show configuration | match cgnat

Check VRF Status

ip vrf show
ip route show table 100

Check nftables Rules

sudo nft list table inet abng_cgnat

Check abngd Logs

sudo journalctl -u abngd -f | grep -i cgnat

Troubleshooting

Traffic Not Reaching CGNAT Appliance

  1. Check CGNAT is enabled: show configuration | match cgnat
  2. Check VRF exists: ip vrf show
  3. Check handoff interface is up and in VRF: ip link show eth3
  4. Check route exists in VRF table: ip route show table 100
  5. Check gateway is reachable: ip vrf exec cgnat ping 10.99.0.1
  6. Check nftables rules: sudo nft list table inet abng_cgnat

Return Traffic Not Working

  1. Check CGNAT appliance is translating return traffic
  2. Check reverse routes on the CGNAT appliance point back to the BNG
  3. Check the CGNAT appliance has routes for the subscriber source_range

Best Practices

  1. Dedicated interface — Use a dedicated interface for the CGNAT handoff link
  2. VRF isolation — Keep CGNAT traffic fully separated from public-IP subscriber traffic
  3. Unique fwmark — Avoid conflicts with other nftables rules
  4. Monitor translations — Use the CGNAT appliance's logging/monitoring to track NAT sessions
  5. Plan for IPv6 — CGNAT is a bridge technology; deploy dual-stack where possible

Next Steps