nanog mailing list archives
Re: NAP/ISP Saturation WAS: Re: Exchanges that matter...
From: Tony Li <tli () jnx com>
Date: Tue, 17 Dec 1996 00:52:47 -0800 (PST)
* ICMP packets are dropped by busy routers Many routers drop ICMP packets (ping, traceroute) when busy, or alternate dropping ICMP packets. I know that this behavior occurs when the packets are directed to the specific router, I am not sure if this every occurs for packets passing through. The standby tool ping needs a more reliable replacement for testing end to end packet loss. There seems to be a great deal of (understandable) confusion on this issue. Let's set it straight: Packets which are _successfully_ forwarded through a (high end) cisco router are not (by default) prioritized by protocol type. Packets which are not forwarded require more work and are effectively rate limited (and consume large amounts of CPU time). Some effects: - Pinging a cisco is not a valid measure of packet loss. It's closer to a CPU load measure than anything else. - Pinging _thru_ a cisco is reasonable. - Traceroute to a cisco is rate limited to one reply per second, so will almost always miss the middle reply. - Traceroute _thru_ a cisco may show many drops which would NOT be seen by normal "thru" traffic. Replies generated by the cisco when the TTL expires are again thru the CPU. So you may well traceroute thru a cisco which does not reply at all. However, you can clearly see the route after that router. * Head of queue blocking in the Gigaswitch Even though the Gigaswitch has input and output queues, your output queue will block until the other providers input queue is free. My (admittedly second hand) understanding is that the Gigaswitch/FDDI actually has minimal amounts of buffering. During a congestion event, it simply withholds the token, resulting in buffering in the routers. Queues there eventually overflow, and ... If this is incorrect, I would greatly appreciate pointers to the truth. Tony - - - - - - - - - - - - - - - - -
Current thread:
- Re: Exchanges that matter..., (continued)
- Re: Exchanges that matter... Nathan Stratton (Dec 07)
- Re: Exchanges that matter... Alec H. Peterson (Dec 08)
- Re: Exchanges that matter... Nathan Stratton (Dec 08)
- Re: Exchanges that matter... Jeremy Porter (Dec 08)
- Re: Exchanges that matter... Alec H. Peterson (Dec 08)
- NAP/ISP Saturation WAS: Re: Exchanges that matter... Forrest W. Christian (Dec 15)
- Re: NAP/ISP Saturation WAS: Re: Exchanges that matter... Mike Leber (Dec 16)
- Re: NAP/ISP Saturation WAS: Re: Exchanges that matter... dave o'leary (Dec 16)
- Re: NAP/ISP Saturation WAS: Re: Exchanges that matter... Dima Volodin (Dec 16)
- Re: NAP/ISP Saturation WAS: Re: Exchanges that matter... Craig Nordin (Dec 16)
- Re: NAP/ISP Saturation WAS: Re: Exchanges that matter... Tony Li (Dec 17)
- Re: NAP/ISP Saturation WAS: Re: Exchanges that matter... Dennis Ferguson (Dec 17)
- Re: NAP/ISP Saturation WAS: Re: Exchanges that matter... David Schwartz (Dec 17)
- Re: NAP/ISP Saturation WAS: Re: Exchanges that matter... Hank Nussbacher (Dec 17)
- Re: Exchanges that matter... Alex.Bligh (Dec 05)
- RE: Exchanges that matter... Deepak Jain (Dec 05)
- Building exchanges that matter .. Joe Rhett (Dec 07)
- Re: Exchanges that matter... Wayne Bouchard (Dec 05)