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

  • From: Travis Pugh
  • Date: Sun Dec 17 10:41:02 2000

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