On Fri, 15 Dec 2000, Daniel Golding wrote:

advertise blocks smaller than a /20 to each other (/24 is a more normal filtering level these days). Also ensure that whichever of the upstreams

Is it safe to assume[*] that an announced /23 will not be filtered by any major (or even the minor) backbones? We just got our ARIN allocation (and I won't go into that, the lag time was all my fault), and I'm currently planning allocation for some remote offices and a couple of hosted buildouts. I'm hoping to not have to announce anything larger than a /23 from any one site unless necessary. -j [*] - It's never safe to assume anything internet related; relatively speaking, is it safe... -Jonathan Disher -Systems and Network Engineer, Web Operations -Internet Pictures Corporation, Palo Alto, CA -[v] (650) 388-0497 | [p] (877) 446-9311 | [e] jdisher@eng.ipix.com

Depends on what class it's in. Let me explain further. Verio, in their infinite wisdom, has decided that they are going to throw CIDR right out the window. We own 64.240.0.0-64.242.255.255. We advertise MANY smaller blocks of this space obviously, and what we have found is that in that space (since it is "Class A" space, remember we don't know what CIDR is since we're Verio) is that Verio does not accept anything smaller than a /20. Now many of our customers run BGP with us and advertise a /24 only, I guess they're SOL as far as Verio is concerned (actually if it's our space they're probably going to see the larger aggregate as well, so it's not as big of a deal, but still mighty annoying). Oh, and did I mention that Verio isn't even one of our peers? Oh well. On Fri, 15 Dec 2000, Jonathan Disher wrote:

On Fri, 15 Dec 2000, Daniel Golding wrote:

...

advertise blocks smaller than a /20 to each other (/24 is a more normal filtering level these days). Also ensure that whichever of the upstreams

Is it safe to assume[*] that an announced /23 will not be filtered by any major (or even the minor) backbones? We just got our ARIN allocation (and I won't go into that, the lag time was all my fault), and I'm currently planning allocation for some remote offices and a couple of hosted buildouts. I'm hoping to not have to announce anything larger than a /23 from any one site unless necessary.

-j

[*] - It's never safe to assume anything internet related; relatively speaking, is it safe...

-Jonathan Disher -Systems and Network Engineer, Web Operations -Internet Pictures Corporation, Palo Alto, CA -[v] (650) 388-0497 | [p] (877) 446-9311 | [e] jdisher@eng.ipix.com

Travis, By doing a summary-only aggregate, you can lose routing information that your downstreams want seen by the global internet. A good example of this is prepending. If I only advertise a /14, then supress a /24 that is subordinate to that block, I may fail to advertise a prepend upon that /24 block. Paying customer don't like stuff like that. BTW, ARIN is pretty clear that it's allocation policies are NOT intended for use as filtering criteria. Most folks seem to get along fine, filtering at the /24 level. It's not like most core routers at large ISPs are 7500s with 64mb anymore. - Daniel Golding On Sun, 17 Dec 2000, Travis Pugh wrote:

On Sun, 17 Dec 2000 nanog@rmrf.net wrote:

...

Depends on what class it's in. Let me explain further. Verio, in their infinite wisdom, has decided that they are going to throw CIDR right out the window. We own 64.240.0.0-64.242.255.255. We advertise MANY smaller blocks of this space obviously, and what we have found is that in that space (since it is "Class A" space, remember we don't know what CIDR is since we're Verio) is that Verio does not accept anything smaller than a /20. Now many of our customers run BGP with us and advertise a /24 only, I guess they're SOL as far as Verio is concerned (actually if it's our space they're probably going to see the larger aggregate as well, so it's not as big of a deal, but still mighty annoying). Oh, and did I mention that Verio isn't even one of our peers? Oh well.

Maybe if you aggregated your announcements instead of feeding a /14 to us as /22, /23, and /24 blocks, it wouldn't be necessary to do minimum-allocation filtering.

-travis

Travis, I think the way to fix this is to use non-summary aggregates in combination with reasonable prefix limit filters - nothing smaller than /24. This is a fair combination of cutting down on extraneous route advertisements, and preserving customer route informations. I certainly agree that advertising /30s to peers is unacceptable. How does it go? "Be liberal in what you accept, be conservative in what you advertise". - Daniel Golding On Sun, 17 Dec 2000, Travis Pugh wrote:

Hi Daniel.

You're entirely correct, in the case of a multihomed customer who needs routing information propagated. However, I differentiate between wholesale deaggregation and an ISP that takes care of multihomed customers' needs.

To me, there's a believability factor in people claiming that they do large-scale deaggs for their customers. Part of that believability is doing due diligence on what they announce, and part of it is doing due diligence on what their customers announce. It doesn't appear that any of that has been done here, which makes me skeptical. A bunch of /25 and greater adverts from 6347, and a bunch of /30s from customer ASNs, won't convince me that anyone needs to relax their filters any time soon.

Some snippets from nitrous:

*>i64.240.169.224/27 209.44.160.105 4294967294 100 0 6347 i *>i64.241.182.128/25 209.83.160.22 4294967294 100 0 6347 i *>i64.242.80.0/27 209.44.160.105 4294967294 100 0 6347 i *>i209.44.23.160/28 64.241.88.17 4294967294 100 0 6347 i *>i209.83.163.128/26 209.83.160.22 4294967294 100 0 6347 i *>i209.83.182.208/28 209.83.160.22 4294967294 100 0 6347 i *>i209.102.112.4/30 209.44.160.105 4294967294 100 0 6347 15131 ? *>i209.102.112.8/30 209.44.160.105 4294967294 100 0 6347 15131 ? *>i209.102.112.208/28 209.44.160.105 4294967294 100 0 6347 15131 ? *>i209.102.112.232/30 209.44.160.105 4294967294 100 0 6347 15131 ? *>i209.102.112.240/30 209.44.160.105 4294967294 100 0 6347 15131 ? *>i209.102.112.244/30 209.44.160.105 4294967294 100 0 6347 15131 ? *>i209.102.112.248/30 209.44.160.105 4294967294 100 0 6347 15131 ? *>i209.102.118.8/30 209.44.160.105 4294967294 100 0 6347 15131 ? *>i209.102.118.12/30 209.44.160.105 4294967294 100 0 6347 15131 ? *>i209.102.118.16/29 209.44.160.105 4294967294 100 0 6347 15131 ? *>i209.102.118.24/29 209.44.160.105 4294967294 100 0 6347 15131 ? *>i209.102.118.32/28 209.44.160.105 4294967294 100 0 6347 15131 ? *>i209.102.118.48/28 209.44.160.105 4294967294 100 0 6347 15131 ? *>i209.126.143.192/27 209.44.160.105 4294967294 100 0 6347 i *>i209.144.220.128/25 209.44.160.105 4294967294 100 0 6347 i *>i209.223.197.128/27 209.83.160.22 4294967294 100 0 6347 i *>i209.242.13.152/29 64.241.88.17 4294967294 100 0 6347 10692 13950 i *>i209.242.13.204/30 64.241.88.17 4294967294 100 0 6347 10692 13950 i *>i209.242.13.212/30 64.241.88.17 4294967294 100 0 6347 10692 13950 i *>i209.242.13.216/30 64.241.88.17 4294967294 100 0 6347 10692 13950 ? *>i209.242.13.220/30 64.241.88.17 4294967294 100 0 6347 10692 13950 ?

On Sun, 17 Dec 2000, Daniel L. Golding wrote:

...

Travis,

By doing a summary-only aggregate, you can lose routing information that your downstreams want seen by the global internet. A good example of this is prepending. If I only advertise a /14, then supress a /24 that is subordinate to that block, I may fail to advertise a prepend upon that /24 block. Paying customer don't like stuff like that.

BTW, ARIN is pretty clear that it's allocation policies are NOT intended for use as filtering criteria. Most folks seem to get along fine, filtering at the /24 level. It's not like most core routers at large ISPs are 7500s with 64mb anymore.

- Daniel Golding