I’ve been mulling this one over as part of the fix to the PPPoE session drops - and have come up with this: assign a “static” IPv4 in whatever internal range you prefer to each customer account on your RADIUS DB, and hand it out in the Access-Accept. We currently use Framed-Pool but will move to Frame-IP-Address and Framed-IP-Netmask.
RADIUS is the only answer if you want to use overlapping pool on both BRAS - which is common if using public IPv4 due to IP availability.
You could potentially have scripts running to help manage this but it’d be messy and not fool proof so not great.
RADIUS can manage a pool though if you don’t want ‘static’ like above. A lot of RADIUS software can be told a pool and it will track what it has and hasn’t given out - and replies to the BRAS with Framed-IP-Address. You do have the possibility of overuse if a stop record is missed and it doesn’t re-enable that IP in the pool, but a daily/weekly cleanup script (checking for active session) or some kind of timeout baked in should cover that use case.
That approach is good if you don’t have high volumes of customers, or if you do, they have decent power grids and you don’t see PPPoE PADI floods etc. Our RADIUS server now is single-query per Access-Request, as efficient as it can get.
Whatever you do on the RADIUS server will reflect in the number of queries per PPPoE session being established, so, if you choose to have dynamic pools in DB, be prepared to handle large volumes of queries as the pool needs to be walked through to find a free IP. Then you can run into issues if you run multiple RADIUS instances or they run farming out to threads, where DB locks result in queries timing out and an ever-increasing load.
You can always of course just keep adding RADIUS and DB servers (and $$$!)
We designed a solution for HA BRAS that works well. You can actually split the pool in half across each BRAS and it will dynamically load balance users. Then redistribute the connected /32 routes into BGP.