On Mon, Sep 28, 1998 at 04:21:27PM -0400, John Todd wrote:
[Warning: Long post. Get another cup of coffee before reading. To save time for those of you looking for the short answer: "Mark - start peering with your upstreams with a small announcement of /23 or /24, and you'll be fine - there's
There was a presentation at NANOG recently which detailed the use of NAT for multihoming. You may be generating too much traffic to use NAT. It might also be worthwhile to have redundant connections to the same transit provider. There are still a few providers around with free C space. You might consider trying that approach. As mentioned, a /16 is a fairly large amount of space to be wasting.
If your "primary" upstream from whom you've received a /24 is advertising your /24 in a larger aggregate, and you also are advertising your /24 through at least one other NSP that is not Sprint (the other possibly being Sprint or some other NSP) then you have two valid inbound paths with acceptable redundancy. You could also ask your primary upstream to "de-CIDRize" their own
If your primary upstream connection goes away you are then blackholed with respect to sprint, etc. as well as all of sprint's singly homed customers, of which there are many.
reasons that (from what I understand) Sprint and AGIS block those routes: overfull and unstable routing tables. You're creating the same end result with the same number of announcements, and using up valuable IPv4 space as a side effect. Double plus ungood. I think only single plus ungood in this case, for the wasted space.
I will certainly not say that you won't have some number of customers that can't get to your service. If you're that concerned about them, pull in T1s from both Sprint and AGIS - they'll announce routes from customers that they won't accept (at least, Sprint seems to - can't say
What about the 'handful of others'? This is ludicrous.
Essentially, I disagree that the premise for your address requirements of any size to ARIN is valid based on the information that you have revealed thus far. If you have 5,000 hosts that all must see the Internet and are running web servers, then it's a different story. But if you're just a few dozen (or even hundred) servers, a /24 or /23 should be sufficient for an acceptable delivery-of-service level.
Yes, I disagree with the address requirements as well. I don't think it's unreasonable for a large generator of traffic to want routable space. Perhaps there should, as mentioned, be additional guidelines from which the registries make a decision? How about a small area of space dedicated to those who have a real reason to have a /24-/20 size block? If the reason for filtering small block of space is to keep small companies not generating a lot of traffic from polluting routing space I don't think this applies. Austin