Re: FW: /8s and filtering
I was also curious about this - if I am a customer who wants to multihome and can justify only a /24, I would go to an ISP which has an allocation from the Class C space rather than one from the Class A space.
It doesn't matter. For all practical purposes, basement multihomers only care that their two or three providers have their route.
Maybe I'm missing something, but what good would it do for someone to multihome if only their own providers accept their route, but nobody else does? I realize that their block should be still announced with their ISP's larger aggregate, but what good does this do if your ISP goes down and can't announce the large aggregate. If you're a smaller organization, perhaps you'll only have a /23 from your upstream provider. With the filtering that seems to be in place, it seems like the only way you can truly multihome with a /23 is if it happens to be in the old Class C space. Or is this wrong? What seems to be needed is perhaps a /8 set aside by the RIR specifically to allocate to small organizations that wish to multihome that people would accept /24 and shorter from. Forrest
Hello, I had the same questions. Could someone please answer these? Harsha. On Tue, 10 Dec 2002, Forrest wrote:
I was also curious about this - if I am a customer who wants to multihome and can justify only a /24, I would go to an ISP which has an allocation from the Class C space rather than one from the Class A space.
It doesn't matter. For all practical purposes, basement multihomers only care that their two or three providers have their route.
Maybe I'm missing something, but what good would it do for someone to multihome if only their own providers accept their route, but nobody else does? I realize that their block should be still announced with their ISP's larger aggregate, but what good does this do if your ISP goes down and can't announce the large aggregate.
If you're a smaller organization, perhaps you'll only have a /23 from your upstream provider. With the filtering that seems to be in place, it seems like the only way you can truly multihome with a /23 is if it happens to be in the old Class C space. Or is this wrong?
What seems to be needed is perhaps a /8 set aside by the RIR specifically to allocate to small organizations that wish to multihome that people would accept /24 and shorter from.
Forrest
comments inline On Tue, Dec 10, 2002 at 12:36:39PM -0600, Forrest wrote:
I was also curious about this - if I am a customer who wants to multihome and can justify only a /24, I would go to an ISP which has an allocation from the Class C space rather than one from the Class A space.
It doesn't matter. For all practical purposes, basement multihomers only care that their two or three providers have their route.
Maybe I'm missing something, but what good would it do for someone to multihome if only their own providers accept their route, but nobody else does? I realize that their block should be still announced with their ISP's larger aggregate, but what good does this do if your ISP goes down and can't announce the large aggregate.
For the assigned block to be part of the same aggregate(of both providers), that implys that the providers sharing the responsibility for the aggregate. It happens, but is rare. In this case, the providers must accept more specific routes from each other, that is within the space being aggregated. If they do not share specifics, one uplink down will cause a large percentage ~50% for the customer. This scenario is valid for load balancing, but redundancy is fragile. The only advantage I see is no limit to prefix length. You can do this with a /28 if you want... given the above caveats are addressed.
If you're a smaller organization, perhaps you'll only have a /23 from your upstream provider. With the filtering that seems to be in place, it seems like the only way you can truly multihome with a /23 is if it happens to be in the old Class C space. Or is this wrong?
In today's VLSM world... the old classes have no bearing on filtering in my experience. Prefix length discrimination knows no classfull boundaries.
What seems to be needed is perhaps a /8 set aside by the RIR specifically to allocate to small organizations that wish to multihome that people would accept /24 and shorter from.
There is value in the current filtering of longest prefixes... Allowing anyone to multihome with BGP, using any network size, is going to double our BGP tables overnight. Perhaps its good that you must be of some size to participate in public BGP. Many providers offer redundancy that is more appropriate for the smaller networks. -- ,N ~Nathan - routing & switching dude/fly-boy/sport biker - San Jose CA~
On Tue, 10 Dec 2002, N wrote:
comments inline
If you're a smaller organization, perhaps you'll only have a /23 from your upstream provider. With the filtering that seems to be in place, it seems like the only way you can truly multihome with a /23 is if it happens to be in the old Class C space. Or is this wrong?
In today's VLSM world... the old classes have no bearing on filtering in my experience. Prefix length discrimination knows no classfull boundaries.
That doesn't seem to be true, look at Verio's routing policies for example. http://info.us.bb.verio.net/routing.html <SNIP> In the traditional Class A space (i.e., 0/1), we accept /22 and shorter. In the traditional Class B space (i.e., 128/2), we accept /22 and shorter. In the traditional Class C space (i.e., 192/3), we accept /24 and shorter. </SNIP> If people didn't accept /24's from the old Class C space then it seems like anyone still using swamp space would find themselves blackholed. Such as this block to pick one at random. 192.203.197.0/24
What seems to be needed is perhaps a /8 set aside by the RIR specifically to allocate to small organizations that wish to multihome that people would accept /24 and shorter from.
There is value in the current filtering of longest prefixes... Allowing anyone to multihome with BGP, using any network size, is going to double our BGP tables overnight. Perhaps its good that you must be of some size to participate in public BGP. Many providers offer redundancy that is more appropriate for the smaller networks.
I guess I don't understand how allowing "just anyone" to multihome is going to double the BGP table size. With the current ASN setup you couldn't have more than ~65000 organizations multihoming. Personally, I think an organization announcing 100 more specifics on accident along with announcing their large aggregate is a much larger problem than the small amount of small organizations that want to multihome. In reality, all the filtering policies do is cause people to simply waste enough IP space in order to qualify for a block that won't get filtered. Have you seen the waste that goes on with some of these web hosting companies? I've seen web servers that have a /25 assigned to *ONE* server because the server owner was willing to pay the $5/IP or whatever that the ISP charges. And the server wasn't even running SSL or anything that required IP addresses, virtual hosting would have worked just fine. You think perhaps there might be another reason for why this is happening? Perhaps it's the only way a company can justify asking for a /19 that will make it past the filters. Forrest
On Tue, 10 Dec 2002 12:36:39 -0600 (CST), Forrest wrote:
Maybe I'm missing something, but what good would it do for someone to multihome if only their own providers accept their route, but nobody else does? I realize that their block should be still announced with their ISP's larger aggregate, but what good does this do if your ISP goes down and can't announce the large aggregate.
Smaller multihomers elect to multihome for a variety of reasons. Those reasons typically include latency reduction and toleration of POP failures, router failures, and line failures. They're not looking to stay online is Sprint or MCI disappears entirely. If you multihomed to 2 providers in this manner and made a table of all your downtime and its causes, loss of the larger aggregate would the tiniest fraction of your downtime, which is already a tiny fraction of the time. We don't put parachutes on commuter jets. The failures where these would be helpful are but the tineiest fraction of the failures that occur. And any significant failure at all of such a redundant system is rare.
If you're a smaller organization, perhaps you'll only have a /23 from your upstream provider. With the filtering that seems to be in place, it seems like the only way you can truly multihome with a /23 is if it happens to be in the old Class C space. Or is this wrong?
You're just biasing the question with the choice of words you use ... "truly" multihome.
What seems to be needed is perhaps a /8 set aside by the RIR specifically to allocate to small organizations that wish to multihome that people would accept /24 and shorter from.
Not only would this increase the size of the global routing table, but this would actually decrease reliability for most basement multihomers. Basement multihomers tend to flap their routes more often than their upstreams. By not being inside a larger aggregate, these flaps are likely to result in more significant pockets of unreachability than they would be otherwise. DS
Well, you can't easily multihome when announcing /23 or shorter but /24 will work fine for multihoming and that is why ARIN passed that policy. What is true, however, is that some isps will filter even /24s on their router, but in that case, there would still be a route to your netblock from your upstream (they would be announcing their entire /19, /18 or whatever with you as a customer getting /24 of that larger block and if your direct route is filtered by an isp, next larger route that includes your block that is not filtered would be used). And there are actually not that many isps that really do filter /24 announcements (I'd say 1% but I maybe wrong). However that some ISPs do filter /24s, would mean that if RIR is directly giving your an ip block it would need to be from the block where ISPs know that RIR is giving out small blocks. Up until now ARIN has not been giving any new small (/24 - /21) allocations, except micro allocations for exchange points and in the micro-allocations (policy 2001-3) it is specifically written that ARIN will do these kind of allocations from specific blocks reserved for that purpose. Now, however, that ARIN is discussing proposals such as 2002-5, 2002-6 and 2002-7 (with 2002-5 & 2002-6 most likely being passed within few months) ARIN maybe put in position of assigning smaller then /20 blocks and that is why I suggested on ARIN ppml mailing list that current micro-allocation wording about assiging small blocks from specifically designated larger blocks be made a separate policy that would apply to all small allocations & asignments being made directly by ARIN. If you think its a good idea to make this a policy, please do send your feedback to ARIN or bring it up on ppml mailing list and then ARIN can work on this futher to make it a policy. On Tue, 10 Dec 2002, Forrest wrote:
I was also curious about this - if I am a customer who wants to multihome and can justify only a /24, I would go to an ISP which has an allocation from the Class C space rather than one from the Class A space.
It doesn't matter. For all practical purposes, basement multihomers only care that their two or three providers have their route.
Maybe I'm missing something, but what good would it do for someone to multihome if only their own providers accept their route, but nobody else does? I realize that their block should be still announced with their ISP's larger aggregate, but what good does this do if your ISP goes down and can't announce the large aggregate.
If you're a smaller organization, perhaps you'll only have a /23 from your upstream provider. With the filtering that seems to be in place, it seems like the only way you can truly multihome with a /23 is if it happens to be in the old Class C space. Or is this wrong?
What seems to be needed is perhaps a /8 set aside by the RIR specifically to allocate to small organizations that wish to multihome that people would accept /24 and shorter from.
Forrest
participants (5)
-
David Schwartz -
Forrest -
Harsha Narayan -
N -
william＠elan.net