North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Initial Route Server Stats for MAE-East
I've only been to one IETF but wasn't the IPPM (IP porvider metric) group working on just such a problem? Basically attacking how we measure performance on an internet? Did the group come up with anything? I deal with people every day that *insist* that pinging a router (yes, we're talking Cisco's in this case) is "a good enough indication for me" that "your routers are dropping X% of my packets". Sometimes it turns out to be true and I find the problem. Many times, it's just not so. That begs the question: How do I determine whether or not I have packet loss or delay on my network (and be able to prove it beyond a reasonable doubt)? Does FTPing a 50M file across the network tell me? Does a 10,000 packet ping tell me? My point for interjecting here is to ask: Has anyone come up with *any* way to measure network performance (packet loss, throughput, delay) other than ping and traceroute? I understand Mike's comments on defining *what* we really want to measure and I'm all for trying to help define it. I ask these questions because I'd really like to find answers, not to stir the coals even more. -brett > by all means, ping all you like. please do realize that > routers have other things to do besides answer pings when > they're busy. just because a router doesn't respond to > 15% of its pings doesn't mean that it's dropping 15% of > its packets or that there is a 15% loss on a line. router > load is not router load, process switched packets are not > the same as card-level switched or cache switched. > > there aren't any easy answers. perhaps we should all just > implement "ping" servers in pops ( a 386 running > linux or bsd might suffice). > > Jeff Young > [email protected] > > > > > > > > > On Sat, 21 Oct 1995, Mike O'Dell wrote: > > > > > > > remember that using pings to sample connectivity to a very busy > > > > cisco router is not a very reliable probe for several reasons. > > > > Returning pings is a low-priority task in the first place, and > > > > they are rate-limited, so if the processor is busy processing > > > > lots of BGP updates and several folks are fribbling with it > > > > using ping or SNMP, it is less than clear what they will see. > > > > > > > > -mo > > > > > > > Michael A. Nasto quips: > > > > > OK! Agreed. So then, what would you use? > > > > > > > Have you ever been in a classroom and had a student raise his hand, > > answer every question, ask intelligent questions, etc. just to prove > > to the class how smart he or she is. This is the premise of > > the 'Two Mike's Interchange' above. One says, HEY! I know ping packets > > are a lower priority than everything else in a *CISCO* router > > LOOK AT ME (wave wave). Then another kid in the class quips... > > if PING is not what you would use, give us a better utility. > > > > In fact... EVERYONE ( okay 99.73 percent :-) uses PING. After all > > router LOAD is router LOAD.... and if a few ICMP packets can't get > > back in a subjectly reasonable time.. then DUH.... "da network > > is busy......" BGP updates take bandwidth just like any other packet. > > > > Of course the 0.27 percent, zen routing gods of the universe just > > feel the load and the harmonic BGP update patterns and PING between > > the BGP updates.... for a better answer. > > > > Sorry, I could not resist.... and apologize for the satire. PING!! > > PING!! PING!! > > > > Tim > > > > -- > > +--------------------------------------------------------------------------+ > > | Tim Bass | #include<campfire.h> | > > | Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | > > | The Silk Road Group, Ltd. | take_one_down(); | > > | | pass_it_around(); | > > | http://www.silkroad.com/ | } | > > | | back_to_work(); /*never reached */ | > > +--------------------------------------------------------------------------+ >
|