|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Possible explanations for a large hop in latency
They probably don't propagate TTL w/in their MPLS core. Depending on how they have MPLS implemented, you may only see 2 hops on the network; the ingress and egress routers. If the ingress router was in NYC and the egress in Seattle, you could understandably expect a large jump in RTT. Not an ATT customer but do know other providers run their MPLS core's this way... -Robert On Thu, Jun 26, 2008 at 6:09 PM, John T. Yocum <[email protected]> wrote: > The explanation I got, was that the latency seen at the first hop was > actually a reply from the last hop in the path across their MPLS network. > Hence, all the following hops had very similar latency. > > Personally, I thought it was rather strange for them to do that. And, I've > never seen that occur on any other network. > > Perhaps someone from ATT would like to chime in. > > --John > > > Frank Bulk - iNAME wrote: > >> Did that satisfy you? I guess with MPLS they could tag the traffic and >> send >> it around the country twice and I wouldn't see it at L3. >> >> Frank >> >> -----Original Message----- >> From: John T. Yocum [mailto:[email protected]] Sent: Thursday, June >> 26, 2008 7:04 PM >> To: [email protected] >> Cc: nanog list >> Subject: Re: Possible explanations for a large hop in latency >> >> When I asked ATT about the sudden latency jump I see in traceroutes, >> they told me it was due to how their MPLS network is setup. >> >> --John >> >> Frank Bulk wrote: >> >>> Our upstream provider has a connection to AT&T (12.88.71.13) where I >>> relatively consistently measure with a RTT of 15 msec, but the next hop >>> (12.122.112.22) comes in with a RTT of 85 msec. Unless AT&T is sending >>> >> that >> >>> traffic over a cable modem or to Europe and back, I can't see a reason >>> why >>> there is a consistent ~70 msec jump in RTT. Hops farther along the route >>> are just a few msec more each hop, so it doesn't appear that >>> 12.122.112.22 >>> has some kind of ICMP rate-limiting. >>> >>> Is this a real performance issue, or is there some logical explanation? >>> >>> Frank >>> >>> >>> >> >> > >
|