Cogent input

Thu Jun 11 14:49:23 UTC 2009

Stephen Kratzer wrote:
> Should have said "And, they have no plans to deploy IPv6 in the immediate 
> future."
>
> On Thursday 11 June 2009 10:33:25 Stephen Kratzer wrote:
>   
>> We've only recently started using Cogent transit, but it's been stable
>> since its introduction 6 months ago. Turn-up was a bit rocky since we never
>> received engineering details, and engineering was atypical in that two eBGP
>> sessions were established, one just to advertise loopbacks, and another for
>> the actual feed. The biggest issue we have with them is that they don't
>> allow deaggregation. If you've been allocated a prefix of length yy,
>> they'll accept only x.x.x.x/yy, not x.x.x.x/yy le 24. Yes, sometimes
>> deaggregation is necessary or desirable even if only temporarily.
>>
>> And, they have no plans to support IPv6.
>>
>> "Cogent's official stance on IPv6 is that we will deploy IPv6 when it
>> becomes a commercial necessity. We have tested IPv6 and we have our plan
>> for rolling it out, but there are no commercial drivers to spend money
>> to upgrade a network to IPv6 for no real return on investment."
>>
>> Stephen Kratzer
>> Network Engineer
>> CTI Networks, Inc.
>>
>> On Thursday 11 June 2009 09:46:45 Justin Shore wrote:
>>     
>>> I'm in search of some information about Cogent, it's past, present and
>>> future.  I've heard bits and pieces about Cogent's past over the years
>>> but by no means have I actively been keeping up.
>>>
>>> I'm aware of some (regular?) depeering issues.  The NANOG archives have
>>> given me some additional insight into that (recurring?) problem.  The
>>> reasoning behind the depeering events is a bit fuzzy though.  I would be
>>> interested in people's opinion on whether or not they should be consider
>>> for upstream service based on this particular issue.  Are there any
>>> reasonable mitigation measures available to Cogent downstreams if
>>> (when?) Cogent were to be depeered again?  My understanding is that at
>>> least on previous depeering occasion, the depeering partner simply
>>> null-routed all prefixes being received via Cogent, creating a blackhole
>>> essentially.  I also recall reading that this meant that prefixes being
>>> advertised and received by the depeering partner from other peers would
>>> still end up in the blackhole.  The only solution I would see to this
>>> problem would be to shut down the BGP session with Cogent and rely on a
>>> 2nd upstream.  Are there any other possible steps for mitigation in a
>>> depeering event?
>>>
>>> I also know that their bandwidth is extremely cheap.  This of course
>>> creates an issue for technical folks when trying to justify other
>>> upstream options that cost significantly more but also don't have a
>>> damaging history of getting depeered.
>>>
>>> Does Cogent still have an issue with depeering?  Are there any
>>> reasonable mitigation measures or should a downstream customer do any
>>> thing in particular to ready themselves for a depeering event?  Does
>>> their low cost outweigh the risks?  What are the specific risks?
>>>
>>> Thanks
>>>   Justin
>>>       
>
>
>
>
>   
In Europe they have been good and stable most of the time. In the US
well, they are cogent and I have so many bad experiences with them here
I cannot in all honestly recommend them. But if your looking for cheap
bandwidth to complement another provider its not an unreasonable thing
to do as they price point is competitive.


Manolo