Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

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

  • From: Kai Schlichting
  • Date: Thu Mar 16 10:42:23 2000

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






Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.