North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Filtering levels (was RE: multi-homing without the BGP (wasRE: Packet Loss))
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 > > > > >
|