Re: mysterious packet delay to/from www.caida.org was: Cisco Netflow Analysis Software

[Kai Schlichting]

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)
>--------------------------------------