Recommended IP pool module + IPv6 + stickiness

classic Classic list List threaded Threaded
5 messages Options
| Threaded
Open this post in threaded view
|

Recommended IP pool module + IPv6 + stickiness

Vegard Svanberg
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 <[hidden email]> [*Takapa@IRC (EFnet)]

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: Recommended IP pool module + IPv6 + stickiness

Alan DeKok-2
On Feb 3, 2021, at 5:00 AM, Vegard Svanberg <[hidden email]> 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.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: Recommended IP pool module + IPv6 + stickiness

Bjørn Mork
Alan DeKok <[hidden email]> 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

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: Recommended IP pool module + IPv6 + stickiness

Vegard Svanberg
In reply to this post by Alan DeKok-2
* Alan DeKok <[hidden email]> [2021-02-03 13:05]:

>
[snip]

Most excellent. Thank you!

--
Vegard Svanberg <[hidden email]> [*Takapa@IRC (EFnet)]

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: Recommended IP pool module + IPv6 + stickiness

Vegard Svanberg
In reply to this post by Bjørn Mork
* Bjørn Mork <[hidden email]> [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 <[hidden email]> [*Takapa@IRC (EFnet)]

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html