I was wondering if anyone had any experience with Cogent Inc. They are
one of the companies offering high speed internet (fast ethernet/GigE) at
rock
bottom prices. 
I know the adage "you get what you pay for" typically applies but
I was looking for some concrete end user experiences. I'm not trying to
break the charter of this mailing list by devoting a discussion to various
emotion based opinions about a particular vendor. I am actually seeking
technical opinions on whether what is being advertised is actually
being delivered with reliability. More specific questions: do Cogent's
peering arrangements seem adequate to the amount of bandwidth
they are offering? Or are these major bottlenecks to an otherwise
good network? Are any of Cogent's competitors worth taking a look
at? Any non-obvious reason why? Does anyone have any statistics to provide
that paints a picture
about what you get from their products? I guess if enough people
complained that this was too off topic, I could still request direct
replies and I could put a summary together for any interested parties.
But I reread the charter before putting this together and it seems
fair game. When is Worldcom, et al going to start offering these
products? ( maybe when companies like cogent start succeeding?)
Thanks,
-BM
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Well, the network really wasn't lit at the time of the last
discussion.
Is anyone on-list a cogent customer? Has anyone done or heard about
any peering with cogent? If so what type of pipe?
Could they do a lot of damage if some customers start to really push
traffic? (ie: 30 "big" customers pushing 500 megs each and throwing
an extra 15gigs/sec onto mae-east).
Matt
- -----Original Message-----
* Matt Levine <matt@deliver3.com> [20010612 17:02]:
Is anyone on-list a cogent customer? Has anyone done or heard about
any peering with cogent? If so what type of pipe?
They are at PAIX. The last I contacted them they had a "very open policy
about public peering". Try contacting <peering@cogentco.com>....they
respond in my experience.
Could they do a lot of damage if some customers start to really push
traffic? (ie: 30 "big" customers pushing 500 megs each and throwing
an extra 15gigs/sec onto mae-east).
My impression is that their connectivity is primarily provided by one or
more transit providers (I know only of above.net) plus a bit of peering.
I'd imagine their links to their transit providers would feel the pain
first. I'd expect that they'd notice and upgrade the links just as
everybody else does. It would move on up the chain. Of course, if most of
the traffic were sourced/destined for a particular spot either Cogent or
one of their transit providers would increase peering. If it was just a
popular bit of content (Web site, RealMedia stream, whatever) that one of
their clients was hosting and that amount of traffic was being pushed
I'd imagine a lot of people would want to turn up (or upgrade existing)
private peering links with them. Problem resolved. I doubt anybody would
feel much pain other than perhaps Cogent and their end-user for a finite
period where the upgrading would be going on.
Perhaps I'm optimistic. YMMV.
-jr
I'm not a cogent customer right now, but they were going to donate
some connectivity to a group i volunteer with (www.kidzonline.org),
I think I have some technical materials at the office.
-ajb
--snip--
* i66.28.15.0/24 209.1.40.66 1000 0 6461 16631 19457 i
*>i 209.1.40.113 1000 0 16631 19457 i
--snip--
route-server.exodus.net>traceroute 66.28.15.1
Type escape sequence to abort.
Tracing the route to 66.28.15.1
1 dcr03-p0-2.sntc02.exodus.net (209.1.169.182) 0 msec 0 msec 0 msec
2 bbr01-g4-0.sntc02.exodus.net (216.33.154.99) 0 msec 0 msec 0 msec
3 bbr02-p3-0.sntc04.exodus.net (209.1.169.254) 4 msec 0 msec 0 msec
4 ibr01-g5-0.sntc04.exodus.net (216.34.2.22) 4 msec 20 msec 0 msec
5 216.32.173.218 0 msec 0 msec 4 msec
6 core3-core5-oc48.sjc2.above.net (208.185.156.65) [AS 6461] 0 msec 4 msec 4 msec
7 iad1-sjc2-oc48.iad1.above.net (216.200.127.25) [AS 6461] 68 msec 72 msec 68 msec
8 core4-core1-oc48.iad1.above.net (208.185.0.138) [AS 6461] 72 msec 72 msec 72 msec
9 core1-iad1-oc48.iad5.above.net (216.200.127.10) [AS 6461] 68 msec 72 msec 68 msec
10 64.124.112.29.cogentco.com (64.124.112.29) [AS 6461] 68 msec 68 msec 68 msec
11 p4-0.core01.phl01.atlas.cogentco.com (66.28.4.18) [AS 16631] 68 msec 68 msec msec
12 p5-0.core02.jfk02.atlas.cogentco.com (66.28.4.1) [AS 16631] 72 msec 76 msec
13 g49.ba01.b001557.jfk02.atlas.cogentco.com (66.28.5.146) [AS 16631] 72 msec 72 76 msec
14 66.28.14.6 [AS 16631] 72 msec * 72 msec
--snip--
Connecting to [rwhois.cogentco.com] port [4321] -> command line server
%rwhois V-1.5:0010b0:00 rwhois.cogentco.com
network:ID:NET-421C0F0018
network:Network-Name:NET-421C0F0018
network:IP-Network:66.28.15.0/24
network:Org-Name:Rudin Management Corp.
network:Street-Address:345 Park Ave, 32 & 33rd fl
network:City:New York City
network:State:NY
network:Postal-Code:10154
network:Country-Code:US
network:Tech-Contact:ZC108-ARIN
network:Updated:2001-05-31 17:50:35
network:Updated-By:ddiller
%ok
--snip--
...
Yes, Cogent is at MAE-E-ATM.
3 a1-0-1052.core1.adc.nac.net (209.123.11.126) 6.355 ms 6.444 6.406 ms
4 mae-east.cogentco.com (198.32.187.114) 8.467 ms 8.414 ms 8.593 ms
Is someone renumbering around this area?
My motivation is to understand the mechanisms and techniques \
by which a non-privelaged user (ie someone without login access to a BGP fed
router)
would diagnose (characterize, locate, identify, etc..) failure to reach a
large corporations
mail servers (1/2 of the MX servers for fleet.com)
RADB has nothing on this, a New York QWEST looking glass says:
Query: bgp
IP address: 170.36.73.11
Location: New York
Timeout: 20 seconds
% Network not in table
What's up?
* Erik Antelman <erik@nombas.com> [20010614 07:47]:
Is someone renumbering around this area?
My motivation is to understand the mechanisms and techniques \
by which a non-privelaged user (ie someone without login access to a BGP fed
router) would diagnose (characterize, locate, identify, etc..) failure to
reach a large corporations mail servers (1/2 of the MX servers for
fleet.com)
Here's some of that stuff I'd do:
Grab a list of their MX servers and use the standard tools to check them out:
* Public looking glasses (which will allow even someone without access
to their own BGP router to check out a reasonable sample of global
routing tables). If you're lucky you may even may able to find a
looking glass in the immediate upstream AS from the site you are
having trouble reaching.
* whois (I highly recommend installing/using the GeekTools proxy to make
querying the various whois servers that may be relevant to your query).
* traceroute/ping (network connectivity)
* nslookup/dig (find out all of the MX servers involved)
* log files on relay hosts you control or otherwise have access to
RADB has nothing on this, a New York QWEST looking glass says:
Query: bgp
IP address: 170.36.73.11
Location: New York
Timeout: 20 seconds
% Network not in table
What's up?
Just what it says. They don't appear to be announcing their block.
(same results here from several boxes I checked, BTW)
Note though that only two of their MX boxes are in that block:
fleet.com preference = 30, mail exchanger = bkb-bh.bkb.com
fleet.com preference = 40, mail exchanger = testmail.fleet.com
fleet.com preference = 10, mail exchanger = sweeper.bkb.com
fleet.com preference = 20, mail exchanger = walmail.bkb.com
fleet.com preference = 10, mail exchanger = mail2.fleet.com
fleet.com preference = 20, mail exchanger = bosmail.bkb.com
fleet.com preference = 20, mail exchanger = fleet-cp.fleet.com
fleet.com nameserver = dnsauth3.sys.gtei.net
fleet.com nameserver = dnsauth1.sys.gtei.net
fleet.com nameserver = dnsauth2.sys.gtei.net
bkb-bh.bkb.com internet address = 204.167.53.66
testmail.fleet.com internet address = 170.36.73.48
sweeper.bkb.com internet address = 155.182.19.38
walmail.bkb.com internet address = 32.97.32.201
mail2.fleet.com internet address = 170.36.73.11
bosmail.bkb.com internet address = 204.167.53.91
fleet-cp.fleet.com internet address = 199.95.175.66
dnsauth3.sys.gtei.net internet address = 4.2.49.4
dnsauth1.sys.gtei.net internet address = 4.2.49.2
dnsauth2.sys.gtei.net internet address = 4.2.49.3
Have you tried contacting the technical contact listed in the WHOIS record?
Or perhaps GTEI (Genuity) who appears to be their service provider?
-jr
HAve youtried doing a BGP lookup for the MX's IP, rather than the whole
/16? That will return the smallest aggregate that includes the target
IP(s). It's entirely possible that the block is not in the table as a /16,
but as a set of sub-aggregates.
-Chris
(Thwaps hand against forehead)
Oh, you DID lookup the individual IP. never mind.
/me crawls back into his cubicle.
-Chris
* Christopher A. Woodfield <rekoil@semihuman.com> [20010614 08:04]:
(Thwaps hand against forehead)
Oh, you DID lookup the individual IP. never mind.
/me crawls back into his cubicle.
Well there is more than one MX box for the site he's concerned with...most
in completely different CIDR blocks. It wouldn't hurt the original poster
to do what you suggested so don't hurt your forehead too badly.
-jr
Are you sure this couldn't be intentional?
I've once seen a setup where you had the lowest-priority MX (by that, I mean
the one with the lowest number, in case my wording is ambiguous or
contradictory) being some host with an RFC 1918 IP, and then there was a
higher-priority MX which was their NAT box. I'm guessing (I never sent mail
there, or worked with this setup, thank god) that the idea was that
connections to the RFC 1918 box would die, so remote MTAs would contact the
NAT box and deliver there. The NAT box would then try to relay to the
primary MX, and since it would obviously have an interface into the network
with the RFC 1918 IPs, it would be able to deliver.
This place doesn't seem to be using this setup anymore, although amusingly
enough most of their NS records point to machines with 10.200 IPs.
I agree that this type of thing is entirely dumb, but is there any reason
that the network mentioned by the original poster couldn't be doing the same
thing?
Many large corporations that have been running IP networks since before Wall
Street knew the meaning of the word Internet have different real blocks of
IP space (usually in the class B space) for their "public" network and their
corporate network...
You may also want to take a look at this:
vivienm@citrine:~$ whois -a 170.36.73.11
Fleet Services Corporation (NET-FLEET)
Mail Stop NY/KP/0104
Peter D. Kiernan Plaza
Albany, NY 12207
US
Netname: FLEET
Netblock: 170.36.0.0 - 170.36.255.255
Maintainer: FSCO
Coordinator:
Ryan, Tom (TR23-ARIN) postmaster@FLEET.COM
(518) 447-2241
Record last updated on 02-Feb-2001.
Database last updated on 13-Jun-2001 23:03:57 EDT.
The ARIN Registration Services Host contains ONLY Internet
Network Information: Networks, ASN's, and related POC's.
Please use the whois server at rs.internic.net for DOMAIN related
Information and whois.nic.mil for NIPRNET Information.
It seems slightly odd to me that this block seems to have no DNS servers
listed for reverse lookups if it is in public use.
Vivien
The most obvious use for this setup (the reason I made several customers
implement it at my previous life as an abusecritter) ) is to close down an
open SMTP relay that couldn't otherwise be closed down (*cough* Cc:Mail
*cough*). Relaying is controlled on the publically accessable server, but
only mail destined for the target domain comes into the primary MX. Hence,
no thrid-party relaying.
-Chris