Framed-IP pools
Framed-IP address pools live in the pool object view, keyed by name. A new pool is created live on commit and an existing pool can be grown live, but any other reshape waits for a restart so no active allocation is orphaned.
Commands
The pool view is object-keyed: a new name creates the pool, an existing name edits it. next chains a successor pool so a full pool overflows into another rather than refusing connections; none clears it. Removing an in-use pool retires it and lets it drain rather than dropping subscribers.
pool <name> range <start> <end> gateway <gw> [prefix <len>] pool <name> next <successor-pool> # or: none pool <name> undo next pool <name> remove # in-use pools retire, then drain pool default range 100.64.10.10 100.64.10.250 \ gateway 100.64.10.1 prefix 24 pool default next overflow-pool commit show pool # used/size
Live-grow semantics
Re-issuing range on an existing pool with the same start and gateway and a larger end is a pure grow: the extra addresses become allocatable immediately on commit, with no restart and no disturbance to bound subscribers, because existing allocations are bitmap indices below the old size. Any other range change — a smaller end, a moved start or a changed gateway — still applies on restart, since a live reshape would orphan active allocations. Growing a full pool under active load is safe: lifting a 10240/10240 pool to 10240/20480 while sessions keep dialling in is exactly the case this exists for.
Overlap caution
When two pools' ranges overlap — a wide default enclosing a named pool's start, for instance — an address is owned by whichever pool actually allocated it. The daemon frees it back to the owning pool, not to the first range match. Avoid deliberately overlapping ranges. If show pool reports used standing above the live session count while the box is idle, that is the signal to investigate.