Skip to content

Dynamic address pools#

A dynamic address pool lets your AAA server hand out an address by naming a pool instead of supplying the address itself. The appliance allocates from the pool, returns the address when the session ends, and tries to give a reconnecting subscriber the address it had before.

Pool families#

Family What a subscriber gets RADIUS attribute naming the pool
ipv4 an IPv4 address Framed-Pool (88)
ipv6-wan its own IPv6 /64 for the access link; the WAN address is prefix::1 Framed-IPv6-Pool (100)
ipv6-pd a delegated IPv6 prefix of the pool's delegation length Delegated-IPv6-Prefix-Pool (171)

Each family is independent, and a static address from AAA always wins over a pool for its family — so a subscriber can have a static IPv6 prefix and a dynamic IPv4 address, or be IPv6-only.

Locally-defined subscribers name pools with ipv4-pool, ipv6-wan-pool and ipv6-pd-pool, or inherit subscribers default-pools.

Running several appliances with the same pool#

Configure the same pool name on every appliance, and give each appliance its own subnets. Your RADIUS profile only ever carries the name, so it does not need to know which appliance a subscriber will land on.

# lns1
set address-pool res-v4 family ipv4
set address-pool res-v4 vrf internet
set address-pool res-v4 announce 100.70.0.0/22

# lns2
set address-pool res-v4 family ipv4
set address-pool res-v4 vrf internet
set address-pool res-v4 announce 100.70.4.0/22

Appliances do not coordinate. If two appliances announce overlapping subnets, return traffic is split between them — the Address Pools page in the web UI warns when it sees that across your fleet.

Announcing into BGP#

A subnet with announce set is originated into BGP as one aggregate in the pool's VRF. The per-subscriber routes inside any pool subnet are never advertised, whether the subnet is announced or not — so BGP carries one prefix per subnet, not one per subscriber. A subnet without announce is not advertised at all; route it to the appliance some other way.

Pools and CGN#

Bind a VRF to on-box CGN with set routing vrf <vrf> cgn-ip-group <group> (or set cgn default-vrf-ip-group <group> for the default table). Every subscriber whose IPv4 lands in that VRF is translated. The VRF's IPv4 pools are then private: they cannot be announced, and you can configure the same private subnets on every appliance, because translation happens locally. IPv6 pools in the same VRF are not translated and follow their own announce setting.

VRFs#

A pool belongs to one VRF. When AAA names no VRF, the subscriber goes into the pool's VRF. When AAA names a different VRF, or a subscriber's pools are in different VRFs, the subscriber is rejected.

When a pool runs out#

The family whose pool is empty is left out and the subscriber comes up on the others; a subscriber left with no address at all is rejected. The address-pool.exhausted alarm is raised straight away, and address-pool.high warns at 90% utilisation.

Changing pools on a live appliance#

Pool changes take effect on commit. Adding subnets or exclusions keeps every existing allocation. Removing a subnet disconnects the subscribers holding addresses in it — check show address-pools <name> before you commit, and consider commit confirmed.

Accounting#

Accounting Start, Interim and Stop records carry the subscriber's IPv4 address, IPv6 WAN address, WAN /64 and delegated prefix, and name the pools they came from (Framed-Pool, Framed-IPv6-Pool, Delegated-IPv6-Prefix-Pool over RADIUS). When a dual-stack IPoE subscriber's second address family comes up after the Start, an Interim-Update is sent immediately.

Seeing what is allocated#

  • show address-pools and show address-pools <name> in the CLI
  • BNG → Address Pools in the web UI
  • GET /api/v1/address-pools and GET /api/v1/address-pools/{name}/allocations
  • bngAddressPoolTable in NETAVO-BNG-MIB

All figures are the appliance's own share of each pool.