Re: [c-nsp] reliability of ping to router physical-, sub- or loopback interface
While it would be nice if we didn't have to explain why simple explanations are inadaquite for complex systems, this is the real world. Simple explanations can cover 80-90 percent of the cases but there are always cases that cant be explained easily. If equipment is designed for optimal icmp handling, what are you willing to give up? Cisco does a prety good job of handling icmp in a timely fashon. I have seen other equipment that exibits hard to explain behavior. In particular, an Extreme Networks core switch that delayed icmp echo traffic for over 1000ms for a several second period every 5 minutes. And this was transit traffic not replies from the switch itself. It took a long time to convince management and other engineers that production traffic was unafected and we didn't have a BIG problem. When I get someone who is complaining about ping times, I like to ask for a traceroute. They usualy will come back and show me that hop x is slow. And as often as not, I get to ask them how can it be that they can get to hops after x faster than they can get to x? Light bulbs go on at this point. Granted I am usualy talking to someone with an IT background and users at the end of a DSL or cable circuit are a different matter. From: Brian Dantzig Senior Network Engineer Medline Industries, Inc. -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of John Elliot Sent: Wednesday, August 24, 2011 5:58 AM To: benny+use...@amorsen.dk; sth...@nethelp.no Cc: cisco-nsp Subject: Re: [c-nsp] reliability of ping to router physical-, sub- or loopback interface Latency tests are often useful for debugging, and ping is an easy-to-use and widely available tool for latency testing. Having to start an incoming support call by explaining why a high varying latency as measured by ping does not actually mean that something is wrong easily wastes a couple of minutes. Even worse if that was the only problem the customer had. So please, router vendors, make ICMP ECHO fast and reliable. Ideal world yes, ping is a useful tool for latency testing, but it is unfortunately abused...hardly ideal to give icmp a priority for packets destined TO router...far more important roles for a router to do than prioritize an icmp flood to a local int. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] does duplex mismatch affect UDP throughput?
On Tue, Aug 02, 2011 Scott Granadose wrote: Nowadays, more vendors have problems with hard settings not quite working (because that code doesn't get tested so well, I'd assume) than in the last century. The notable exception being the Cisco 7200 (single-port) FastEthernet modules (PA and IO-board). Those can not do autoneg at all, and need their counterpart to be hard set. Vendor problems aside, the problems with hard setting is not so much things not working as set up (that usually works) but things get replaced. So, for example, a device breaks, gets replaced by a new one, and the person doing the replacement forgets to set the ethernet port to hard set. Been there, seen that, and *these* problems are much more frequent these days than just set all ends to autoneg. Carriers probably stick with fixed duplex as a legacy issue. Auto negotiation used to be somewhat iffy. Sun in particular had problems with it in the past. While I've not had problems with Sun for about 8-10 years. Once this gets baked into your network, it's hard to get rid of. It also eliminates the possability of a negtiation issue. If both sides are auto, there is a chance it won't work right. If both are full, it works. You might call this determinalistic provisioning. A good thing to remember is that if you are auto-negotiating, and your side comes up half-duplex, the other side is probably full-duplex no auto-negotiate. Yes, you could be connected to some odd equipment that is actualy running half but, 9 out of 10 times it's configured full-no-auto. Brian Dantzig ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
