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.
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:
- VRF creation — Creates a Linux VRF device and routing table
- Interface binding — Moves the handoff interface into the VRF
- Policy routing — Adds
ip rule add fwmark <mark> table <N> - Default route — Installs a default route in the VRF via the CGNAT gateway
- Packet marking — nftables marks subscriber traffic for VRF steering
- Subscriber classification — Sessions with IPs in
source_rangeare flagged for CGNAT
Recommended CGNAT Appliance
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
- Check CGNAT is enabled:
show configuration | match cgnat - Check VRF exists:
ip vrf show - Check handoff interface is up and in VRF:
ip link show eth3 - Check route exists in VRF table:
ip route show table 100 - Check gateway is reachable:
ip vrf exec cgnat ping 10.99.0.1 - Check nftables rules:
sudo nft list table inet abng_cgnat
Return Traffic Not Working
- Check CGNAT appliance is translating return traffic
- Check reverse routes on the CGNAT appliance point back to the BNG
- Check the CGNAT appliance has routes for the subscriber
source_range
Best Practices
- Dedicated interface — Use a dedicated interface for the CGNAT handoff link
- VRF isolation — Keep CGNAT traffic fully separated from public-IP subscriber traffic
- Unique fwmark — Avoid conflicts with other nftables rules
- Monitor translations — Use the CGNAT appliance's logging/monitoring to track NAT sessions
- Plan for IPv6 — CGNAT is a bridge technology; deploy dual-stack where possible
Next Steps
- Routing — BGP and OSPF integration
- RADIUS AAA — RADIUS integration
- VRF Steering (Advanced) — Detailed VRF operations