New dynamic IP pools module
Hi group, Here is a new FreeRADIUS module which provides dynamic IP addresses. It uses some new approaches and IMHO has greater functionality in some areas than already existing solutions. More information: http://projects.asn.pl/freemods/wiki/rlm_netvim_pools Source code (last test with v. 1.1.3): svn co http://svn.asn.pl/freemods/trunk/rlm_netvim_pool The code has been in production use since 2005, so I would consider it quite stable. BTW, I would like to submit a new vendor-specific RADIUS dictionary to the FreeRADIUS project: http://svn.asn.pl/misc/freeradius/dictionary.asn We, guys at ASN, develop a Linux distribution for network access servers - Lintrack [1] - and we use this dictionary for functionality implemented in our system. I would like to thank the FreeRADIUS development team for their great work. It's one of the best coded servers implemented in C I've ever seen (at least the core ;-)). Stay tuned for our further contributions to the project (and hey, don't miss our FreeRADIUS web interface [2])!. [1] http://www.lintrack.org/ [2] http://projects.asn.pl/ara/ Cheers, -- Pawel Foremski pjf@asn.pl
On Sat 27 Jan 2007 00:13, Pawel Foremski wrote:
Hi group,
Here is a new FreeRADIUS module which provides dynamic IP addresses. It uses some new approaches and IMHO has greater functionality in some areas than already existing solutions.
More information:
http://projects.asn.pl/freemods/wiki/rlm_netvim_pools
Source code (last test with v. 1.1.3):
svn co http://svn.asn.pl/freemods/trunk/rlm_netvim_pool
The code has been in production use since 2005, so I would consider it quite stable.
Cool. Looks like IPPools are becoming quite popular :-) A quick scan of it shows you have some interesting ideas, at the cost of being more complex than rlm_sqlippool I will check it out in more detail next week. Has it been tested with Postgresql? Cheers -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
On Saturday 27 January 2007 01:10, Peter Nixon wrote:
I will check it out in more detail next week. Has it been tested with Postgresql?
No, as it's clearly stated in docs, it works only with MySQL. Porting would require making the database access method more general, and probably rewriting some SQL queries (or just making them configurable) -- just in case someone wants to volunteer ;-). -- Pawel Foremski pjf@asn.pl
Pawel Foremski wrote:
On Saturday 27 January 2007 01:10, Peter Nixon wrote:
I will check it out in more detail next week. Has it been tested with Postgresql?
No, as it's clearly stated in docs, it works only with MySQL.
Porting would require making the database access method more general, and probably rewriting some SQL queries (or just making them configurable) -- just in case someone wants to volunteer ;-).
It might not be too hard. We'll see. If we do add the module, it's probably best to call it something other than "netvim". Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On Saturday 27 January 2007 08:42, Alan DeKok wrote:
Pawel Foremski wrote:
Porting would require making the database access method more general, and probably rewriting some SQL queries (or just making them configurable) -- just in case someone wants to volunteer ;-).
It might not be too hard. We'll see. If we do add the module, it's probably best to call it something other than "netvim".
Yeah, sure. Feel free to rename it. My original intention to share the code was just to show another approach, probably inspiring someone to take it and make better suited for inclusion in FreeRADIUS. However, with such design, one would most certainly need a user interface to manage the IP pools and host groups, as it's quite hard to do this by hand (although possible). -- Pawel Foremski pjf@asn.pl
On Sat 27 Jan 2007 13:18, Pawel Foremski wrote:
On Saturday 27 January 2007 08:42, Alan DeKok wrote:
Pawel Foremski wrote:
Porting would require making the database access method more general, and probably rewriting some SQL queries (or just making them configurable) -- just in case someone wants to volunteer ;-).
It might not be too hard. We'll see. If we do add the module, it's probably best to call it something other than "netvim".
Yeah, sure. Feel free to rename it.
Any suggestions?
My original intention to share the code was just to show another approach,
Thanks. We appreciate others contributing!
probably inspiring someone to take it and make better suited for inclusion in FreeRADIUS.
However, with such design, one would most certainly need a user interface to manage the IP pools and host groups, as it's quite hard to do this by hand (although possible).
Yep. We need a web interface to rlm_sqlippool also, but unfortunately the interface we use is embedded into a larger webapp which we won't be releasing and we haven't had the time to write something releasable as yet. Cheers -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
On Saturday 27 January 2007 18:17, Peter Nixon wrote:
On Sat 27 Jan 2007 13:18, Pawel Foremski wrote:
On Saturday 27 January 2007 08:42, Alan DeKok wrote:
It might not be too hard. We'll see. If we do add the module, it's probably best to call it something other than "netvim".
Yeah, sure. Feel free to rename it.
Any suggestions?
rlm_{1}{2}{3}pool 1: sql, mysql 2: asn, pjf, prio, hpw (hierarchical, prioritized, weighted) 3: optional "ip" I would pick rlm_sqlasnippool or rlm_sqlprioippool if I had to choose, but feel free to name it as you want; I would only like to mention the original name and purpose in the code. -- Pawel Foremski pjf@asn.pl
On Sat 27 Jan 2007 20:08, Pawel Foremski wrote:
On Saturday 27 January 2007 18:17, Peter Nixon wrote:
On Sat 27 Jan 2007 13:18, Pawel Foremski wrote:
On Saturday 27 January 2007 08:42, Alan DeKok wrote:
It might not be too hard. We'll see. If we do add the module, it's probably best to call it something other than "netvim".
Yeah, sure. Feel free to rename it.
Any suggestions?
rlm_{1}{2}{3}pool
1: sql, mysql 2: asn, pjf, prio, hpw (hierarchical, prioritized, weighted) 3: optional "ip"
I would pick rlm_sqlasnippool or rlm_sqlprioippool if I had to choose, but feel free to name it as you want; I would only like to mention the original name and purpose in the code.
I am about to put this in cvs. What does ASN stand for in your suggested naming? (I am trying to decide between rlm_sqlasnippool an rlm_sqlprioippool) -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
On Saturday 24 February 2007 15:40, Peter Nixon wrote:
I would pick rlm_sqlasnippool or rlm_sqlprioippool if I had to choose, but feel free to name it as you want; I would only like to mention the original name and purpose in the code.
I am about to put this in cvs.
Great!
What does ASN stand for in your suggested naming? (I am trying to decide between rlm_sqlasnippool an rlm_sqlprioippool)
ASN is name of the company that I've created this module for. [1] http://www.asn.pl/?lang=en - more English info to appear soon -- Pawel Foremski pjf@asn.pl
On Sat 24 Feb 2007 17:06, Pawel Foremski wrote:
On Saturday 24 February 2007 15:40, Peter Nixon wrote:
I would pick rlm_sqlasnippool or rlm_sqlprioippool if I had to choose, but feel free to name it as you want; I would only like to mention the original name and purpose in the code.
I am about to put this in cvs.
Great!
What does ASN stand for in your suggested naming? (I am trying to decide between rlm_sqlasnippool an rlm_sqlprioippool)
ASN is name of the company that I've created this module for.
[1] http://www.asn.pl/?lang=en - more English info to appear soon
Hmm.. OK. I don't like putting company names into the name of a module as it means nothing to our end users.... Would you be happy with rlm_sqlhpwippool (hierarchical, prioritized, weighted)? rlm_sqlprioippool sounds a little bit weird to my ears (eyes)... Cheers -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
On Sun 25 Feb 2007 15:23, Paweł Foremski wrote:
On Sunday 25 February 2007 14:04, Peter Nixon wrote:
Would you be happy with rlm_sqlhpwippool (hierarchical, prioritized, weighted)?
Sure. OK. Added as rlm_sqlhpwippool to cvs HEAD.
I have also added a link to: http://wiki.freeradius.org/IP_Pool And the documentation to: http://wiki.freeradius.org/Rlm_sqlhpwippool Please check the documentation when you have time (I have made a few small changes to generalise it a little). Cheers -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
On Sat 27 Jan 2007 09:42, Alan DeKok wrote:
Pawel Foremski wrote:
On Saturday 27 January 2007 01:10, Peter Nixon wrote:
I will check it out in more detail next week. Has it been tested with Postgresql?
No, as it's clearly stated in docs, it works only with MySQL.
Porting would require making the database access method more general, and probably rewriting some SQL queries (or just making them configurable) -- just in case someone wants to volunteer ;-).
It might not be too hard. We'll see. If we do add the module, it's probably best to call it something other than "netvim".
I agree, but please don't call it rlm_sqlippool2 :-) As a comparison of the features: rlm_sqlippool: * 958 lines of code + Supports any database supported by FreeRADIUS + Uses 1 SQL table (per instance) * Supports multiple IP ranges per pool rlm_netvim_pools * 831 lines of code - Supports MySQL only - Use 6 different SQL tables - Does some periodic synchronization steps to keep tables up to date * Supports multiple IP ranges by creating different pools and then grouping them + Supports pool priorities (based on utilization and weighting) end the host group loop Please note that I have yet to test the code (just scanning it by eye) so please feel free to correct any mis-statements I made. The basic claim to fame that I can see is that it supports multiple, prioritized pools for a single host group (whatever that is). I am interested in how this applies generally in different configurations with different access methods, but it is an interesting idea. sqlippool does support multiple IP ranges in the same pool, and could do simple prioritization/fallback by have multiple instances of the module using a different sql table each. (Not say that this is better or worse, just that it should be possible) Now, I am a fan of leveraging SQL to get jobs done, but without a production test I am not sure whether the extra complexity (it seems that it would also be significantly slower than sqlippool) is worth it. Obviously someone finds it usefull though, or it wouldn't have been written. :-) I think this should probably go into cvs head, but with an appropriate name (and documentation). I can see that this is going to cause even more confusion with the people who come on the list and ask about DHCP/IPPools so it is important that we document the advantages of each available module clearly. http://wiki.freeradius.org/IP-Pool would be a good place to start. Cheers -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
On Saturday 27 January 2007 13:53, Peter Nixon wrote:
(snip) - Does some periodic synchronization steps to keep tables up to date
Well, that's needed for "real world". If we could assume 100% protocol reliability (ie. that we don't miss a single packet from NAS), these wouldn't be needed, I guess.
The basic claim to fame that I can see is that it supports multiple, prioritized pools for a single host group (whatever that is).
I will try to provide an example showing almost all of it's features. Imagine you have two OSPF areas consisting of some network access servers. In each area you have machines belonging to two different IP subnets, say: 1) area 1: 10.1.1.0/24, 10.1.2.0/24 2) area 2: 10.2.1.0/24, 10.2.2.0/24 Now then, you'd like to share a public IPv4 address space 2.0.0.0/16 between dialup clients connecting to NASes in these two areas. Because it'd be a good idea to take advantage of OSPF route summarization (to avoid distributing /32 routes), you split the big /16 class into smaller /17, assigning the lower half to area 1 and the higher one to area 2. However, it's possible that /17 class would not suffice for single network area under some special circumstances, so you would like to allow e.g. area 2 borrow some addresses from area 1. How to do this with netvim pools? 1) create host group "hg1", representing OSPF area 1 - add 10.1.1.0/24 to hg1 - add 10.1.2.0/24 to hg1 2) create host group "hg2", representing OSPF area 2 - add 10.2.1.0/24 to hg2 - add 10.2.2.0/24 to hg2 3) create pool name "public-ip" 4) create pool instances, each having name "public-ip" - to hg1, assign 2.0.0.0/17 with prio 0 - to hg1, assign 2.0.128.0/17 with prio 1 - to hg2, assign 2.0.128.0/17 with prio 0 - to hg2, assign 2.0.0.0/17 with prio 1 In multihomed networks one may want to add new public IP address space (say 3.0.0.0/16) in the same manner, but this time assigning some weights. This way it should be possible to balance network traffic between two upstream ISPs in a natural way. The last step would be: 4) - to hg1, assign 2.0.0.0/17 with prio 0 weight 3 - to hg1, assign 3.0.0.0/17 with prio 0 weight 1 - to hg1, assign 2.0.128.0/17 with prio 1 weight 3 - to hg1, assign 3.0.128.0/17 with prio 1 weight 1 - to hg2, assign 2.0.128.0/17 with prio 0 weight 3 - to hg2, assign 3.0.128.0/17 with prio 0 weight 1 - to hg2, assign 2.0.0.0/17 with prio 1 weight 3 - to hg2, assign 3.0.0.0/17 with prio 1 weight 1 That should spread about 75% through ISP serving 2/16 and about 25% through ISP serving 3/16. Obviously it'll vary in case traffic is balanced also by other means (BGP, for instance). Well, and finally, you would like to provide a backup catch-all IP pool: 1) create host group "all" - assign 0.0.0.0/0 to it - connect other host groups as "children" 2) create pool instance, each having name "public-ip" - to "all", assign say 190.180.128.0/17 prio 10 One may argue that such "selection of host group" of an incoming packet may already be done in text file configuration, but it's not possible with NASes configured in an SQL database. Cheers, -- Pawel Foremski pjf@asn.pl
participants (4)
-
Alan DeKok -
Pawel Foremski -
Paweł Foremski
-
Peter Nixon