[c-nsp] identify reason for step like round trip time increasing

[Rodney Dunn]

It would take some heavy debugging with sniffers
to find out where and in what direction the
delay is introduced.

Search the archives but it's clear that pinging
to a router isn't the correct way to get
RTT measurements.  You should ping through the
devices to an endstation that is dedicated
to responding to pings.

Or use SAA for RTT calculations.

If you could time sync your sending device
and the router via NTP you could
do a "debug ip packet <acl>" and match
that up with a sniffer trace on the sending device
to see what direction the delay is.

Then you would have to sniff hop by hop
to find out where it's getting introduced. 

Rodney

 On Wed, Dec 22, 2004 at 07:32:07PM +0800, Joe Shen wrote:
> Hi,
> 
> We have a Linux server measuring responding speed to
> our Catalyst6509 switches. The server 'ping' 20 56Byte
> packets to Catalyst6509 every 20 seconds.
> 
> In past month, the RTT data graph show a step like
> increasing. That is, there is three steps on RTT
> graph. I checked CPU load on Catalyst6509 and found
> the CPU load is below 30%. 
> 
> As I configured "mls flow full"( but netflow
> collection is disabled) , someone said this should be
> the reason when traffic through that Catalyst6509
> increase abruptly ( we migrate some traffic from other
> path to path through this catalyst6509 this month).
> But, "set mls flow destionation" does not show any
> effect on RTT measurement.
> 
> Could anybody do some help ?
> 
> thanks.
> 
> Joe
> 
> 
> 
>  
> 
> _________________________________________________________
> Do You Yahoo!?
> ×¢²áÊÀ½çÒ»Á÷Æ·ÖʵÄÑÅ»¢Ãâ·ÑµçÓÊ
> http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/