North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Alternative to NetFlow for Measuring Traffic flows
> > > 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. > > --
|