FW: /8s and filtering

Mailman List Mirror (Read Only)
1

>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

2

Hello,
  I had the same questions. Could someone please answer these?

Harsha.

3

comments inline

>
> >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.

4

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

5

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

6

Hello,
  Now I am confused because I have got two sets of contradicting answers.
Some say that anyone can multihome, some say that you need to be of a
certain minimum size to multihome. May I know what is the right answer?

  I agree that allowing anyone to multihome would increase the size of the
routing table. So does this mean that someone has to be of a certain size
to multihome?

Harsha.

7

Now I am confused because I have got two sets of contradicting answers.

  Because there are two questions, one about provider independent space and
one about space allocated by an ISP to its customer.

Some say that anyone can multihome, some say that you need to be of a
certain minimum size to multihome. May I know what is the right answer?

  Anyone can multihome. There is no size requirement (except perhaps of your
budget).

I agree that allowing anyone to multihome would increase the size of the
routing table. So does this mean that someone has to be of a certain size
to multihome?

  No, because multihoming does not require that anyone but your direct
providers see your route. Since you pay them, you aren't imposing any costs
on anyone else.

  The people you don't pay can choose to accept your small route or not.
Either way, you can reach them and they can reach you. Their route to you may
not be optimum, but that's their choice. If you want them to hear your route,
you can pay them to do so. It will work either way.

  To repeat:

  1) Small multihomers should get IP address space from their most reliable
provider. This is the one they trust the most and intend to remain with the
longest.

  2) Small multihomers must get the ISP that assigns them address space to
allocate them at least a /24 (with multihoming as the justification if
needed). The ISP must agree to allow them to advertise their allocation
through other providers and must agree to hear and announce the block from
the customer *and* *other* *ISPs*.

  3) The ISP that assigns you IPs must prefer the more specific route from
their peers if they don't hear it directly from the multihomer.

  4) Small multhomers must get their other provider(s) to agree to hear their
announcement and readvertise it.

  5) Multihoming should be done only by those reasonably competent and
experienced. You probably can't get enough help from a mailing list and may
wind up signing contracts or purchasing equipment that harms you.

  DS

8

  2) Small multihomers must get the ISP that assigns them address space to
allocate them at least a /24 (with multihoming as the justification if
needed). The ISP must agree to allow them to advertise their allocation
through other providers and must agree to hear and announce the block from
the customer *and* *other* *ISPs*.

Hello,
Doesn't this mean that unless filtering policies change, after Class C
space is used up, the multihomer will have to get a /22 from the ISP
(since after Class C gets used up allocations will be made from Class A
space). There are only three /8s left in the Class C space.

Harsha.

9

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.

10

To be accepted into Verio's space per the URL that
forrest@almighty.c64.org pasted... you are correct. I still think this
is a rare method of filtering... and perhaps Verio will change their
policy to be /24 everywhere once the Classfull C ranges are gone. As
others have mentioned... not all providers filter in the same way, and
sometimes the methods are not published..... Its relatively safe to
make a *vague* judgement that a /24 will get you reachable via *most* of
the net.

11

No. Providers who you don't pay to carry your route can reach you through
the larger aggregate. In fact, even the /24 requirement can be ignored if all
your providers reach each other directly or can convince their transit
providers to carry smaller routes.

  DS

12

Have any of the major players ever tried cleaning up in the basement
multihoming market? It seems to me that a pair of well positioned
regional ISPs could easily share an aggregate, use it exclusively for
multihomers thus alleviating the strain on the global routing table
while giving their customers good visibility in the routing table.

Tim