nanog mailing list archives
RE: routing table size
From: "Mark Radabaugh" <mark () amplex net>
Date: Mon, 29 Jul 2002 22:43:51 -0400
Until then, my money is on clueless redist connected/statics, large cable/dsl providers who announce a /24 per pop/city/whatever to their single transit provider, and general ignorance. Why attribute to functionality what can easily be explained by incomptence. :) -- Richard A Steenbergen <ras () e-gerbil net>
You forgot one of my favorite frustrations - slow start. Try this: a) start an ISP and tell your upstream you want a /21. They will tell you that you can only have a /24. b) Tell them that you understand they can't give you a /21 based on ARIN guidelines but you would like them to reserve it for you. Listen to them laugh. c) Keep requesting more space as you need it while you grow. Tell them you want contiguous space. Listen to them laugh. Your choice is take a new discontinuous block or renumber the whole network. This would be why we announce 2 /22's and 2 /23's even though given contiguous space we could make a single announcement. Add in the $2500 cost of obtaining a ARIN allocation versus what are 'free' addresses from our upstreams and we will probably continue as-is for a while. Why does ARIN need $2500 for an entry in a database anyway? End result is we would like to make a single announcement. By being truthful in requesting address space based on the guidelines we end up with address space that is fragmented - so we make the extra announcements. I have not seen a statistic for non-transit AS's announcing multiple discontinuous prefixes - I suspect that there are a lot of them for the same reason we do it. Obviously you can't keep leaving big 'reserved' holes in your allocations to downstreams for potential growth. You can't expect a network to renumber everytime they need more space. I don't have a good answer to this problem nor do I expect one - it's just another reason why we have additional growth in the routing tables. Mark Radabaugh Amplex (419) 833-3635
Current thread:
- Re: routing table size, (continued)
- Re: routing table size Ralph Doncaster (Jul 27)
- Re: routing table size David Schwartz (Jul 27)
- Re: routing table size Stephen J. Wilcox (Jul 27)
- Re: routing table size David Schwartz (Jul 27)
- Re: routing table size Stephen J. Wilcox (Jul 27)
- Re: routing table size Brian (Jul 29)
- Re: routing table size Richard A Steenbergen (Jul 29)
- Re: routing table size Paul Schultz (Jul 29)
- RE: routing table size Phil Rosenthal (Jul 29)
- RE: routing table size jnull (Jul 29)
- Re: routing table size David Schwartz (Jul 27)
- Re: routing table size Ralph Doncaster (Jul 27)
- RE: routing table size Mark Radabaugh (Jul 29)
- Re: routing table size Tim Thorne (Jul 30)