From owner-freebsd-questions Sat Oct 13 21:37: 7 2001 Delivered-To: freebsd-questions@freebsd.org Received: from topaz.mdcc.cx (topaz.mdcc.cx [212.204.230.141]) by hub.freebsd.org (Postfix) with ESMTP id 55E4837B408 for ; Sat, 13 Oct 2001 21:37:02 -0700 (PDT) Received: from k7.mavetju.org (topaz.mdcc.cx [212.204.230.141]) by topaz.mdcc.cx (Postfix) with ESMTP id 153E52B697; Sun, 14 Oct 2001 06:36:55 +0200 (CEST) Received: by k7.mavetju.org (Postfix, from userid 1001) id D6F40E0; Sun, 14 Oct 2001 14:36:33 +1000 (EST) Date: Sun, 14 Oct 2001 14:36:33 +1000 From: Edwin Groothuis To: Chip Cc: freebsd-questions@FreeBSD.ORG Subject: Re: traceout oddity - can anyone explain this loop? Message-ID: <20011014143633.O2865@k7.mavetju.org> Mail-Followup-To: Edwin Groothuis , Chip , freebsd-questions@FreeBSD.ORG References: <01101319105213.96094@chip.wiegand.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <01101319105213.96094@chip.wiegand.org>; from chip@wiegand.org on Sat, Oct 13, 2001 at 07:10:52PM -0700 Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, Oct 13, 2001 at 07:10:52PM -0700, Chip wrote: > Here is the response of running traceroute to a router at my workplace, > notice the loop it was in starting at hop 13. I set the ttl up higher and > let it run, finally killed it at 75 hops, stuck in that loop. Any idea what > this loop means? Is it something I should be concerned about? (I think > probably so, but what to do about it?) > > 1 firewall (192.168.1.10) 0.548 ms 0.495 ms 0.437 ms > 2 pia152-1.pioneernet.net (66.114.152.1) 25.289 ms 25.510 ms 24.918 ms > 3 sea-gw.isomedia.com (207.115.64.129) 25.236 ms 26.040 ms 25.323 ms > 4 isomedia-gw.peer1.net (216.187.64.97) 25.712 ms 25.601 ms 25.234 ms > 5 500.serial1-11.gw7.sea1.alter.net (157.130.191.5) 25.957 ms 27.009 ms > 25.193 ms > 6 146.atm2-0.xr2.sea1.alter.net (152.63.105.182) 25.536 ms 26.145 ms > 26.213 ms > 7 0.so-0-0-0.xl2.sea1.alter.net (152.63.106.233) 26.180 ms 25.738 ms > 26.366 ms > 8 0.so-0-1-0.tl2.por3.alter.net (152.63.107.157) 30.913 ms 32.464 ms > 30.998 ms > 9 0.so-3-0-0.tl2.lax9.alter.net (152.63.0.166) 55.209 ms 53.563 ms > 53.028 ms > 10 so-1-0-0.xl2.lax2.alter.net (152.63.3.186) 55.045 ms 54.098 ms 53.750 > ms > 11 pos4-0.xr2.lax2.alter.net (152.63.115.230) 54.213 ms 53.845 ms 54.252 > ms > 12 194.atm6-0.gw3.lax2.alter.net (152.63.53.53) 54.191 ms 60.878 ms > 54.468 ms > 13 63.66.44.161 (63.66.44.161) 94.501 ms 101.446 ms 94.261 ms > 14 loopback0.gw3.lax2.alter.net (137.39.4.239) 92.190 ms 92.471 ms 93.983 > ms > 15 63.66.44.161 (63.66.44.161) 132.684 ms 134.368 ms 132.027 ms This behaviour often happens if there is a recent problem (less than 10 minutes) with the connectivity towards the remote subnet. At this moment 63.66.44.161 thinks that the remote subnet (which is unreachable) is reachable via loopback0.gw3.lax2.alter.net. loopback0.gw3.lax2.alter.net doesn't know the remote subnet anymore and sends it in this case to its default gateway, which is 63.66.44.161. That one says "Euh.... this remote subnet, I'll send it to loopback0.gw3.lax2.alter.net". And loopback0.gw3.lax2.alter.net sends it back to its default gateway. This goes on till the end of times or until the TTL of the packet has reached zero. You can't do anything about it, it's a networking problem (unless you're in the networking dept of that ISP) Edwin -- Edwin Groothuis | Personal website: http://www.MavEtJu.org edwin@mavetju.org | Interested in MUDs? Visit Fatal Dimensions: ------------------+ http://www.FatalDimensions.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message