[54217] in North American Network Operators' Group
Re: Alternative to NetFlow for Measuring Traffic flows
daemon@ATHENA.MIT.EDU (alex@yuriev.com)
Tue Dec 17 08:53:08 2002
Date: Tue, 17 Dec 2002 09:06:40 -0500 (EST)
From: alex@yuriev.com
To: Richard A Steenbergen <ras@e-gerbil.net>
Cc: "K. Scott Bethke" <kbethke@thruport.com>, nanog@merit.edu
In-Reply-To: <20021217061918.GA56949@overlord.e-gerbil.net>
Errors-To: owner-nanog-outgoing@merit.edu
> > > 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 standard problem resolved in the set theory. Pick your set.
Measure. Pick your set again, measure. Repeat N times. Decide which set of
results you accept as more likely. Use them.
Alex
>
> 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.
>
>
--
