Re: Supernet block sizes - recommendations?
Same here. For large chunks of class C's, we send the end site directly to the NIC. This somewhat defeats the goal of using CIDR to reduce routing table explosion, since if the block comes directly from the NIC, no aggregation can be done by the service provider which connects the site. Its just hard convincing the end sites the 'merits' of a chunk of class C addresses for them-- too many are just too caught up in the 'prestige' involved in getting a class B network... if only someone could tell all those 'consultants' advising these end sites to get class B's... ;-) I can think of a couple of benefits of having big chunk of C's rather than a B: - two-level subnetting, even using dumb protocols that can't to VLSM (i.e. each individual class-C is a "subnet" of the block, plus each class-C can be subnetted itself) - more flexible routing policy possible with EGP2/BGP3 - a monolithic class-B can have only one routing policy (at least until BGP4) but a block of class-C's can be divided to support multiple policies for different parts of the block. This may not be something to advocate, though, since it plays against aggregation. --Vince
Vince Fuller <vaf@Valinor.Stanford.EDU> writes: Same here. For large chunks of class C's, we send the end site directly to the NIC.
This somewhat defeats the goal of using CIDR to reduce routing table explosion, since if the block comes directly from the NIC, no aggregation can be done by the service provider which connects the site.
Well it depends. If the chunks are large, reasonable aggregation still happens. No offence to Vince but we should concentrate on the lower levels of aggregation. That's where it matters most and where entropy is hopefully going to be less of a factor in the future. I have discussed this recently with some fairly senior people and to my big surprise and dismay they really thought the (achievable) object of the exercise was one supernet route per continent! :-) :-( Let me explain a little the strategy we recommend here: 1) Allocate a conservative(!) chunk size as most requestors have a tendency to stockpile. So unless they provide a good justification, they will be allocated less than requested. 2) To prevent low level entropy, "reserve" a contiguous chunk for the same requestor. Usually this is the same size as the chunk allocated. Tell the requestor that they can get (part of this) contiguous address space upon presenting documentation on how they use the first chunk. After about a year we have seen that only a small part comes back for more. 3) We plan to recycle the reserved space after 12-18 months. If we err very low in the first assignment we will have to open a new discontiguous chunk for the same organisation. So we have created two supernet routes instead of one. How big a deal is this if it happens occasionally? I deem this and acceptable tradeoff between address space usage and routing table size. Example: If we get a request for 64 Cs which is not very well substantiated we will allocate 16 or 32 and reserve the same amount. And now for something completely different..... Ways to convince people to let go of a "class" B request: Take their projected host and subnet numbers. Compute the address space usage factor and tell them: "Your own projections show that you will use only x% of the address space you request. By the Internet community's standards this too wasteful." We regularly get requests that lie in the low single digits by this standard. Of course you have to consider the proposed subnetting scheme. If they propose lots of 8-bit subnets with less than 10 hosts on them, we do suggest a different subnet size or in extreme cases even subnetting Cs. Tell them: "A scheme for classless inter-domain routing is coming. This means classes will no longer be visible soon. So why bother." Tell them that the procedure for getting Bs takes longer and requires them to provide more information to justify the request.... and keep that promise. Refer really notorious cases to the next higher level Internet Registry. They have more experience and a much thicker skin. We have been sitting on some bogus requests for a long time and I expect IANA to just sit on some indefinitely. This is really convincing and sometimes the only escape! Hope this helps some of you. Comments welcome. Daniel
Ways to convince people to let go of a "class" B request:
Of course you have to consider the proposed subnetting scheme. If they propose lots of 8-bit subnets with less than 10 hosts on them, we do suggest a different subnet size or in extreme cases even subnetting Cs.
Tell them: "A scheme for classless inter-domain routing is coming. This means classes will no longer be visible soon. So why bother."
My simple argument is usually this: Unless you are planning to have more than 255 hosts on a single subnet (which might not be a good idea in a *lot* of cases, and can also be offset by the 'secondary' addressing scheme of some router vendors), a group of class C addresses is way more flexible than a class C. Consider: 1. No more worries about 'split' subnets in wide area nets-- a definite problem in unforeseen future expansion plans. Subnet a class C on your wide area net and allocate other class C's at the end sites. This does not affect the site's routing tables (since their routers would have to carry all the subnets anyway). The large number of class C addresses is probably of more concern to ME (as a service provider) if I am not using CIDR. 2. No more worrying about variable length subnets, etc. Take a class C net, chop it up using whatever boundary wanted, and use a different mask for the other class C. Less administrative and technical headaches!! Usually these arguments do the trick-- its a matter of technical sense prevailing over 'I want a class B' pride. -vikas vikas@jvnc.net
participants (3)
-
aggarwal＠nisc.jvnc.net -
Daniel Karrenberg -
Vince Fuller