Approach to allocating netblocks
For the first time we have our own ARIN-assigned netblocks that we can now split out and divide to our customers. What's the best approach to handing out /30's, /29's, etc. that is efficient as possible but allows for customers to expand their allocation to a neighboring block? I was thinking of having one /24 for each block size, and then do the divide and conquer approach by allocating the first /30, for example, as 0 and 128, then next two at 64 and 192, etc. Once there's only one /30 free between each allocation, I would start using another /24. Of course, that would mean 50% (or less) utilization. Ideas? Frank
If most of your allocations are small, and you don't plan on growing them very often, you'll probably do better with starting at the ends and working your way inward.For example,. for /30s, allocate 0/30, then 4/30, 248/30, and 252/30 before moving in to 8/30, 12/30, 240/30, and 244/30. That way you're preserving larger netblocks for as long as possible before breaking them up. Frank Bulk wrote:
For the first time we have our own ARIN-assigned netblocks that we can now split out and divide to our customers.
What's the best approach to handing out /30's, /29's, etc. that is efficient as possible but allows for customers to expand their allocation to a neighboring block?
I was thinking of having one /24 for each block size, and then do the divide and conquer approach by allocating the first /30, for example, as 0 and 128, then next two at 64 and 192, etc. Once there's only one /30 free between each allocation, I would start using another /24. Of course, that would mean 50% (or less) utilization.
Ideas?
Frank
For the first time we have our own ARIN-assigned netblocks that we can now split out and divide to our customers.
What's the best approach to handing out /30's, /29's, etc. that is efficient as possible but allows for customers to expand their allocation to a neighboring block?
I was thinking of having one /24 for each block size, and then do the
I see what you're saying, but what if the customer whom you assigned the 0/30 to wants a larger block...rather than making them renumber (which in the case of a small customer, is a very painful experience because of all the DNS and router/firewall reconfiguration issues that they don't normally deal with and therefore cause their service provider (us) and their consultant a lot of grief), I would want to give them 0/29. But if the 4/30 is already assigned to someone else, I'm stuck. But perhaps the BCP is to make the customer renumber, in which case I'm making things more complicated than they need to be. Frank -----Original Message----- From: Dave Israel [mailto:davei@otd.com] Sent: Wednesday, January 14, 2009 10:17 AM To: frnkblk@iname.com Cc: NANOG list Subject: Re: Approach to allocating netblocks If most of your allocations are small, and you don't plan on growing them very often, you'll probably do better with starting at the ends and working your way inward.For example,. for /30s, allocate 0/30, then 4/30, 248/30, and 252/30 before moving in to 8/30, 12/30, 240/30, and 244/30. That way you're preserving larger netblocks for as long as possible before breaking them up. Frank Bulk wrote: divide
and conquer approach by allocating the first /30, for example, as 0 and 128, then next two at 64 and 192, etc. Once there's only one /30 free between each allocation, I would start using another /24. Of course, that would mean 50% (or less) utilization.
Ideas?
Frank
Customer should have the forethought to request the right amount of space to include for growth. If customer requested more space, rather than grow into another adjacent block, we would just assign them an additional block elsewhere in the overall subnet, and route both blocks to them. Jason On Wed, Jan 14, 2009 at 10:30 AM, Frank Bulk <frnkblk@iname.com> wrote:
I see what you're saying, but what if the customer whom you assigned the 0/30 to wants a larger block...rather than making them renumber (which in the case of a small customer, is a very painful experience because of all the DNS and router/firewall reconfiguration issues that they don't normally deal with and therefore cause their service provider (us) and their consultant a lot of grief), I would want to give them 0/29. But if the 4/30 is already assigned to someone else, I'm stuck.
But perhaps the BCP is to make the customer renumber, in which case I'm making things more complicated than they need to be.
Frank
-----Original Message----- From: Dave Israel [mailto:davei@otd.com] Sent: Wednesday, January 14, 2009 10:17 AM To: frnkblk@iname.com Cc: NANOG list Subject: Re: Approach to allocating netblocks
If most of your allocations are small, and you don't plan on growing them very often, you'll probably do better with starting at the ends and working your way inward.For example,. for /30s, allocate 0/30, then 4/30, 248/30, and 252/30 before moving in to 8/30, 12/30, 240/30, and 244/30. That way you're preserving larger netblocks for as long as possible before breaking them up.
For the first time we have our own ARIN-assigned netblocks that we can now split out and divide to our customers.
What's the best approach to handing out /30's, /29's, etc. that is efficient as possible but allows for customers to expand their allocation to a neighboring block?
I was thinking of having one /24 for each block size, and then do the
Frank Bulk wrote: divide
and conquer approach by allocating the first /30, for example, as 0 and 128, then next two at 64 and 192, etc. Once there's only one /30 free between each allocation, I would start using another /24. Of course, that would mean 50% (or less) utilization.
Ideas?
Frank
-- Jason Biel jason@biel-tech.com
On Wed, Jan 14, 2009 at 10:34:29AM -0600, Jason Biel wrote:
Customer should have the forethought to request the right amount of space to include for growth.
hmm, as a vict^H^H^H^H former associate of a few startups I can assure you the customer will almost never know how much space they need for growth, or when. :)
If customer requested more space, rather than grow into another adjacent block, we would just assign them an additional block elsewhere in the overall subnet, and route both blocks to them.
Seems reasonable as long as it can be done whenever the customer discovers they really do need more space. Jeff Kinz
--On onsdag, onsdag 14 jan 2009 10.30.18 -0600 Frank Bulk <frnkblk@iname.com> wrote:
But perhaps the BCP is to make the customer renumber, in which case I'm making things more complicated than they need to be.
Most customers with PA space (which is what you are giving them) are quite used to renumbering. If not, they will become, given v6 PAishness. Renumbering is not to be avoided at all costs, because: Renumbering cleans cruft and finds mishaps waiting to happen. Renumbering rewards those who have done proper configuration separation. Renumbering rewards those who have automated their systems management. Renumbering thus is good for you. There are economic incentives (keeping the customer because said customer hovers in the Lagrange point between clueless and lazy) to let suboptimal numbering schemes fester. Might alter picture above, but from operational standpoint renumbering is not that bad. -- Måns Nilsson M A C H I N A Now my EMOTIONAL RESOURCES are heavily committed to 23% of the SMELTING and REFINING industry of the state of NEVADA!!
I hesitate to put my customers in "the Lagrange point between clueless and lazy" because they're SMBs doing what 99% of the other SMBs out there do. I have some customers who are in the hub in a multi-site VPN network and renumbering would be very painful. While Renumbering has all the positives you mentioned, it's a sure way to sour the customer relationship. Much cheaper, long-term, to set aside adjacent address space. Frank -----Original Message----- From: Måns Nilsson [mailto:mansaxel@besserwisser.org] Sent: Thursday, January 15, 2009 4:17 AM To: NANOG list Subject: RE: Approach to allocating netblocks --On onsdag, onsdag 14 jan 2009 10.30.18 -0600 Frank Bulk <frnkblk@iname.com> wrote:
But perhaps the BCP is to make the customer renumber, in which case I'm making things more complicated than they need to be.
Most customers with PA space (which is what you are giving them) are quite used to renumbering. If not, they will become, given v6 PAishness. Renumbering is not to be avoided at all costs, because: Renumbering cleans cruft and finds mishaps waiting to happen. Renumbering rewards those who have done proper configuration separation. Renumbering rewards those who have automated their systems management. Renumbering thus is good for you. There are economic incentives (keeping the customer because said customer hovers in the Lagrange point between clueless and lazy) to let suboptimal numbering schemes fester. Might alter picture above, but from operational standpoint renumbering is not that bad. -- Måns Nilsson M A C H I N A Now my EMOTIONAL RESOURCES are heavily committed to 23% of the SMELTING and REFINING industry of the state of NEVADA!!
On Wed, Jan 14, 2009 at 09:05, Frank Bulk <frnkblk@iname.com> wrote:
For the first time we have our own ARIN-assigned netblocks that we can now split out and divide to our customers.
What's the best approach to handing out /30's, /29's, etc. that is efficient as possible but allows for customers to expand their allocation to a neighboring block?
We pay much more attn to efficient utilization and advertisement aggregation than to ensuring that customers have contiguous blocks. For example, we internally assign a /24 to a given PE router and then assign from it straight through; 0/30, 4/30, 8/29, etc. as customers get turned up or request more space. Then when it's used up, we add another... Although it is neat and tidy to have contiguous blocks everywhere, the cost to benefit doesn't seem to be there so we focus on aggregation at transition points such as edge to backbone, backbone to peers, etc. ~Chris
I was thinking of having one /24 for each block size, and then do the divide and conquer approach by allocating the first /30, for example, as 0 and 128, then next two at 64 and 192, etc. Once there's only one /30 free between each allocation, I would start using another /24. Of course, that would mean 50% (or less) utilization.
Ideas?
Frank
-- Chris Grundemann www.chrisgrundemann.com
On Wed, Jan 14, 2009 at 11:05 AM, Frank Bulk <frnkblk@iname.com> wrote:
For the first time we have our own ARIN-assigned netblocks that we can now split out and divide to our customers.
What's the best approach to handing out /30's, /29's, etc. that is efficient as possible but allows for customers to expand their allocation to a neighboring block?
Frank, Prioritize the following optimization criteria in order of importance to you: 1. Most efficient use of address space. 2. Maximum routing aggregability. 3. Highest probability of expansion by only changing the netmask Solution to #1: For each new assignment, select the smallest block of available addresses which is large enough to accommodate the new assignment, where a "block" is defined as a network plus netmask, not defined as a range of addresses. Carve the assignment from the end of the block. Downside: expansion by changing the netmask is unlikely since the assignments are all crunched together. Solution to #2: Split your ARIN netblock based on your current and anticipated routing areas. Inside each sub-block, implement your second priority. Downside: Over time this becomes futile as your routing areas move, split and merge. Solution to #3: For each new assignment, select the largest block of available addresses. Split it in half, placing the new assignment in the middle. When the assignee expands, there is a relatively high probability that the adjacent part of the next shorter netmask is still available. This is called "sparse allocation." Downside: This fragments the heck out of your address space. You will typically only be able to assign address blocks whose netmask is more than log2(n) bits longer than the netmask of your ARIN block where n is the total number of assignments you've already made. For example, after assigning 150 /29's from your /20, the largest remaining block would be a /28. Assign 150 more /30's and your largest remaining block would be a /29! With Solution #1, you'd still have an untouched /21. You can do a hybrid of #1 and #3 by doing things like "pick the smallest block that's at least 4 times the size you need, split in half, etc." Or, you might split the ARIN block in half and do #3 for /28 and longer assignments in the first half and #1 for /27 and shorter assignments in the second. Unfortunately, the efficacy of such approaches is unproven. Unless you have a particularly large system (and if this is your first ARIN block, you don't) just go with solution #1 so that you don't run into problems with what will probably be tightening criteria for subsequent IPv4 address assignment. On Thu, Jan 15, 2009 at 5:16 AM, Måns Nilsson <mansaxel@besserwisser.org> wrote:
from operational standpoint renumbering is not that bad.
Måns, http://www.ietf.org/internet-drafts/draft-carpenter-renum-needs-work-01.txt provides 24 pages and growing worth of problems with renumbering. Here's a simple one: Web browsers intentionally violate the DNS TTL with a technique called "DNS Pinning." DNS Pinning limits acceptance of server IP address changes due to a javascript issue where repeated address changes could otherwise be used to induce a browser to scan the inside of a firewalled network and report the results to an outside attacker. This can persist as long as the browser is running, perhaps months at a time. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
--On torsdag, torsdag 15 jan 2009 15.11.48 -0500 William Herrin <herrin-nanog@dirtside.com> wrote:
On Thu, Jan 15, 2009 at 5:16 AM, Måns Nilsson <mansaxel@besserwisser.org> wrote:
from operational standpoint renumbering is not that bad.
Måns,
http://www.ietf.org/internet-drafts/draft-carpenter-renum-needs-work-01.t xt provides 24 pages and growing worth of problems with renumbering.
Here's a simple one:
Web browsers intentionally violate the DNS TTL with a technique called "DNS Pinning."
<snip> Given the small netmasks, I'd guess that most of the browser population behind them is addicted to a proxy. The proxy might not subscribe to pinning. Also, the browsers that run for months typically aren't on end-user PCs, but on the workstations of the clued, if I might be so blunt. It is not that renumbering is painless, not at all. But it is very useful as "spring cleaning". I'd rather know what happens by testing it than finding out by being woken up while on call. -- Måns Nilsson M A C H I N A Now KEN and BARBIE are PERMANENTLY ADDICTED to MIND-ALTERING DRUGS ...
participants (7)
-
Chris Grundemann -
Dave Israel -
Frank Bulk -
Jason Biel -
jkinz＠kinz.org -
Måns Nilsson -
William Herrin