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