[54214] in North American Network Operators' Group
Re: Alternative to NetFlow for Measuring Traffic flows
daemon@ATHENA.MIT.EDU (Richard A Steenbergen)
Tue Dec 17 01:20:08 2002
Date: Tue, 17 Dec 2002 01:19:18 -0500
From: Richard A Steenbergen <ras@e-gerbil.net>
To: alex@yuriev.com
Cc: "K. Scott Bethke" <kbethke@thruport.com>, nanog@merit.edu
In-Reply-To: <Pine.LNX.4.10.10212162339220.11994-100000@s1.yuriev.com>
Errors-To: owner-nanog-outgoing@merit.edu
On Mon, Dec 16, 2002 at 11:41:12PM -0500, alex@yuriev.com wrote:
>
> > Also, that method has the same "knowing the routes" problem as netflow.
> > Whereever you are getting your list of ASN's route ASN.*"'s routes, there
> > is pretty much no way they are accurate (for an ASN of ANY size).
>
> The vast majority of the routes will be an intersection of routes
> announced by the AS to other AS (including looking glasses).
Assume you are provider A, and you are considering peering with provider
B. Assume Provider B has customer Z, who buys transit from Provider B and
Provider C. Assume you already peer with provider C.
You have no way to know if customer Z will be part of your routes to
Provider B, or if you will prefer them over provider C, without having the
route list.
This is a very common situation if you have any decent amount of peering,
and/or if you are considering peering with a provider who has any
reasonable number of multihomed customers. As we've already proved in
previous nanog emails, the top 20 route-announcing providers added
together have enough routes to cover the internet around 8 times over.
Even looking glasses may not contain all the paths available.
Projecting actual IP traffic onto actual IP routes is the only way to do
it.
--
Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
