Use "tree".
Actually, given IANA's current requirements, and most ISP's desires to abide by both the letter and intent of these guidelines, I'd have to day, "don't". The reason is, tree is a program designed to allocate 'growable' blocks, which translates into deliberately anti-optimal allocation. (Apologies to the authors for any perceived negativity - tree does what it was intended to do, wonderfully - it's just the opposite of what IANA says to do.) This maximizes the number of holes, while minimizing the hole size. At a very early point in allocation, you stop being able to allocate blocks, when your density is basically minimum. To keep IANA happy, and to cause maximal-density usage of CIDR blocks, what should be allocated is un-growable blocks, just big enough for customer needs. This ensures that once the CIDR block is allocated-out, density is sufficient to justify trivially another CIDR block. This is basically a space-packing problem, which while non-trivial, yields solutions which are quite simple to code. The general process is as follows. To do this, you want to avoid breaking up any 'holes', so that you will most likely be able to accommodate the needs of any customer, big or small. If you have an unused power-of-two chunck which exactly fits your customer's needs, give it to them. If not, break up the smallest "hole" bigger that they need. This minimizes the number of "holes", maximizes "hole" size, and maximizes probability that all customers needs will be met, and that all holes will be used before you need to get another block to meet new needs. At a previous employer, I developed a perl script to do just this. I'll see whether it's possible to get them to release this code to the public domain, since they aren't using it (my previous employer was acquired (read: absorbed) by PSInet, and all engineering and associated development is now done by PSI, with any prior work non-PSI code basically abandoned (or so I am lead to believe).
Brandon Ross wrote:
We are in need of a software package to manage our IP space. We've looked at several products on the market but haven't found anything that really suits an ISP's needs very well. Does anyone know of anything on the market that works well? It should understand CIDR and be hierarchical.
I guess the question would be, what is meant by hierarchical... do you mean assigning sub-CIDR blocks to customers, and then managing customers' space as well as your own? CIDR and VLSM goes without saying... -- Brian Dickson, Email: briand@teleglobe.net Teleglobe USA, Inc., Tel : +1 703 821 4818 Suite 400, 8251 Greensboro Drive, Fax : +1 703 821 4885 McLean, Virginia, USA, 22102 http://www.teleglobe.com
On Mon, 19 Oct 1998, Brian Dickson wrote:
We are in need of a software package to manage our IP space. We've looked at several products on the market but haven't found anything that really suits an ISP's needs very well. Does anyone know of anything on the market that works well? It should understand CIDR and be hierarchical.
I guess the question would be, what is meant by hierarchical... do you mean assigning sub-CIDR blocks to customers, and then managing customers' space as well as your own?
Something like that. We have a need to assign perhaps a large block to web hosting, then out of that block assign smaller blocks to each server, then yet a smaller block still to each customer, for example. CIDR and VLSM goes without saying... Brandon Ross Network Engineering 404-815-0770 800-719-4664 Director, Network Engineering, MindSpring Ent., Inc. info@mindspring.com ICQ: 2269442 Stop Smurf attacks! Configure your router interfaces to block directed broadcasts. See http://www.quadrunner.com/~chuegen/smurf.cgi for details.
To keep IANA happy, and to cause maximal-density usage of CIDR blocks, what should be allocated is un-growable blocks, just big enough for customer needs. This ensures that once the CIDR block is allocated-out, density is sufficient to justify trivially another CIDR block.
This also means when the customer needs more space, they either have to renumber (and this is the number one customer complaint), or have to set up their network with overlayed subnets (and not all the stuff out there can successfully do that). We serve primarily business customers with dedicated LAN access, and have relatively little dialup business (as measured by address space and revenue). This is one of our biggest costs since part of our service is to manage the internet access for our customers, including on-site configuration. So that means we actually go renumber the customer for them. That's good for the customer, but it also means we are sorely aware of the costs involved. We try to balance things the best we can by working with customers to determine what their needs are with respect to their expanding networking needs over the coming year. I try to allocate what they reasonably expect to need in the next 12 months, giving them the smallest subnet that fits that projected need if it is not more than 2 or 4 times the current need. But I have had customers who hooked up 3 machines to begin with and knew that they would have 100 machines within 6-9 months, and they really did.
This is basically a space-packing problem, which while non-trivial, yields solutions which are quite simple to code. The general process is as follows.
The coding is certainly simple enough, but is it a practical business model? The answer is actually yes, if one considers a reasonable balance between current and future needs. I've tried the "tree" approach, manually and have found that I end up going back and re-using the "holes" for different (and usually new) customers without leaving space for customer expansion. Once we have reached the 50% usage mark it's still not time to go back and get more space, so the "holes" get used. Still, there is a 50% time in which we can expand most customers with growing space if we do use the "tree" method. Today as we are rapidly growing, new customers still outpace the growth in network size of existing customers. It's still a business decision on which way to allocate network address space, rather than a technical one. -- -- *-----------------------------* Phil Howard KA9WGN * -- -- | Inturnet, Inc. | Director of Internet Services | -- -- | Business Internet Solutions | eng at intur.net | -- -- *-----------------------------* philh at intur.net * --
This also means when the customer needs more space, they either have to renumber (and this is the number one customer complaint), or have to set up their network with overlayed subnets (and not all the stuff out there can successfully do that).
You bet! (Not to mention that the overlayed subnet solution requires that all traffic between the two subnets must bounce off the router, which means that the router may need a 100Mbps port in some cases instead of the 10Mbps port the average custoemr router provides).
We serve primarily business customers with dedicated LAN access, and have relatively little dialup business (as measured by address space and revenue). This is one of our biggest costs since part of our service is to manage the internet access for our customers, including on-site configuration. So that means we actually go renumber the customer for them. That's good for the customer, but it also means we are sorely aware of the costs involved. We
Ditto for us. While we have been known to make sparse allocations on occasion, we usually don't. The overwhelming majority of our customers do not upgrade their address space. If we made all allocations sparsely, I can assure you that we would have found ourselves at the bottom of a hole of our own digging soon enough when some customer needed a big block and all we had was a multitude of small blocks left.
try to balance things the best we can by working with customers to determine what their needs are with respect to their expanding networking needs over the coming year. I try to allocate what they reasonably expect to need in the next 12 months, giving them the smallest subnet that fits that projected need if it is not more than 2 or 4 times the current need. But I have had customers who hooked up 3 machines to begin with and knew that they would have 100 machines within 6-9 months, and they really did.
We deal with these on a case by case basis, and the usage predictions made by the customers do indeed come true much of the time. I think the problem is that tree is claimed to systematically use the sparse approach, and that is when you can get into trouble. -Phil
participants (4)
-
Brandon Ross -
Brian Dickson -
Phil Howard -
Phillip Vandry