On Jul 9, 20:31, "Daniel W. McRobb" <dwm@ans.net> wrote:
When I asked Cisco about this (a while ago), they said flow-switching incurred a 20% overhead (which someone there called "minimal", which I didn't agree with).
I guess this has changed; we have a clear performance improvement.
'tis very unwise to run IP accounting on a very busy router. We wouldn't dare turn it on for a core router w/ 40,000 routes. Some of our customers who have done so on border routers immediately turn arond and complain about performance problems. :-( And we're not talking
Yes, if the box doesn't have the CPU to do it, don't. But I said 'edge routers'. Core routers are the wrong places to do it anyway, depending on paradigm; but generally, traffic will be collected from and broken down into fairly small streams. It's only when it passes through core routers the proportions are too large; a 'border router' for a large network/customer is in this context a core router.
"fairly small" streams is only true if you don't have bandwidth-heavy customers. We have several customers w/ lots of bandwidth, who use it.
'tis also very important to know the route taken for a net when analyzing the data. Discrepancies here can be huge and completely invalidate any conclusions you might make about how much traffic is traversing a given path.
For this we like combined interface stats; AS-based traffic matrices are (from our point of view) mostly useful for end-to-end measurements.
traversing a given path. This is particularly true for busy end routers (like NAP peers) and core routers.
One wouldn't do it here anyway, as noted.
Then you potentially miss huge contributions to your network load (NAP routers <-> T3 customers, for example).
I also prefer measurements that won't potentially get dropped in transit (throwing a big unknown into confidence level of data). Is there an efficient means of retrieving flow data from a Cisco and not potentially dropping a bunch of it on the floor?
You may drop something from time to time, but this simply turns the data collection into sampling. With a sufficient sample size, this is as good as anything; you still want to correlate your information with other sources, such as interface stats, and adjust accordingly. But please, let us not turn this into "my box is better than your box".
I wasn't doing that. I asked an honest question. Dropping data at indeterminate points, unknown to the measurement tool, is not turning collection into sampling (well, at least not useful sampling). If you have no means of determining how many were dropped, and under what conditions, you have essentially useless data. Interface stats won't get you that information. If you drop traffic at times of heavy bursts you lose some of the most interesting data (that which may be causing your network real pain). Is there an efficient means of retrieving flow data from a Cisco and not potentially dropping a bunch of it on the floor? Will there be at some point in the future? We'd use it if it was available. We'd even pay for it, I imagine. :-) Daniel ~~~~~~
Is it just me, or are the ANS commandos after me? I don't think further discussion of ways of generating stats are terribly interesting. Needs are often defined in terms of available solutions, so you see a different need than I do. As for achieving some useful end result, several roads lead to Rome, or can be made to go there. The essential issue is not if knob X exists on box Y, but if there are enough knobs and instruments to let you do what you need. One thing we have found much more useful than AS traffic matrices (which I have to admit has a certain trivia feel about them, although I'm the one who made the stuff) is live, X-based line load monitoring (humm; I made that too): each "interesting" (for some value of interesting) line has several 20-minute histograms for salient interface information, updated every 10 seconds, on one of four monitors, right here behind me. Some years ago, with lower speed lines to small countries, we could even spot DNS loops; and it allowed us to detect CU-SeeMe traffic storms instantly, when that was a problem. As noted, busy core routers are ill suited for collecting IP accounting. The fact that they may be border routers in BGP terms doesn't make them any less core routers from a network perspective. So you just have to rig things differently, then. Other people have mentioned flow switching in Ciscos; and yes, we see 5-10% lower CPU as well. -- ------ ___ --- Per G. Bilse, Mgr Network Operations Ctr ----- / / / __ ___ _/_ ---- EUnet Communications Services B.V. ---- /--- / / / / /__/ / ----- Singel 540, 1017 AZ Amsterdam, NL --- /___ /__/ / / /__ / ------ tel: +31 20 6233803, fax: +31 20 6224657 --- ------- 24hr emergency number: +31 20 421 0865 --- Connecting Europe since 1982 --- http://www.EU.net e-mail: bilse@EU.net
Is it just me, or are the ANS commandos after me?
It's just you, really :-)
I don't think further discussion of ways of generating stats are terribly interesting. Needs are often defined in terms of available solutions, so you see a different need than I do.
That is in fact, the question. The ANS folks are curious about ways to generate stats, and because they've come from a position of having had a lot better stats than most of the rest of us, this is understandable. Further, they have a fair bit of experience on what can be done with a lot of data, and on interesting things to derive from that. It would behoove us NANOG participants to listen to what they have to say. There are really two discussions here that got merged together for a couple reasons, one being that of convenience: What to do about long term stats. What to do about short-term stats. The ping stuff is the short-term stats. It's certainly nice to be able to sample out packets when necessary, and can really help for tracking such things down. Others haven't mentioned it, but other ways to track down such flows (for those of us without wonderful instrumenting capabilities) include careful placement of host routes and/or tunnels to redirect traffic to points in the network where it can be more closely monitored, examination of IP ttls of such packets, etc., etc.
As for achieving some useful end result, several roads lead to Rome, or can be made to go there. The essential issue is not if knob X exists on box Y, but if there are enough knobs and instruments to let you do what you need.
It's true, but a discussion of what knobs HAVE EXISTED on boxes, and what knobs DO EXIST, and how to make those more standard across multiple vendors is a useful one, as long as it does not degenerate like it (almost) has.
One thing we have found much more useful than AS traffic matrices (which I have to admit has a certain trivia feel about them, although I'm the one who made the stuff) is live, X-based line load monitoring (humm; I made that too): each "interesting" (for some value of interesting) line has several 20-minute histograms for salient interface information, updated every 10 seconds, on one of four monitors, right here behind me.
This is the short-term, long-term issue. If you want to know who you exchange traffic with, who you need to consider peering with in more places or establishing additional links to, you need things like AS matrices. We certainly appreciate the modicum of data we have now, and would be happier with more of it. Knowing how hot each of your links is is nice, and may help you see short-term spikes, but it doesn't help long-term engineering of your network.
As noted, busy core routers are ill suited for collecting IP accounting. The fact that they may be border routers in BGP terms doesn't make them any less core routers from a network perspective. So you just have to rig things differently, then.
This is getting silly :-) It's relatively well-established that if you want to collect data somewhere, getting it right is going to be hard. The more you want to collect, the harder it is. Invariably it's useful to have stats on boxes at the borders of your network where you peer with other folks, and it's also useful inside your network. All of these things depend on what you're trying to engineer for, and almost all of them are useful. Balancing usefulness versus forwarding path performance is a tricky thing, but one should not assume it's impossible, and considering the possibilities is far more than a waste of time. --jhawk John Hawkinson
On Jul 10, 10:44, John Hawkinson <jhawk@bbnplanet.com> wrote:
Is it just me, or are the ANS commandos after me?
It's just you, really :-)
Good to hear. :-)
This is the short-term, long-term issue.
If you want to know who you exchange traffic with, who you need to consider peering with in more places or establishing additional links to, you need things like AS matrices. We certainly appreciate the modicum of data we have now, and would be happier with more of it.
Knowing how hot each of your links is is nice, and may help you see short-term spikes, but it doesn't help long-term engineering of your network.
Yes, but 'long-term' is one of these things ... You can't really project with any degree of accuracy more than 6-9 months ahead, and our experience indicates that historical data is not all that useful. (Ie, that is the case for us; it may be different for other people.) There aren't any agreed ways of measuring the capacity of networks, but my take on our capacity is that we have 100-150 times more capacity than three years ago. Ie, this is what we can extract from historical data; but there is a limit to how far into the future one can project, using this data, and it certainly isn't three years.
As noted, busy core routers are ill suited for collecting IP accounting. The fact that they may be border routers in BGP terms doesn't make them any less core routers from a network perspective. So you just have to rig things differently, then.
This is getting silly :-) It's relatively well-established that if you want to collect data somewhere, getting it right is going to be hard. The more you want to collect, the harder it is.
Yes, but my point is that bean-counting accuracy, "proof", hard facts, etc isn't particularly important. You want to look at trends for long-term planning, and current measurements to see if you should maybe reroute traffic over alternative connections, sort of "right now". Between those two extremes, a good nose and healthy gut is likely to be more useful than even the most careful analysis of historical data, simply because growth doesn't necessarily follow any particular pattern.
Invariably it's useful to have stats on boxes at the borders of your network where you peer with other folks, and it's also useful inside your network. All of these things depend on what you're trying to engineer for, and almost all of them are useful. Balancing usefulness versus forwarding path performance is a tricky thing, but one should not assume it's impossible, and considering the possibilities is far more than a waste of time.
Sure, nobody would disagree with that. -- ------ ___ --- Per G. Bilse, Mgr Network Operations Ctr ----- / / / __ ___ _/_ ---- EUnet Communications Services B.V. ---- /--- / / / / /__/ / ----- Singel 540, 1017 AZ Amsterdam, NL --- /___ /__/ / / /__ / ------ tel: +31 20 6233803, fax: +31 20 6224657 --- ------- 24hr emergency number: +31 20 421 0865 --- Connecting Europe since 1982 --- http://www.EU.net e-mail: bilse@EU.net
participants (3)
-
Daniel W. McRobb -
John Hawkinson -
Per Gregers Bilse