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