New dynamic IP pools module
pjf at asn.pl
Sat Jan 27 15:19:45 CET 2007
On Saturday 27 January 2007 13:53, Peter Nixon wrote:
> - 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 22.214.171.124/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 126.96.36.199/17 with prio 0
- to hg1, assign 188.8.131.52/17 with prio 1
- to hg2, assign 184.108.40.206/17 with prio 0
- to hg2, assign 220.127.116.11/17 with prio 1
In multihomed networks one may want to add new public IP address space (say
18.104.22.168/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:
- to hg1, assign 22.214.171.124/17 with prio 0 weight 3
- to hg1, assign 126.96.36.199/17 with prio 0 weight 1
- to hg1, assign 188.8.131.52/17 with prio 1 weight 3
- to hg1, assign 184.108.40.206/17 with prio 1 weight 1
- to hg2, assign 220.127.116.11/17 with prio 0 weight 3
- to hg2, assign 18.104.22.168/17 with prio 0 weight 1
- to hg2, assign 22.214.171.124/17 with prio 1 weight 3
- to hg2, assign 126.96.36.199/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 188.8.131.52/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.
pjf at asn.pl
More information about the Freeradius-Devel