Initial Route Server Stats for MAE-East
Brett D. Watson
bwatson at mci.net
Mon Oct 23 01:44:08 UTC 1995
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
> young at mci.net
>
> >
> > >
> > > 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 */ |
> > +--------------------------------------------------------------------------+
>
More information about the NANOG
mailing list