How to Use a Public /24 for Your ISP with ISPbills Built-in IPAM

A public /24 is an address plan, not a list of 256 customers

A public IPv4 /24 gives an ISP 256 addresses to organize. How many customers it can serve depends on the delivery model: directly assigned public addresses, routed customer subnets, shared NAT, infrastructure use, and the space kept for growth. Handing out addresses sequentially without a plan makes later expansion and troubleshooting unnecessarily difficult.

ISPbills includes an IP address management workflow through IPv4 Pools, PPP profiles, and customer allocation. It helps keep subscriber pools consistent and exposes capacity pressure. It does not replace upstream routing, configure a complete CGNAT platform merely by creating a pool, or turn an unallocated prefix into public address space.

1. Confirm ownership, routing, and the service model

Before creating a pool, confirm who provides the /24 and how traffic will reach you. Your upstream might route the block statically to your router, or you might originate it through an agreed BGP arrangement. Record the authorized origin, next hop, filtering requirements, reverse-DNS arrangements, and the contact responsible for routing changes. Where applicable, maintain the registry, IRR, and RPKI authorization needed for your actual announcement.

Internal subnetting and external advertisement are different decisions. You can divide a /24 internally without advertising every smaller subnet to the internet. Many networks filter IPv4 advertisements more specific than /24; confirm your upstream’s policy rather than expecting a public /27 announcement to propagate. A /24 announcement is not guaranteed reachability either: authorization, routing policy, and return paths still matter.

Decide which customers need dedicated public IPv4, which can use a shared-address service, and which need a routed block. Keep the customer-facing service description honest: a subscriber behind CGNAT does not have an independently reachable public address. Plan IPv6 alongside IPv4 instead of treating address conservation as a permanent substitute for dual stack.

2. Understand the address arithmetic

A /24 contains 2^(32 - 24) = 256 addresses. In a conventional broadcast subnet, one is the network address and one is the broadcast address, leaving 254 host addresses. If one host address is reserved as the gateway, 253 remain before additional infrastructure reservations.

The current ISPbills IPv4 Pool creation workflow reserves the network address, the first host as the gateway, and the broadcast address. Consequently, a fresh /24 pool offers 253 subscriber allocation slots. The dashboard represents this as 254 usable addresses, with the gateway already counted as one allocated address. These figures describe different things and are not a discrepancy.

These are pool-specific numbers, not a universal rule for every topology. Routed /32 subscribers, loopbacks, NAT egress addresses, and RFC 3021 point-to-point /31 links have different addressing semantics. ISPbills’ current IPv4 Pool form rejects masks longer than /30, so do not try to model a /31 or /32 link as a normal subscriber pool.

3. Divide the /24 by purpose before assigning customers

The following is an illustrative allocation plan, not a recommendation that every ISP use these exact proportions. It covers the whole /24 without gaps or overlaps and separates two subscriber pools from operational address space.

The block sizes add up to 128 + 64 + 32 + 16 + 16 = 256. The two subscriber pools provide 125 + 61 = 186 initial customer slots, not 192. The other 64 addresses have planned non-subscriber purposes. Public infrastructure should include only services that genuinely need public addresses; private management or a protected management VPN is often more appropriate for device administration.

A single large pool is simpler and avoids repeated subnet overhead. Smaller pools give clearer service boundaries but consume more reserved addresses and can strand capacity in the wrong pool. Choose the layout using demand, routing, and failure-domain requirements rather than splitting the block just to make a neat table.

4. Create the subscriber pools in built-in IPAM

Open Routers & Packages > IPv4 Pools with a Group Admin account or a NOC account granted the relevant IP-pool permissions. Select New IPv4 pool.

1. Name the first pool. Use a clear operational name such as Public_PPPoE_A. Where the router uses a named pool, keep the naming consistent with that configuration.
2. Enter the aligned subnet. In this documentation example the value is 203.0.113.0/25. In production, enter the equivalent block from your assigned prefix.
3. Review validation and save. The workflow checks for duplicate pool names, an invalid network boundary, and overlap with another pool in the ISP workspace.
4. Create the second subscriber pool. Use Public_PPPoE_B with the equivalent of 203.0.113.128/26.
5. Check the resulting inventory. Verify subnet, gateway, broadcast, available capacity, and the PPP profiles attached to each pool.

Do not place DNS servers, router management addresses, NAT public addresses, or growth reserves inside an automatically allocated customer pool unless their exclusion is explicitly enforced by the applicable allocation design. A label in a spreadsheet does not stop an allocator from selecting an address. The straightforward approach in this example is to keep those blocks outside the subscriber pools entirely.

5. Connect the pool to PPPoE service delivery

Creating an inventory record is not enough. In the relevant PPP profile, select the intended IPv4 Pool and review IPv4 Allocation Mode. Then confirm that the customer’s package and master-package/profile relationship lead to that profile.

In static allocation mode, the platform can keep an address associated with the customer and use the corresponding RADIUS Framed-IP-Address during the applicable PPPoE workflow. When Router authentication is configured, the supported synchronization path also updates the router-side subscriber configuration. Router authentication and RADIUS authentication are different operational paths; confirm which one your installation uses.

For an active customer in dynamic allocation mode, ISPbills removes the fixed framed-IP assignment so allocation can follow the configured dynamic path. Do not sell that configuration as a guaranteed fixed address. Also do not treat the IPAM allocation counter as a live count of every router-issued dynamic lease: reconcile dynamic utilization with the router and active sessions.

Before onboarding a batch, activate a controlled test subscription and check the actual PPP session address, the expected customer record, outbound connectivity, return routing, and the public source address seen by an external test endpoint. If the service promises dedicated public IPv4, confirm that an unintended source-NAT rule is not translating it behind another address. Apply only the inbound access policy the customer service requires; public addressing is not permission to expose all ports.

6. Watch capacity before the pool is exhausted

The IPv4 Pools dashboard shows available capacity and allocation, surfaces critical pools first, and supports searching by name, subnet, gateway, or broadcast. Capacity filters distinguish Available below 70%, Near capacity at 70-89%, and Critical at 90% or above. PPP-profile dependencies help identify which services a pool change could affect.

For example, 90 subscriber assignments in the /25 pool use 91 of its 126 dashboard-usable addresses when the gateway is included: approximately 72%. That leaves 35 subscriber slots and places the pool in the near-capacity range. Start planning at that point rather than waiting for the last free address.

Review each pool separately. Forty free addresses in one service pool do not help a different exhausted pool unless you deliberately change its allocation design. Check current customer records and sessions before reclaiming an address. Do not delete or replace a pool simply because a filtered list looks empty.

7. Use shared addressing deliberately when demand exceeds public capacity

If most customers only need outbound connectivity, a properly engineered CGNAT service can share some public addresses among many subscribers. RFC 6598 reserves 100.64.0.0/10 as shared address space for service-provider use. It is not publicly routed subscriber address space and is distinct from RFC 1918 private addressing.

CGNAT requires separate NAT configuration, routing, port-capacity planning, session limits, monitoring, and operationally appropriate mapping logs. Subscriber identification can require the public IP, source port, protocol, and timestamp together. Shared public reputation, port exhaustion, inbound-service restrictions, gaming behavior, and customer VPN compatibility also need consideration. A public /24 does not translate into a fixed guaranteed number of CGNAT subscribers.

ISPbills pool management helps organize the subscriber-side address assignment. It does not, by itself, install the complete CGNAT policy or provide every translation log required by your jurisdiction. Offer dedicated public addressing where needed and expand IPv6 so IPv4 sharing remains an explicit service design, not an invisible workaround.

8. Change a live address plan through a maintenance process

Changing a pool subnet is not just renaming a row. The ISPbills subnet-replacement workflow requires confirmation and queues customer address reallocation. It can affect subscriber addresses and connectivity. Back up the relevant configuration, record customer-to-address mappings, review profile dependencies, prepare routing and NAT changes, and arrange a maintenance window before proceeding.

Prefer a staged transition where feasible: prepare a new non-overlapping pool, validate the service path with a test customer, move the intended service population through the supported workflow, and verify actual sessions. A failed readdressing is not safely reversed by blindly deleting a pool. Restore the approved routing, profile, and allocation plan and confirm customer connectivity before closing the change.

Frequently asked questions

Start with one verified pool: use the Routers and Service Delivery guide, review MikroTik integration, and explore the ISPbills demo. Connect the address plan to DDoS protected scope separately, with particular care around shared NAT and essential services.

Sources and scope: current ISPbills IPv4 pool, PPP profile, and allocation workflows; RFC 4632 on CIDR; RFC 5737 on documentation addresses; RFC 6598 on shared address space; and RFC 3021 on point-to-point /31 links. This AI-assisted planning article uses illustrative addresses, not a tested configuration for a particular live network.