Re: Market for diversity (was: Re: Cogent latency / congestion)
On Sat, 25 Aug 2007, Andy Davidson wrote: Is it not possible to require that each of your suppliers provide over a specified path ? I'm planning a build-out that will require a diverse path between two points, and one supplier has named two routes, and promised that they wont change for the duration of the contract. Perhaps I am naive, but a promise should be a promise. Just naive. Most people make assumptions about what was promised. If it sounds too good to be true, it probably is. What the sales person promises, the fine print takes away. http://www.atis.org/ndai/ATIS_NDAI_Final_Report_2006.pdf You will find out no one will sell to you if the contract requires some things, and the alternatives are rather limited. I would be more concerned about suppliers that promise things that aren't possible than suppliers that decline to sell things that aren't possible. Unrealastic buyers are just as much of a problem as non-performance by sellers. If anyone promises their network will never do down, they will never have single paths, they are perfect; you should grab your wallet and run away.
Re: Market for diversity (was: Re: Cogent latency / congestion)
On Sat, 25 Aug 2007, Andy Davidson wrote: Is it not possible to require that each of your suppliers provide over a specified path ? I'm planning a build-out that will require a diverse path between two points, and one supplier has named two routes, and promised that they wont change for the duration of the contract. Perhaps I am naive, but a promise should be a promise. Note: IANAL, nor do I play one on TV. Spell out exactly what you want (read: make no assumptions about even the most mundane details) when talking to your account rep and go over the contract and accompanying schedules with a fine-toothed comb before you sign. You want to make sure all those details are spelled out the same way that you provided them to your salescritter and also check for legalese that gives the provider room to do things like re-groom your circuit/lamdba/whatever you're buying onto another (possibly convergent) path without your notification and consent. Even then, be prepared to take your provider(s) to task and perform due diligence on those physical routes on a regular basis. Note that getting this information in the first place may require you to execute a non- disclosure agreement. Check the wording of that agreement as well to make sure that it won't prevent you from a) performing future due diligence and b) seeking legal relief if a future round of due diligence shows that the terms of your contract have been breached. jms
Re: Market for diversity (was: Re: Cogent latency / congestion)
Hi, David, everyone -- On 21 Aug 2007, at 17:55, David Lesher wrote: And still not getting it. A friend oversees various expensive USG networks. They pay for physically diverse routing from multiple sources. Yet every year, when they do an laborious audit down to the "what fiber, in what bundle, in what trench" level; they find.. Guess What! Yep, someone has moved this circuit or that one to where both pipes are intimate neighbors. Is it not possible to require that each of your suppliers provide over a specified path ? I'm planning a build-out that will require a diverse path between two points, and one supplier has named two routes, and promised that they wont change for the duration of the contract. Perhaps I am naive, but a promise should be a promise. Also instead of buying path A from supplier X and path B from supplier Y, it might be worth buying paths A and B from supplier X and a spare path B from supplier Y too. Supplier X must know they only get dollar N because they can provide both paths.. and in addition diversity has to matter more than money because you are in effect paying for one path twice. Andy -a -- // http://www.andyd.net/
Re: Does anyone multihome anymore? (was: Re: Cogent latency / congestion)
At 03:49 AM 8/22/2007, Security Admin (NetSec) wrote: Pardon my forwardness, but don't people just multi-home these days? If your Multihoming is great for when there is a total outage. In the case of Cogent on Monday, it wasnt "down"... In this case, there is only so much you can do to influence how packets come back at you as BGP doesnt know anything about a "lossy" or slow connections. ---Mike
Does anyone multihome anymore? (was: Re: Cogent latency / congestion)
Pardon my forwardness, but don't people just multi-home these days? If your network connection is that mission critical, then having at least two providers would be prudent. Keep Cogent for el cheapo/variable latency connection, but have a reliable second and/or third source (i.e. Sprint, UUNET/Verizon). All of these issues have convinced me to multihome with Sprint as soon as my fiber-to-the-home-business is finished. Granted I still have a single point of failure with the single fiber into my cable co (which will allow me to multi-home with Sprint and cable co TWC, ASN 20001) but the crime rate in my area is MUCH lower in the last mile. Much less chance of gunfire taking it down. I am more worried about that critical path in Cleveland; hopefully Sprint and Level3/ATDN (TWC multihomed providers) keep their fiber buried more deeply in high crime/railroad areas... -- This mail was scanned by BitDefender For more informations please visit http://www.bitdefender.com
Re: Market for diversity (was: Re: Cogent latency / congestion)
It's inevitable given buying throughput is rather like moving something by ship. You never go to the ship [fiber] owner; you go to a freight broker who deals with a consolidator who calls an agent who knows who has chartered ships from A to B on DATE and This may also have something to do with the fact that carriers/fiber owners tend to play a slight game of schizophrenia with themselves. On the same cables they try to make wildly different levels of compensation (say: SONET voice traffic vs SONET data vs IP -- in decreasing order of value per bit) Then try to increase the marginal value of existing assets by increasing the total bit capacity (when we all know the highest value traffic grows at the slowest rate). So they sell of large chunks of capacity to brokers so they don't have to play channel wars (openly) with themselves. Then do anticompetitive things when those brokers themselves try to move up the value chain by selling data PL services at IP prices, etc. The telecom industry has not decided what the real value of its service(s) are. It knows what people will pay for a single connection and knows that its cost for failure to perform is only a fraction of what the engineering to "do it right" is. Simple economics. Want to see a telecom industry that sells protected services and MEANS they are protected? Want to see a telecom industry that doesn't have people mucking around fat-fingering XCs anymore? Try a 1 year SLA credit for service affecting outage on SONET services in your contract. If your carrier balks, offer to pay (additionally) whatever you think you'd pay for a truly protected service knowing you'll probably get the whole amount back if they don't provide it. Deepak
Re: Market for diversity (was: Re: Cogent latency / congestion)
On Aug 21, 2007, at 12:55 PM, David Lesher wrote: Speaking on Deep Background, the Press Secretary whispered: On Tue, 21 Aug 2007, Adrian Chadd wrote: Or there might suddenly be a reason/market for properly physically diverse paths which provide partial 1:1 (ie, some services are guaranteed full backup bandwidth, other services get degraded access) IP paths.. I don't think the target customer in this case is really in the market for properly physically diverse paths which provide partial 1:1. The target customer seems to be looking for no-frills, cheap Internet. Customers in a market for properly physically diverse paths with partial 1:1 probably are already buying Internet from other ISPs. And still not getting it. A friend oversees various expensive USG networks. They pay for physically diverse routing from multiple sources. Yet every year, when they do an laborious audit down to the "what fiber, in what bundle, in what trench" level; they find.. Guess What! Yep, someone has moved this circuit or that one to where both pipes are intimate neighbors. My rule is that you never really know where bits are actually going unless you put in the fiber yourself. (Of course, you can know where the bits _went_, once the backhoe or the train crash takes out your circuit, but by an extension of the quantum measurement theory, that only applies to the past, not the future.) It's inevitable given buying throughput is rather like moving something by ship. You never go to the ship [fiber] owner; you go to a freight broker who deals with a consolidator who calls an agent who knows who has chartered ships from A to B on DATE and [Look up the "GTS Katie" incident for a side effect of this.] Yes, and likewise you never know how your (literal) shipment is going until you get it. (Vienna, Austria, to Norfolk, Virginia, with a stage by truck from St Louis, Missouri ? Happened to me. They must have been using some sort of hot potato routing.) Totally OT, but it made me really happy to learn that Dulles Airport is officially a port, and I can literally send things by ship to IAD for customs clearance and pickup for the same price as to Norfolk, Virginia (an actual port, with docks and water and ships and all that). Of course, I don't have to care about their routing protocols or their last mile problems. Regards Marshall -- A host is a host from coast to [EMAIL PROTECTED] & no one will talk to a host that's close[v].(301) 56-LINUX Unless the host (that isn't close).pob 1433 is busy, hung or dead20915-1433
Re: Market for diversity (was: Re: Cogent latency / congestion)
Speaking on Deep Background, the Press Secretary whispered: > > > On Tue, 21 Aug 2007, Adrian Chadd wrote: > > Or there might suddenly be a reason/market for properly physically diverse > > paths which provide partial 1:1 (ie, some services are guaranteed full > > backup > > bandwidth, other services get degraded access) IP paths.. > > I don't think the target customer in this case is really in the market > for properly physically diverse paths which provide partial 1:1. The > target customer seems to be looking for no-frills, cheap Internet. > > Customers in a market for properly physically diverse paths with partial > 1:1 probably are already buying Internet from other ISPs. And still not getting it. A friend oversees various expensive USG networks. They pay for physically diverse routing from multiple sources. Yet every year, when they do an laborious audit down to the "what fiber, in what bundle, in what trench" level; they find.. Guess What! Yep, someone has moved this circuit or that one to where both pipes are intimate neighbors. It's inevitable given buying throughput is rather like moving something by ship. You never go to the ship [fiber] owner; you go to a freight broker who deals with a consolidator who calls an agent who knows who has chartered ships from A to B on DATE and [Look up the "GTS Katie" incident for a side effect of this.] -- A host is a host from coast to [EMAIL PROTECTED] & no one will talk to a host that's close[v].(301) 56-LINUX Unless the host (that isn't close).pob 1433 is busy, hung or dead20915-1433
Re: Cogent latency / congestion
At 05:43 PM 8/20/2007, Steve Gibbard wrote: On Mon, 20 Aug 2007, Mike Tancsa wrote: Bell uses Cogent in a large way. The second traceroute was from an IP in their AS (577) out. I am prepending out Cogent, but Bell does everything it can not to use Teleglobe so I am having problems influencing their routes to come back that way. They also have a very odd path out of Chicago. This is Bear in mind that doing "everything they can not to use Teleglobe" probably involves local preference. Local preference comes before AS path length in the BGP selection order, so nothing you can do with prepending is going to help. Yes, I realize that. I think its because they (Bell) pay Teleglobe for transit, so they dont want to use it where possible. Back when I signed up with Teleglobe, I was hoping there were some community tricks I could use to influence bell's local pref, but because they buy transit from Teleglobe, this was not implemented. I think the only thing I could do would be to withdraw the prefixes from Cogent or resort to deaggregation so that they would follow a more specific prefix. ---Mike You'll need to either keep them from seeing the undesirable path at all (drop the announcement, ask your upstreams to limit its propagation, etc.) or convince Bell not to use it. Depending on the setup, you may be able to limit route propagation with communities, or it may require some phone calls. -Steve
Re: Cogent latency / congestion
I see Cogent has updated their page - so we think this cut is fixed now? Eric Spaeth wrote: This appears to be affecting Telia as well. Here was their last update: "Concerning the cable break near Cleveland we have been informed that the cables have been intentionally sabotaged. The provider informed that they need to change the whole damaged fibre part and that is 3600 feet. Fibre has been ordered and ETA is 1900 UTC. Once the fibre arrives they need to blow it into the 3600 feet long duct before the splicing can start." -Eric
Re: Cogent latency / congestion
Deepak Jain wrote: That said, Cogent's page says nothing about sabotage (status.cogentco.com) and I can't find the reference on teliasonera's page Link please? The updates I received from Telia have only been verbal, but they indicated that an entire span of fiber would need to be replaced and that the segment could not be spliced (they didn't say "sabotage"). The quote I included earlier was from wcix.net rep Dennis Nugent's post in this thread: http://www.webhostingtalk.com/showthread.php?t=629335 I figured it would be better to include his written updates from Telia instead of paraphrasing my conversations with our account team. -Eric
Re: Cogent latency / congestion
> Date: Mon, 20 Aug 2007 19:17:21 -0400 > From: Deepak Jain <[EMAIL PROTECTED]> > > > If someone sabotages a rail to stop a train and the derailment takes out > > the fiber that is buried in the right-of-way, is that unintentional > > sabotage? At least of the fiber? > > That's not sabotage at all. > > As it relates to the fiber, its not "deliberately and maliciously > destroying [fiber]"... unless the goal was to cause a derailment which > hurt the train operator both from the operation of the train and > subsequent revenues they might lose from fiber operations along the same > right-of-way -- then *that* would be sabotage. > > In the case you outlined above, barring other motivations, the fiber > would be "collateral damage". > > That said, Cogent's page says nothing about sabotage > (status.cogentco.com) and I can't find the reference on teliasonera's > page Link please? Too many people missed the emoticon. Clearly the fiber damage in the case I gave was collateral damage. It would have been sabotage on the rail line and the derailed train. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgpjiM6O6M2m6.pgp Description: PGP signature
Re: Cogent latency / congestion
If someone sabotages a rail to stop a train and the derailment takes out the fiber that is buried in the right-of-way, is that unintentional sabotage? At least of the fiber? That's not sabotage at all. As it relates to the fiber, its not "deliberately and maliciously destroying [fiber]"... unless the goal was to cause a derailment which hurt the train operator both from the operation of the train and subsequent revenues they might lose from fiber operations along the same right-of-way -- then *that* would be sabotage. In the case you outlined above, barring other motivations, the fiber would be "collateral damage". That said, Cogent's page says nothing about sabotage (status.cogentco.com) and I can't find the reference on teliasonera's page Link please? DJ
Re: Cogent latency / congestion
On Mon, 20 Aug 2007, Deepak Jain wrote: Sounds like a DHS/FBI investigation will be starting soon. Eesh.. if we start having to secure 500,000 route miles of fiber routes against sabotage, um... well, I guess I'll have to become a fiber installation contractor. :) That and carriers will have to stop value-engineering route diversity out of their networks. jms
Re: Cogent latency / congestion
> Date: Mon, 20 Aug 2007 23:25:12 +0100 > From: "Rod Beck" <[EMAIL PROTECTED]> > Sender: [EMAIL PROTECTED] > > As opposed to 'unintentionally sabotaged'? I think there is some > redundancy there ... > > Sorry for the cheap shot, it was just too tempting. > > Roderick S. Beck > Director of EMEA Sales > Hibernia Atlantic > 1, Passage du Chantier, 75012 Paris > http://www.hiberniaatlantic.com > Wireless: 1-212-444-8829. > Landline: 33-1-4346-3209 > AOL Messenger: GlobalBandwidth > [EMAIL PROTECTED] > [EMAIL PROTECTED] > ``Unthinking respect for authority is the greatest enemy of truth.'' > Albert Einstein. If someone sabotages a rail to stop a train and the derailment takes out the fiber that is buried in the right-of-way, is that unintentional sabotage? At least of the fiber? Just asking...;-} -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgpleOpSBYckl.pgp Description: PGP signature
Re: Cogent latency / congestion
Eric Spaeth wrote: This appears to be affecting Telia as well. Here was their last update: "Concerning the cable break near Cleveland we have been informed that the cables have been intentionally sabotaged. The provider informed that they need to change the whole damaged fibre part and that is 3600 feet. Fibre has been ordered and ETA is 1900 UTC. Once the fibre arrives they need to blow it into the 3600 feet long duct before the splicing can start." Sounds like a DHS/FBI investigation will be starting soon. Eesh.. if we start having to secure 500,000 route miles of fiber routes against sabotage, um... well, I guess I'll have to become a fiber installation contractor. :) DJ
RE: Cogent latency / congestion
As opposed to 'unintentionally sabotaged'? I think there is some redundancy there ... Sorry for the cheap shot, it was just too tempting. Roderick S. Beck Director of EMEA Sales Hibernia Atlantic 1, Passage du Chantier, 75012 Paris http://www.hiberniaatlantic.com Wireless: 1-212-444-8829. Landline: 33-1-4346-3209 AOL Messenger: GlobalBandwidth [EMAIL PROTECTED] [EMAIL PROTECTED] ``Unthinking respect for authority is the greatest enemy of truth.'' Albert Einstein. -Original Message- From: [EMAIL PROTECTED] on behalf of Eric Spaeth Sent: Mon 8/20/2007 11:06 PM To: nanog@merit.edu Subject: Re: Cogent latency / congestion This appears to be affecting Telia as well. Here was their last update: "Concerning the cable break near Cleveland we have been informed that the cables have been intentionally sabotaged. The provider informed that they need to change the whole damaged fibre part and that is 3600 feet. Fibre has been ordered and ETA is 1900 UTC. Once the fibre arrives they need to blow it into the 3600 feet long duct before the splicing can start." -Eric This e-mail and any attachments thereto is intended only for use by the addressee(s) named herein and may be proprietary and/or legally privileged. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this email, and any attachments thereto, without the prior written permission of the sender is strictly prohibited. If you receive this e-mail in error, please immediately telephone or e-mail the sender and permanently delete the original copy and any copy of this e-mail, and any printout thereof. All documents, contracts or agreements referred or attached to this e-mail are SUBJECT TO CONTRACT. The contents of an attachment to this e-mail may contain software viruses that could damage your own computer system. While Hibernia Atlantic has taken every reasonable precaution to minimize this risk, we cannot accept liability for any damage that you sustain as a result of software viruses. You should carry out your own virus checks before opening any attachment
Re: Cogent latency / congestion
This appears to be affecting Telia as well. Here was their last update: "Concerning the cable break near Cleveland we have been informed that the cables have been intentionally sabotaged. The provider informed that they need to change the whole damaged fibre part and that is 3600 feet. Fibre has been ordered and ETA is 1900 UTC. Once the fibre arrives they need to blow it into the 3600 feet long duct before the splicing can start." -Eric
Re: Cogent latency / congestion
On Mon, 20 Aug 2007, Mike Tancsa wrote: Bell uses Cogent in a large way. The second traceroute was from an IP in their AS (577) out. I am prepending out Cogent, but Bell does everything it can not to use Teleglobe so I am having problems influencing their routes to come back that way. They also have a very odd path out of Chicago. This is Bear in mind that doing "everything they can not to use Teleglobe" probably involves local preference. Local preference comes before AS path length in the BGP selection order, so nothing you can do with prepending is going to help. You'll need to either keep them from seeing the undesirable path at all (drop the announcement, ask your upstreams to limit its propagation, etc.) or convince Bell not to use it. Depending on the setup, you may be able to limit route propagation with communities, or it may require some phone calls. -Steve
Re: Cogent latency / congestion
> Date: Mon, 20 Aug 2007 16:11:44 -0400 > From: Mike Tancsa <[EMAIL PROTECTED]> > Sender: [EMAIL PROTECTED] > > > At 03:54 PM 8/20/2007, Dan Armstrong wrote: > >We're going crazy up here, I'm trying to nail down where exactly the > >problem is - We don't use Cogent anywhere, but we're having terrible > >problems with Bell and many sites in Europe... > > Bell uses Cogent in a large way. The second traceroute was from an IP > in their AS (577) out. I am prepending out Cogent, but Bell does > everything it can not to use Teleglobe so I am having problems > influencing their routes to come back that way. They also have a > very odd path out of Chicago. This is from a site in Toronto (source > IP in AS577) back to me peering with Cogent's router in Toronto... > Toronto, Chicago, Kansas, Texas, Washington, Boston, Albany, > Toronto. Thats quite the milk run. Usually its Toronto, Chicago, Toronto. > Almost certainly the fiber cut of last night. Still down after >19 hours. Not a pretty picture for those lacking diversity between Chicago and points east. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgpKffokZ1MRz.pgp Description: PGP signature
Re: Cogent latency / congestion
At 03:54 PM 8/20/2007, Dan Armstrong wrote: We're going crazy up here, I'm trying to nail down where exactly the problem is - We don't use Cogent anywhere, but we're having terrible problems with Bell and many sites in Europe... Bell uses Cogent in a large way. The second traceroute was from an IP in their AS (577) out. I am prepending out Cogent, but Bell does everything it can not to use Teleglobe so I am having problems influencing their routes to come back that way. They also have a very odd path out of Chicago. This is from a site in Toronto (source IP in AS577) back to me peering with Cogent's router in Toronto... Toronto, Chicago, Kansas, Texas, Washington, Boston, Albany, Toronto. Thats quite the milk run. Usually its Toronto, Chicago, Toronto. % traceroute -f 6 -q1 199.212.134.3 traceroute to 199.212.134.3 (199.212.134.3), 64 hops max, 40 byte packets 6 64.230.229.5 (64.230.229.5) 4.846 ms 7 64.230.242.97 (64.230.242.97) 4.030 ms 8 64.230.147.14 (64.230.147.14) 14.213 ms 9 206.108.103.142 (206.108.103.142) 14.216 ms 10 p13-0.core01.ord01.atlas.cogentco.com (154.54.11.29) 101.348 ms 11 te3-1.mpd01.ord01.atlas.cogentco.com (154.54.1.206) 102.507 ms 12 t2-4.mpd01.mci01.atlas.cogentco.com (154.54.2.233) 108.993 ms 13 t4-2.mpd01.iah01.atlas.cogentco.com (154.54.5.221) 108.496 ms 14 t2-2.mpd01.dca01.atlas.cogentco.com (154.54.2.145) 110.221 ms 15 t8-2.mpd01.bos01.atlas.cogentco.com (154.54.1.105) 129.529 ms 16 g2-0-0.core01.bos01.atlas.cogentco.com (154.54.2.213) 108.507 ms 17 p13-0.core01.alb02.atlas.cogentco.com (154.54.7.41) 116.526 ms 18 p14-0.core01.yyz01.atlas.cogentco.com (66.28.4.218) 118.463 ms 19 v3491.mpd01.yyz01.atlas.cogentco.com (154.54.5.78) 217.912 ms 20 v3492.mpd01.yyz02.atlas.cogentco.com (154.54.5.82) 225.491 ms 21 sentex.demarc.cogentco.com (38.104.158.78) 217.134 ms 22 i3-vl-814 (67.43.129.242) 65.576 ms 23 shell1 (199.212.134.3) 66.221 ms ---Mike Mike Tancsa wrote: Does anyone have any details about the Cogent outage that started this morning (9am GMT-400) and is still continuing ? If its a fibre cut between Montville (NJ?) and Cleveland OH (http://status.cogentco.com/) why is it so bad in Chicago and Albany locations ? Is there really that little excess capacity ? My connection out of Toronto is pretty bad via Albany 3 g8-22.mpd01.yyz02.atlas.cogentco.com (38.104.158.77) 7.470 ms 6.754 ms 6.481 ms 4 v3493.mpd01.yyz01.atlas.cogentco.com (154.54.5.85) 6.981 ms 6.730 ms 6.984 ms 5 g2-0-0-3490.core01.yyz01.atlas.cogentco.com (154.54.5.73) 6.482 ms 7.175 ms 5.974 ms 6 p4-0.core01.alb02.atlas.cogentco.com (66.28.4.217) 105.954 ms 112.055 ms 111.426 ms 7 p6-0.core01.bos01.atlas.cogentco.com (154.54.7.42) 115.413 ms 117.090 ms 113.816 ms and Bell's through Chicago is even worse 6 64.230.229.5 (64.230.229.5) 12.572 ms 36.983 ms 200.187 ms 7 64.230.242.97 (64.230.242.97) 4.685 ms 5.439 ms 3.645 ms 8 64.230.147.14 (64.230.147.14) 14.351 ms 15.344 ms 14.387 ms 9 206.108.103.142 (206.108.103.142) 14.374 ms 14.280 ms 14.255 ms 10 p13-0.core01.ord01.atlas.cogentco.com (154.54.11.29) 156.616 ms * 142.150 ms 11 te3-1.mpd01.ord01.atlas.cogentco.com (154.54.1.206) 135.199 ms 138.900 ms * 12 t2-4.mpd01.mci01.atlas.cogentco.com (154.54.2.233) 152.292 ms 149.956 ms 148.095 ms 13 t4-2.mpd01.iah01.atlas.cogentco.com (154.54.5.221) 149.047 ms 150.556 ms 151.232 ms ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications,[EMAIL PROTECTED] Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike
Re: Cogent latency / congestion
On 8/20/07, Robert Bonomi <[EMAIL PROTECTED]> wrote: > > > > > No details, but I've seen reports of 100+ms between S.F. and L.A. on > Cogent, as well. > > hexstars-computer:~ hexstar$ traceroute status.cogentco.com traceroute to status.cogentco.com (38.9.51.60), 64 hops max, 40 byte packets 1 10.0.1.1 (10.0.1.1) 2.466 ms 1.044 ms 1.012 ms 2 * * * 3 * ge-2-8-ur01.oakland.ca.sfba.comcast.net (68.86.249.113) 11.942 ms 12.726 ms 4 68.86.90.138 (68.86.90.138) 16.877 ms 13.270 ms 15.623 ms 5 68.86.90.149 (68.86.90.149) 16.048 ms 16.763 ms 14.488 ms 6 68.86.90.165 (68.86.90.165) 20.053 ms 17.489 ms 16.963 ms 7 te-4-4.car2.sanjose1.level3.net (4.79.43.133) 19.845 ms 19.059 ms 17.520 ms 8 ae-23-79.car3.sanjose1.level3.net (4.68.18.69) 19.369 ms 16.214 ms 14.273 ms 9 cogent-comm.car3.sanjose1.level3.net (4.68.110.138) 17.942 ms 20.228ms 19.781 ms 10 v3492.mpd01.sjc01.atlas.cogentco.com (154.54.6.105) 108.626 ms 198.176ms 223.244 ms 11 t9-2.mpd01.lax01.atlas.cogentco.com (154.54.5.70) 101.092 ms 105.903ms 105.539 ms 12 t2-1.mpd01.iah01.atlas.cogentco.com (154.54.3.185) 103.102 ms 97.710ms 98.995 ms 13 t3-4.ccr01.clt01.atlas.cogentco.com (154.54.7.146) 206.319 ms 248.681ms * 14 t3-3.mpd01.dca01.atlas.cogentco.com (154.54.5.54) 108.830 ms 118.044ms 133.046 ms 15 v3491.mpd01.dca02.atlas.cogentco.com (154.54.2.182) 103.144 ms 102.917ms 103.185 ms 16 v3490.mpd01.iad03.atlas.cogentco.com (154.54.7.98) 103.380 ms 104.275ms 103.733 ms 17 g1-1.core01.hhc.corp.cogentco.com (38.104.58.6) 104.401 ms * 107.873ms 18 support.cogentco.com (38.9.51.60) 102.263 ms 104.932 ms 102.603 ms
Re: Cogent latency / congestion
Cogent is reporting a fiber cut in ohio. http://status.cogentco.com -Zak - Original Message - From: "Robert Bonomi" <[EMAIL PROTECTED]> To: Sent: Monday, August 20, 2007 3:32 PM Subject: Re: Cogent latency / congestion Date: Mon, 20 Aug 2007 15:21:38 -0400 To: nanog@merit.edu Subject: Cogent latency / congestion Does anyone have any details about the Cogent outage that started this morning (9am GMT-400) and is still continuing ? If its a fibre cut between Montville (NJ?) and Cleveland OH (http://status.cogentco.com/) why is it so bad in Chicago and Albany locations ? Is there really that little excess capacity ? No details, but I've seen reports of 100+ms between S.F. and L.A. on Cogent, as well.
Re: Cogent latency / congestion
We're going crazy up here, I'm trying to nail down where exactly the problem is - We don't use Cogent anywhere, but we're having terrible problems with Bell and many sites in Europe... Mike Tancsa wrote: Does anyone have any details about the Cogent outage that started this morning (9am GMT-400) and is still continuing ? If its a fibre cut between Montville (NJ?) and Cleveland OH (http://status.cogentco.com/) why is it so bad in Chicago and Albany locations ? Is there really that little excess capacity ? My connection out of Toronto is pretty bad via Albany 3 g8-22.mpd01.yyz02.atlas.cogentco.com (38.104.158.77) 7.470 ms 6.754 ms 6.481 ms 4 v3493.mpd01.yyz01.atlas.cogentco.com (154.54.5.85) 6.981 ms 6.730 ms 6.984 ms 5 g2-0-0-3490.core01.yyz01.atlas.cogentco.com (154.54.5.73) 6.482 ms 7.175 ms 5.974 ms 6 p4-0.core01.alb02.atlas.cogentco.com (66.28.4.217) 105.954 ms 112.055 ms 111.426 ms 7 p6-0.core01.bos01.atlas.cogentco.com (154.54.7.42) 115.413 ms 117.090 ms 113.816 ms and Bell's through Chicago is even worse 6 64.230.229.5 (64.230.229.5) 12.572 ms 36.983 ms 200.187 ms 7 64.230.242.97 (64.230.242.97) 4.685 ms 5.439 ms 3.645 ms 8 64.230.147.14 (64.230.147.14) 14.351 ms 15.344 ms 14.387 ms 9 206.108.103.142 (206.108.103.142) 14.374 ms 14.280 ms 14.255 ms 10 p13-0.core01.ord01.atlas.cogentco.com (154.54.11.29) 156.616 ms * 142.150 ms 11 te3-1.mpd01.ord01.atlas.cogentco.com (154.54.1.206) 135.199 ms 138.900 ms * 12 t2-4.mpd01.mci01.atlas.cogentco.com (154.54.2.233) 152.292 ms 149.956 ms 148.095 ms 13 t4-2.mpd01.iah01.atlas.cogentco.com (154.54.5.221) 149.047 ms 150.556 ms 151.232 ms ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications,[EMAIL PROTECTED] Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike
Re: Cogent latency / congestion
> Date: Mon, 20 Aug 2007 15:21:38 -0400 > From: Mike Tancsa <[EMAIL PROTECTED]> > Sender: [EMAIL PROTECTED] > > > > Does anyone have any details about the Cogent outage that started > this morning (9am GMT-400) and is still continuing ? If its a fibre > cut between Montville (NJ?) and Cleveland OH > (http://status.cogentco.com/) why is it so bad in Chicago and Albany > locations ? Is there really that little excess capacity ? > > My connection out of Toronto is pretty bad via Albany > > 3 g8-22.mpd01.yyz02.atlas.cogentco.com (38.104.158.77) 7.470 > ms 6.754 ms 6.481 ms > 4 v3493.mpd01.yyz01.atlas.cogentco.com (154.54.5.85) 6.981 > ms 6.730 ms 6.984 ms > 5 g2-0-0-3490.core01.yyz01.atlas.cogentco.com (154.54.5.73) 6.482 > ms 7.175 ms 5.974 ms > 6 p4-0.core01.alb02.atlas.cogentco.com (66.28.4.217) 105.954 > ms 112.055 ms 111.426 ms > 7 p6-0.core01.bos01.atlas.cogentco.com (154.54.7.42) 115.413 > ms 117.090 ms 113.816 ms > > and Bell's through Chicago is even worse > > 6 64.230.229.5 (64.230.229.5) 12.572 ms 36.983 ms 200.187 ms > 7 64.230.242.97 (64.230.242.97) 4.685 ms 5.439 ms 3.645 ms > 8 64.230.147.14 (64.230.147.14) 14.351 ms 15.344 ms 14.387 ms > 9 206.108.103.142 (206.108.103.142) 14.374 ms 14.280 ms 14.255 ms > 10 p13-0.core01.ord01.atlas.cogentco.com (154.54.11.29) 156.616 ms > * 142.150 ms > 11 te3-1.mpd01.ord01.atlas.cogentco.com (154.54.1.206) 135.199 > ms 138.900 ms * > 12 t2-4.mpd01.mci01.atlas.cogentco.com (154.54.2.233) 152.292 > ms 149.956 ms 148.095 ms > 13 t4-2.mpd01.iah01.atlas.cogentco.com (154.54.5.221) 149.047 > ms 150.556 ms 151.232 ms > > ---Mike > > > > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications,[EMAIL PROTECTED] > Providing Internet since 1994www.sentex.net > Cambridge, Ontario Canada www.sentex.net/mike > There is a fiber cut (occurred at about 2:11 UTC) in Ohio. I'm not sure if that has anything to do with this problem. It is impacting some traffic between Chicago and New York, though. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgpq1xh4YzKwm.pgp Description: PGP signature
Re: Cogent latency / congestion
Yes, their status page is not accurate. We're seeing traffic hitting the bitbucket at various locations on their network including Dallas (IAH) and Ashburn (IAD). It's be nice if they pulled their routes for this stuff. For example: traceroute to grouse.dabbledb.com (64.15.129.72), 64 hops max, 40 byte packets 1 38.99.21.1 (38.99.21.1) 2.012 ms 1.122 ms 0.468 ms 2 g0-10.na21.b003104-1.sfo01.atlas.cogentco.com (38.104.128.129) 1.229 ms 2.223 ms 0.975 ms 3 g1-7.111.core01.sfo01.atlas.cogentco.com (38.112.39.45) 1.758 ms 1.153 ms 2.523 ms 4 p4-0.core01.sjc01.atlas.cogentco.com (66.28.4.94) 2.010 ms 2.290 ms 3.886 ms 5 p14-0.core01.iah01.atlas.cogentco.com (66.28.4.237) 47.753 ms 46.791 ms 47.996 ms 6 * * * 7 * * * 8 * * * 9 *^C -david Mike Tancsa wrote: Does anyone have any details about the Cogent outage that started this morning (9am GMT-400) and is still continuing ? If its a fibre cut between Montville (NJ?) and Cleveland OH (http://status.cogentco.com/) why is it so bad in Chicago and Albany locations ? Is there really that little excess capacity ? My connection out of Toronto is pretty bad via Albany 3 g8-22.mpd01.yyz02.atlas.cogentco.com (38.104.158.77) 7.470 ms 6.754 ms 6.481 ms 4 v3493.mpd01.yyz01.atlas.cogentco.com (154.54.5.85) 6.981 ms 6.730 ms 6.984 ms 5 g2-0-0-3490.core01.yyz01.atlas.cogentco.com (154.54.5.73) 6.482 ms 7.175 ms 5.974 ms 6 p4-0.core01.alb02.atlas.cogentco.com (66.28.4.217) 105.954 ms 112.055 ms 111.426 ms 7 p6-0.core01.bos01.atlas.cogentco.com (154.54.7.42) 115.413 ms 117.090 ms 113.816 ms and Bell's through Chicago is even worse 6 64.230.229.5 (64.230.229.5) 12.572 ms 36.983 ms 200.187 ms 7 64.230.242.97 (64.230.242.97) 4.685 ms 5.439 ms 3.645 ms 8 64.230.147.14 (64.230.147.14) 14.351 ms 15.344 ms 14.387 ms 9 206.108.103.142 (206.108.103.142) 14.374 ms 14.280 ms 14.255 ms 10 p13-0.core01.ord01.atlas.cogentco.com (154.54.11.29) 156.616 ms * 142.150 ms 11 te3-1.mpd01.ord01.atlas.cogentco.com (154.54.1.206) 135.199 ms 138.900 ms * 12 t2-4.mpd01.mci01.atlas.cogentco.com (154.54.2.233) 152.292 ms 149.956 ms 148.095 ms 13 t4-2.mpd01.iah01.atlas.cogentco.com (154.54.5.221) 149.047 ms 150.556 ms 151.232 ms ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications,[EMAIL PROTECTED] Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike
Re: Cogent latency / congestion
> Date: Mon, 20 Aug 2007 15:21:38 -0400 > To: nanog@merit.edu > Subject: Cogent latency / congestion > > > > Does anyone have any details about the Cogent outage that started > this morning (9am GMT-400) and is still continuing ? If its a fibre > cut between Montville (NJ?) and Cleveland OH > (http://status.cogentco.com/) why is it so bad in Chicago and Albany > locations ? Is there really that little excess capacity ? No details, but I've seen reports of 100+ms between S.F. and L.A. on Cogent, as well.
Re: Cogent latency / congestion
Not seeing any Cogent problems in Tyson's Corner, Virginia Regards Marshall On Aug 20, 2007, at 3:21 PM, Mike Tancsa wrote: Does anyone have any details about the Cogent outage that started this morning (9am GMT-400) and is still continuing ? If its a fibre cut between Montville (NJ?) and Cleveland OH (http:// status.cogentco.com/) why is it so bad in Chicago and Albany locations ? Is there really that little excess capacity ? My connection out of Toronto is pretty bad via Albany 3 g8-22.mpd01.yyz02.atlas.cogentco.com (38.104.158.77) 7.470 ms 6.754 ms 6.481 ms 4 v3493.mpd01.yyz01.atlas.cogentco.com (154.54.5.85) 6.981 ms 6.730 ms 6.984 ms 5 g2-0-0-3490.core01.yyz01.atlas.cogentco.com (154.54.5.73) 6.482 ms 7.175 ms 5.974 ms 6 p4-0.core01.alb02.atlas.cogentco.com (66.28.4.217) 105.954 ms 112.055 ms 111.426 ms 7 p6-0.core01.bos01.atlas.cogentco.com (154.54.7.42) 115.413 ms 117.090 ms 113.816 ms and Bell's through Chicago is even worse 6 64.230.229.5 (64.230.229.5) 12.572 ms 36.983 ms 200.187 ms 7 64.230.242.97 (64.230.242.97) 4.685 ms 5.439 ms 3.645 ms 8 64.230.147.14 (64.230.147.14) 14.351 ms 15.344 ms 14.387 ms 9 206.108.103.142 (206.108.103.142) 14.374 ms 14.280 ms 14.255 ms 10 p13-0.core01.ord01.atlas.cogentco.com (154.54.11.29) 156.616 ms * 142.150 ms 11 te3-1.mpd01.ord01.atlas.cogentco.com (154.54.1.206) 135.199 ms 138.900 ms * 12 t2-4.mpd01.mci01.atlas.cogentco.com (154.54.2.233) 152.292 ms 149.956 ms 148.095 ms 13 t4-2.mpd01.iah01.atlas.cogentco.com (154.54.5.221) 149.047 ms 150.556 ms 151.232 ms ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications,[EMAIL PROTECTED] Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike
