
That's an excellent question -- and one I've always wondered myself. This is purely speculative, but I believe outbound ICMP (e.g. sent from the router to whatever src solicited it) is what's de-prioritised. Someone more familiar with Cisco and Juniper equipment might know for certain. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | On Wed, Aug 19, 2009 at 09:55:40AM -0500, Frank Bulk - iName.com wrote:
Good point. Is the ICMP rate-limiting of these largish routers ingress and egress, or only ingress-only?
Frank
-----Original Message----- From: outages-bounces@outages.org [mailto:outages-bounces@outages.org] On Behalf Of Jeremy Chadwick Sent: Wednesday, August 19, 2009 12:21 AM To: outages@outages.org Subject: Re: [outages] Level3 Chicago
The closest thing I know of is PingPlotter for Windows.
I'll remind folks that TCP and UDP-based traceroute/mtr-like utilities still rely on ICMP time exceeded (type 11) being sent out to obtain the present path, so if folks are looking for a pure TCP or UDP-based traceroute or equivalent, to avoid dropping of ICMP, they're barking up the wrong tree. :-)
-- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |
On Tue, Aug 18, 2009 at 10:42:14PM -0500, Frank Bulk wrote:
Is there version of mtr that include support for TCP or UDP types? A google search didn't reveal anything to me, but would be the best of mtr with the benefits of tcptraceroute.
Frank
-----Original Message----- From: outages-bounces@outages.org [mailto:outages-bounces@outages.org] On Behalf Of Jeremy Chadwick Sent: Tuesday, August 18, 2009 12:50 PM To: outages@outages.org Subject: Re: [outages] Level3 Chicago
It would be helpful if you could use something like mtr instead of traceroute in this case. The below trace could be indicating ICMP de-prioritisation on L3 routers, which is known to be enabled, but could also be an indicator of packet loss starting at hop #5 and "trickling down" through succeeding hops (possibly #10 or #11).
mtr --order=LSRNABW can help in diagnosing this.
-- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |
On Tue, Aug 18, 2009 at 01:36:58PM -0400, Clayton Zekelman wrote:
Further to the issue below - I'm typically seeing packet loss at hop 5. This particular trace doesn't show it though, although there are timeouts on hop 6.
1 br0.win.mnsi.net (216.8.137.193) 0 msec 0 msec 0 msec 2 ge-6-12-222.car2.Detroit1.Level3.net (64.152.144.77) 0 msec 4 msec 0
msec
3 ae-11-11.car1.Detroit1.Level3.net (4.69.133.245) 4 msec 0 msec 4 msec 4 ae-8-8.ebr2.Chicago1.Level3.net (4.69.133.242) 8 msec 4 msec 16 msec 5 ae-5.ebr2.Chicago2.Level3.net (4.69.140.194) 8 msec 8 msec 8 msec 6 * * ae-2-2.ebr2.Washington1.Level3.net (4.69.132.70) 32 msec 7 ae-72-72.csw2.Washington1.Level3.net (4.69.134.150) 36 msec ae-82-82.csw3.Washington1.Level3.net (4.69.134.154) 36 msec ae-72-72.csw2.Washington1.Level3.net (4.69.134.150) 32 msec 8 ae-2-79.edge2.Washington4.Level3.net (4.68.17.83) 28 msec ae-3-89.edge2.Washington4.Level3.net (4.68.17.147) 40 msec ae-1-69.edge2.Washington4.Level3.net (4.68.17.19) 24 msec 9 savvis-level3-te.Washington1.Level3.net (4.68.110.102) 32 msec 28 msec 40 msec 10 * * * 11 cr1-bundle-pos1.NewYork.savvis.net (204.70.196.137) 28 msec * 28 msec 12 206.24.199.2 48 msec 32 msec 32 msec 13 toroonnldr01.bb.telus.com (154.11.6.71) 32 msec 192 msec 36 msec 14 host82.145.115.209.in-addr.arpa (209.115.145.82) 40 msec 40 msec 40 msec 15 209.202.116.58 40 msec 48 msec 36 msec 16 www.govital.net (209.202.88.24) 36 msec 40 msec 36 msec
At 01:05 PM 8/18/2009, Clayton Zekelman wrote:
I'm seeing some minor packet loss traversing Level3 in Chicago.
We connect to their network in Detroit, and we're clean until the first hop into Chicago.
Anyone else seeing anything like that?
--- Clayton Zekelman Managed Network Systems Inc. (MNSi) 344-300 Tecumseh Rd. E. Windsor, Ontario N8X 5E8
tel. 519-985-8410 fax. 519-985-8409
_______________________________________________ outages mailing list outages@outages.org https://puck.nether.net/mailman/listinfo/outages
No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.409 / Virus Database: 270.13.60/2311 - Release Date: 08/18/09 06:03:00
--- Clayton Zekelman Managed Network Systems Inc. (MNSi) 344-300 Tecumseh Rd. E. Windsor, Ontario N8X 5E8
tel. 519-985-8410 fax. 519-985-8409
_______________________________________________ outages mailing list outages@outages.org https://puck.nether.net/mailman/listinfo/outages
outages mailing list outages@outages.org https://puck.nether.net/mailman/listinfo/outages
outages mailing list outages@outages.org https://puck.nether.net/mailman/listinfo/outages