Recommended IP pool module + IPv6 + stickiness
Hi, I'm looking into centralising PPPoE IP address pool assignment/distribution and am setting up a test environment. Backend is SQL. I looked into sqlippool and sqlhpwippool, without managing to decide whether one is better than the other. Any suggestions? Just pick one and go with it? Then there's IPv6. As far as I can see the above modules don't support v6. This is not a major blocker as we could assign large enough pools to the NASes and let them handle v6 assignments. But still would be nice to have this centrally. Are there any modules supporting v6 yet? Lastly: Currently the NAS devices have a "semi-sticky" assignment policy. If a client disconnects and reconnects, they'll usually get the same IP. This is not configurable, so I don't know the internals (like timeout etc). Just wondering if it's straight-forward to mimic this in FR. Thanks in advance! -- Vegard Svanberg <vegard@svanberg.no> [*Takapa@IRC (EFnet)]
On Feb 3, 2021, at 5:00 AM, Vegard Svanberg <vegard@svanberg.no> wrote:
I'm looking into centralising PPPoE IP address pool assignment/distribution and am setting up a test environment.
Backend is SQL. I looked into sqlippool and sqlhpwippool, without managing to decide whether one is better than the other. Any suggestions? Just pick one and go with it?
Use sqlippool. The other one is not maintained, and has no default configuration or queries.
Then there's IPv6. As far as I can see the above modules don't support v6.
sqlippool supports IPv6. It's actually doesn't care about IP address types. It just does queries to allocate / find / release "things". So it works for RADIUS and DHCP, for both IPv4 and IPv6.
This is not a major blocker as we could assign large enough pools to the NASes and let them handle v6 assignments. But still would be nice to have this centrally. Are there any modules supporting v6 yet?
See above. This is being used in production. You just have to edit the queries to use IPv6 attributes instead of IPv4 ones. We should really have an example of this in the default config...
Lastly: Currently the NAS devices have a "semi-sticky" assignment policy. If a client disconnects and reconnects, they'll usually get the same IP. This is not configurable, so I don't know the internals (like timeout etc). Just wondering if it's straight-forward to mimic this in FR.
See raddb/mods-config/sql/ippool/*/queries.conf. This is the default. If you don't see comments about allocating "the address a client previously had", use 3.0.20, or grab v3.0.x from GitHub. We'll release the next version real soon now. Alan DeKok.
Alan DeKok <aland@deployingradius.com> writes:
Then there's IPv6. As far as I can see the above modules don't support v6.
sqlippool supports IPv6. It's actually doesn't care about IP address types. It just does queries to allocate / find / release "things". So it works for RADIUS and DHCP, for both IPv4 and IPv6.
But before you decide to use that feaure you should step back and ask yourself a couple of questions: Do I need global IPv6 addresses on the link? It's not required, so if you don't actually need it for anything then just don't bother allocating any. Should the prefix I assign to the customer's LAN (presumably by DHCPv6-PD) be dynamically allocated? People have different opinions here. There isn't a right or wrong answer. But the question should be asked, since the number of available addresses means that you *can* allocate a static prefix for every end user site. Personally I hate renumbering, and can't understand why I should force that on innocent users :-) Bjørn
* Bjørn Mork <bjorn@mork.no> [2021-02-03 14:30]:
Do I need global IPv6 addresses on the link? It's not required, so if you don't actually need it for anything then just don't bother allocating any.
That's a good question, which remains to be answered... ;-) Amongst other things, a few in-band management issues have to be resolved. Might need some sort of at least internally routable address on the external-facing interface for a while. Luckily with v6 comes the freedom of multiple approaches...
Should the prefix I assign to the customer's LAN (presumably by DHCPv6-PD) be dynamically allocated? People have different opinions here. There isn't a right or wrong answer. But the question should be asked, since the number of available addresses means that you *can* allocate a static prefix for every end user site.
Definitely. As v6 support is getting noticably better (bugs are squashed and different brands of equipment are starting to agree on how to speak to each other), I'm leaning towards making end-user prefixes as static as possible. Up until not too long ago, some of our equipment even refused to re-assign the same prefix ("error: already assigned"). One bug down... ;-)
Personally I hate renumbering, and can't understand why I should force that on innocent users :-)
I completely agree. -- Vegard Svanberg <vegard@svanberg.no> [*Takapa@IRC (EFnet)]
participants (3)
-
Alan DeKok -
Bjørn Mork -
Vegard Svanberg