VRF Steering
Virtual Routing and Forwarding for CGNAT traffic isolation and handoff.
Overview
VRF (Virtual Routing and Forwarding) allows AthenaBNG to maintain separate routing tables for different traffic classes. The primary use case is CGNAT steering — routing subscribers on RFC 6598 addresses through a dedicated VRF to an external CGNAT appliance for NAT translation.
A future release will include built-in nftables-based deterministic CGNAT. The VRF steering architecture described here will remain supported for operators who prefer a dedicated CGNAT appliance.
CGNAT VRF
What abngd Creates
When CGNAT is enabled, abngd performs these operations at startup:
- Creates a Linux VRF device:
ip link add <vrf_name> type vrf table <vrf_table> - Brings the VRF up:
ip link set <vrf_name> up - Moves the handoff interface into the VRF:
ip link set <handoff_interface> master <vrf_name> - Adds a policy routing rule:
ip rule add fwmark <fwmark> table <vrf_table> - Adds a default route in the VRF:
ip route add default via <handoff_gateway> table <vrf_table> - Loads nftables rules for packet marking in
inet abng_cgnattable
All of this is done via netlink (not shelling out to ip).
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"
Traffic Flow
Subscriber (100.64.x.x — RFC 6598 address from RADIUS)
↓
nftables marks packet with fwmark (0x64)
↓
ip rule matches fwmark → lookup table 100
↓
VRF table 100: default via 10.99.0.1 dev eth3
↓
CGNAT appliance translates source IP → public IP
↓
Upstream / Internet
Subscribers with public IPs are not marked and route normally via the default table.
Recommended CGNAT Appliance
We recommend NFware vCGNAT for the external CGNAT appliance. It provides deterministic NAT mapping, DPDK acceleration, full translation logging for lawful intercept compliance, and runs on commodity x86 hardware.
Any router or appliance that accepts routed traffic on the handoff interface will work (e.g. Linux nftables on a dedicated server, Juniper MX, A10 Thunder CGN).
Verification
View VRF Status
ip vrf show
# Name Table
# cgnat 100
View VRF Routes
ip route show table 100
# default via 10.99.0.1 dev eth3
Check Policy Rules
ip rule show
# 32765: from all fwmark 0x64 lookup 100
Check nftables Packet Marking
sudo nft list table inet abng_cgnat
Check Handoff Interface
ip link show eth3
# eth3: ... master cgnat state UP ...
Troubleshooting
Packets Not Being Steered
-
Check nftables rules exist:
sudo nft list table inet abng_cgnat -
Check subscriber has a CGNAT-range IP:
abng> show subscribers -
Check abngd logs:
sudo journalctl -u abngd -f | grep -i cgnat
Routes Not Working
-
Check VRF exists:
ip vrf show -
Check routes in VRF:
ip route show table 100 -
Check policy rules:
ip rule show | grep 0x64
Traffic Not Reaching CGNAT Appliance
-
Check handoff interface is up and in VRF:
ip link show eth3 -
Check gateway is reachable from within the VRF:
ip vrf exec cgnat ping 10.99.0.1 -
Verify the CGNAT appliance has return routes for the
source_range
Teardown
When CGNAT is disabled or abngd shuts down, the VRF plumbing is cleaned up in reverse order:
- Remove the default route from the VRF table
- Remove the
ip rulefor fwmark steering - Move the handoff interface out of the VRF
- Delete the VRF device
- Flush the
inet abng_cgnatnftables table
Best Practices
- Dedicated interface — Use a dedicated physical or VLAN interface for the CGNAT handoff
- VRF isolation — Never mix CGNAT and public-IP subscriber traffic in the same routing table
- Unique fwmark — Choose a fwmark that doesn't conflict with other nftables or tc rules
- Monitor the appliance — Use the CGNAT appliance's logging/SNMP to track translation sessions and pool utilisation
- Plan for IPv6 — CGNAT is a bridge technology; deploy dual-stack where possible
Next Steps
- CGNAT Feature Overview — High-level CGNAT architecture
- CGNAT Configuration — Full parameter reference
- Custom Overhead Profiles — Overhead tuning