New dynamic IP pools module

[Pawel Foremski]

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 at asn.pl