Planning tools
Size it before you buy it.
Put in your subscriber count and busy-hour traffic. These calculators return the worker cores, memory, NIC ports, public addresses and conntrack budget the deployment needs — using the same figures our deployment engineers size from.
Your deployment
PPPoE + IPoE sessions established at the same time at the busy hour — not the number of customers you bill. On a residential network roughly 60–80% of customers are online at peak, so 12,000 customers is about 10,000 sessions. Read it from show sessions on a box you already run, or from your RADIUS accounting at the busiest hour. This figure sets the QoS pipe budget, the conntrack table and the licence count; it does not set worker cores — throughput does.
The busy-hour peak on your upstream (NNI) link in Gbps, taken from your monitoring graphs — not the sum of sold plans, which is always many times larger. Count the larger direction (usually download); the worker that carries a flow handles both directions. Add the growth you expect over the life of the box. This is the number that sets worker cores: one worker forwards about 2 Gbps with NAT on, 2.3 Gbps without.
Only PMDs with working RSS in DPDK are listed — RSS is what spreads subscriber traffic across workers, so a NIC without it cannot scale past one core.
PPPoE hides the IP header from the NIC, so upstream needs software fan-out.
Concurrent connections (conntrack entries) one subscriber holds at peak, not sessions. A home with phones, a TV and a laptop sits around 50–150; an office, a CCTV DVR or a heavy P2P user can hold 500 or more. Live figure: show nat block lists ct-refs per subscriber on a running box. Subscribers × flows is rounded up to the next 100,000 and becomes conntrack-capacity, 64 bytes per entry inside the hugepage arena. The daemon accepts 65,536 to 8,388,608.
A card occupies one PCIe slot, so it belongs to one CPU. Forwarding can only spread across sockets if you have a card in each — one 4-port card is still a single-socket NIC.
Hardware you already have (optional)
PHYSICAL cores per socket, not SMT threads. On Linux run lscpu and read Socket(s) and Core(s) per socket; if you only have a thread count, halve it. Leave both at 0 to size a new box from scratch. When filled in, the verdict below compares your box against the requirement per socket, because only the socket that holds a data NIC can run forwarding workers.
Enabled features
Recommended platform
- Closest profile
- Medium ISP
- CPU class
- Single socket, clock-optimized
- Cores — required
- 11 total
- Cores — you have
- —
- Verdict
- —
- Cores per socket
- 8 worker + 3 non-worker
- SMT threads to isolate
- 16
- System RAM
- 64 GB recommended
- Hugepages (NIC node)
- 8 GB, 1 GB pages
- Conntrack arena
- —
- QoS pipe budget
- —
- Upstream fan-out
- —
- NIC
- Intel X520-DA2 or X710-DA2
- NUMA layout
- Single node
Addressing
What: the private prefix your PPPoE/IPoE subscribers get their framed IP from — the same range as the pool line in pool.conf. Use RFC 6598 shared space (100.64.0.0/10), never a public range and never a range you also use on your LAN.
Format: CIDR only, e.g. 100.64.0.0/21. This prefix becomes the nat-rule line, so every subscriber inside it is translated through the pool below.
How many subscribers: the BNG hands out every host address in the range, .0 and .255 included; only the network address, the broadcast address and the pool gateway (the first host) are kept back. So /24 = 253, /22 = 1,021, /21 = 2,045, /20 = 4,093, /19 = 8,189.
Watch out: a Framed-IP-Address from RADIUS that lies outside this prefix is not matched by the rule and is routed without NAT.
What: the public IPv4 addresses you own that subscribers will appear from on the internet. They must reach this BNG: either on the WAN subnet (the BNG proxy-ARPs for every pool address) or statically routed to it by your upstream.
Format: a range 203.0.113.1-203.0.113.126, a CIDR 203.0.113.0/25, or one address. The nat.conf line is always written as two full addresses, which is what the daemon parses.
Which addresses: a range lets you skip the .0 and .255 of a routed /24, which some upstream routers and filters treat specially. The daemon itself accepts them. Do not include an address that is also a snat ... to target or a WAN interface IP.
Capacity: public IPs × subscribers per IP (port range ÷ block). The result panel says how many of these addresses the inside range actually needs.
Port blocks
What: the fixed window of outside ports one subscriber owns for the whole session. Every flow from that subscriber picks a port inside the window; when the window is full, new flows are dropped and counted as nat-alloc-fail in show nat statistics.
Rule: your choice — any whole number from 1 up to the port span, as on Juniper, Nokia and Huawei. It does not have to be a power of two. The only requirement is that it fits the range at least once; the daemon rejects a block larger than the span.
Choosing: smaller blocks pack more subscribers per public IP; larger blocks survive port-hungry devices. A live residential box shows about 150 ports per subscriber on average with the busiest near 800, so 1024 is a safe residential choice and 2048 is generous. Offices, CCTV recorders and heavy P2P users want 2048–4096. Pick a size that divides your span exactly to waste nothing: 20000–59999 with block 2500 is 16 subscribers per IP and 4,096 on a /24. The trade-off table in the results shows common sizes plus yours.
What: the span of outside ports on each public IP that blocks are carved from. Subscribers per IP = span ÷ block size, rounded down.
Start: 1024 or higher. Ports below 1024 are the well-known service ports and are treated specially by servers and middleboxes.
End: make the span an exact multiple of the block, otherwise the remainder on every IP is stranded — a block is never split. Formula: end = start + (blocks × block size) − 1. Examples at block 2048: 1024–64511 gives 31 blocks and wastes nothing; 27000–61815 gives 17; 1024–65535 gives 31 but strands 1,024 ports per IP.
Note: the daemon does not check that the end is above the start or that one block fits; a bad range is accepted and simply carves nothing. This page warns instead.
What: concurrent connections one subscriber holds at peak — conntrack entries, not sessions and not ports. Each TCP connection, UDP mapping or ICMP echo is one entry. A home is typically 50–150; an office, CCTV DVR or P2P user can hold 500 or more. On a running box, show nat block lists ct-refs per subscriber.
Result: subscribers × flows, rounded up to the next 100,000, becomes conntrack-max at 64 bytes per entry. The daemon accepts 65,536 to 8,388,608; above that the page caps the value and warns. Closed flows are released by the idle timeouts in nat.conf, so a generous figure here costs only hugepage memory.
What: the last word on the nat.conf pool line. Keep deterministic.
Today: the daemon accepts and stores the keyword but nothing reads it. Every subscriber gets one fixed block at session-up and one block compliance record is written then, in both modes; per-flow records are a separate switch, ipdr flow enable. dynamic is reserved for a future per-flow-only mode.
Address plan
- Inside range
- —
- Inside addresses
- —
- Outside range
- —
- Outside addresses
- —
- Public IPs needed
- —
- Ports per subscriber
- —
- Stranded ports
- —
- Conntrack
- —
Block size trade-off
| Block | Subs per IP | Capacity | IPs needed | Fits pool |
|---|
Capacity is what your outside range would carry at that block size. Your current selection is highlighted.
Want this checked against your network?
Send the numbers you put in above along with your access mix and traffic profile. We come back with a validated hardware profile and a written quote.