Skip to main content

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.

Built-in Deterministic CGNAT — Coming Soon

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:

  1. Creates a Linux VRF device: ip link add <vrf_name> type vrf table <vrf_table>
  2. Brings the VRF up: ip link set <vrf_name> up
  3. Moves the handoff interface into the VRF: ip link set <handoff_interface> master <vrf_name>
  4. Adds a policy routing rule: ip rule add fwmark <fwmark> table <vrf_table>
  5. Adds a default route in the VRF: ip route add default via <handoff_gateway> table <vrf_table>
  6. Loads nftables rules for packet marking in inet abng_cgnat table

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.

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

  1. Check nftables rules exist:

    sudo nft list table inet abng_cgnat
  2. Check subscriber has a CGNAT-range IP:

    abng> show subscribers
  3. Check abngd logs:

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

Routes Not Working

  1. Check VRF exists:

    ip vrf show
  2. Check routes in VRF:

    ip route show table 100
  3. Check policy rules:

    ip rule show | grep 0x64

Traffic Not Reaching CGNAT Appliance

  1. Check handoff interface is up and in VRF:

    ip link show eth3
  2. Check gateway is reachable from within the VRF:

    ip vrf exec cgnat ping 10.99.0.1
  3. 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:

  1. Remove the default route from the VRF table
  2. Remove the ip rule for fwmark steering
  3. Move the handoff interface out of the VRF
  4. Delete the VRF device
  5. Flush the inet abng_cgnat nftables table

Best Practices

  1. Dedicated interface — Use a dedicated physical or VLAN interface for the CGNAT handoff
  2. VRF isolation — Never mix CGNAT and public-IP subscriber traffic in the same routing table
  3. Unique fwmark — Choose a fwmark that doesn't conflict with other nftables or tc rules
  4. Monitor the appliance — Use the CGNAT appliance's logging/SNMP to track translation sessions and pool utilisation
  5. Plan for IPv6 — CGNAT is a bridge technology; deploy dual-stack where possible

Next Steps