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