[27839] in North American Network Operators' Group
Re: mysterious packet delay to/from www.caida.org was: Cisco
daemon@ATHENA.MIT.EDU (Kai Schlichting)
Thu Mar 16 10:37:31 2000
Message-Id: <4.2.2.20000316102152.02c50540@mail.speedus.net>
Date: Thu, 16 Mar 2000 10:32:58 -0500
To: <nanog@merit.edu>
From: Kai Schlichting <kai@pac-rim.net>
Cc: <info@caida.org>
In-Reply-To: <006801bf8ee7$3b6493e0$9c0361ca@iphone.cn.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Errors-To: owner-nanog-outgoing@merit.edu
The assymmetric path is similar enough for both IP spaces to discount
this possibility: no duplicate ACKs or packets are ever seen, removing
the possibility of ANY end-to-end loss. The fact that its 100% reproducable
and always gets stuck on the same packet furthers another suspicion:
Someone told me that broken reverse DNS may do such things on certain
servers: they start to throw out content, then suddenly block on
the reverse DNS lookup and stop the flow right in the middle. I
haven't been able to produce the problem with any other site so
far though. The site in question does have a DNS problem, which leads
me to the next set of questions:
Is a delegating nameserver (namely UUnet's) supposed to dish out
glue A RR records for the servers it delegates to ? (in the
"additional records" section of the answer)
If yes, does it do so only if root-nameservers have an A RR for such
a server (e.g. a registered nameserver) ?
Are delegations to servers that are NOT registered breaking RFCs and
thus 'illegal' ?
Will Networksolutions ever update name server registrations, again ?
Renaming doesn't work for me: the form processor complains about the
new server name not being registered. That's not the idea in a "rename" operation, really.
Thanks,
bye,Kai
At Wednesday 08:29 PM 3/15/00 , Yu Ning wrote:
>Hi,
>
>It's very interesting that i encountered this problem yesterday. If i'm
>not mistaken: you have different source address block which have different
>trace delay to the same external site? The huge jump of delay is up to
>the source address, not the host OS. Right ?
>
>So i think it may be the reason of asymmetric routing. In more detail,
>say we you have source addr. A, B, and external destination C. Your trace
>A->C has a larger delay than B->C . The reason is that the backward path from C->A
>is different than C->B (it's very possible, because you, or your upstream
>may advertise add block A, B differently), which has a larger delay.
>
>You can verify this in this way. Let's A, B trace to a same external
>traceroute server address (say net.yahoo.com, or others). You may
>find they have the same OUTBOUND path. But then trace back from the
>traceroute server to A, and B, i believe you will find the difference.
>
>hope this help, regards.
>
>Yu Ning
>
>
>--------------------------------------
>(Mr.) Yu Ning
>ChinaNet Operation Center
>Networking Dep.,Datacom Bureau
>China Telecom.,Beijing(100088),P.R.C
>+86-10-82078519/62359464/62367444(fax)
>--------------------------------------
