[32900] in North American Network Operators' Group
Re: Filtering levels (was RE: multi-homing without the BGP (was
daemon@ATHENA.MIT.EDU (Daniel L. Golding)
Sun Dec 17 11:49:08 2000
Date: Sun, 17 Dec 2000 11:46:45 -0500 (EST)
From: "Daniel L. Golding" <dan@netrail.net>
To: Travis Pugh <tpugh@shore.net>
Cc: nanog@rmrf.net, Jonathan Disher <jdisher@eng.bamboo.com>,
nanog@merit.edu
In-Reply-To: <Pine.GSO.4.21.0012171022480.6152-100000@cider.ecosoft.com>
Message-ID: <Pine.BSF.4.21.0012171142480.24270-100000@courier.netrail.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Errors-To: owner-nanog-outgoing@merit.edu
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
> >
> >
>
