Then why is it that whenever we ask for extra space because of issues like this (in our case, we'd like to be able to assign /19 blocks for each larger POP so that it can be independantly routed in the Internet) we get told, sorry, that's an operational issue, we won't assign space for that.
You know, I've got the same problem. I've been trying to think of a way to deal with one of my locations slower growth, yet higher profile customers. I want them to be able to route independantly should the links all go out between it and my other locales, but it doesn't grow fast enough to keep up with the others and I can't manage to get it into its own /19 without having to seal from its block as the time draws near to beg ARIN for more space. It might behoove ARIN to allow us /19s for locations like that on a special request form. -- Jason Weisberger Chief Technology Officer SoftAware, Inc. 310/305-0275
On Thu, 5 Nov 1998, Jason Weisberger wrote:
You know, I've got the same problem. I've been trying to think of a way to deal with one of my locations slower growth, yet higher profile customers. I want them to be able to route independantly should the links all go out between it and my other locales, but it doesn't grow fast enough to keep up with the others and I can't manage to get it into its own /19 without having to seal from its block as the time draws near to beg ARIN for more space.
Well, like others have mentioned, there are ways around this, even if they are a bit sub-optimal. As long as you have at least a /19 total, and you use the same upstream provider(s) in all of the POPs that this /19 is used in, you can announce the specifics for each pop along with the /19 in each of those POPs. This will accomplish several things for you. First of all, like you said, if you lose all internal connectivity from any of those POPs, but you still have at least 1 upstream, all of your traffic will still get to you by following the more specific route. Since the /19 is still being announced, those backbones that filter longer masks will still send the traffic to your upstream(s) who will have the more specific routes in their tables and send the traffic in the right direction. This method, of course, is a bit unfriendly since you're making more announcements than you would be otherwise. 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.
This method, of course, is a bit unfriendly since you're making more announcements than you would be otherwise.
And if you are using 2 different providers for 2 POPs where the announcement is split, one POP is hosed. -- Jason Weisberger Chief Technology Officer SoftAware, Inc. 310/305-0275
On Thu, 5 Nov 1998, Jason Weisberger wrote:
This method, of course, is a bit unfriendly since you're making more announcements than you would be otherwise.
And if you are using 2 different providers for 2 POPs where the announcement is split, one POP is hosed.
Actually, if you mean you lost internal connectivity, each pop would be half hosed as long as you're announcing the /19 in both. In that case it might be best to just announce the specifics and let the traffic from the providers that do filter on masks longer than /19 be sub-optimal. 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.
Well, like others have mentioned, there are ways around this, even if they are a bit sub-optimal. As long as you have at least a /19 total, and you use the same upstream provider(s) in all of the POPs that this /19 is used in, you can announce the specifics for each pop along with the /19 in each of those POPs. This will accomplish several things for you. First of all, like you said, if you lose all internal connectivity from any of those POPs, but you still have at least 1 upstream, all of your traffic will still get to you by following the more specific route. Since the /19 is still being announced, those backbones that filter longer masks will still send the traffic to your upstream(s) who will have the more specific routes in their tables and send the traffic in the right direction.
This method, of course, is a bit unfriendly since you're making more announcements than you would be otherwise.
But you can remove the unfriendliness (again, in the case that you are using the same upstream in each location) by announcing the specifics with community no-export. Although I once tried this and it failed utterly for lack of clue in the upstream. -Phil
participants (3)
-
Brandon Ross -
Jason Weisberger -
Phillip Vandry