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
I believe that this is a topic that has been brought up before. http://www.merit.edu/mail.archives/nanog/2000-12/threads2.html#00175 ---- Steve Rude steve@rudedogg.com On Tue, 12 Jun 2001, Murphy, Brennan wrote:
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----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Steve Rude Sent: Tuesday, June 12, 2001 4:13 PM To: Murphy, Brennan Cc: 'nanog@merit.edu' Subject: Re: cogentco.com technical analysis? I believe that this is a topic that has been brought up before. http://www.merit.edu/mail.archives/nanog/2000-12/threads2.html#00175 - ---- Steve Rude steve@rudedogg.com On Tue, 12 Jun 2001, Murphy, Brennan wrote:
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 SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com> iQA/AwUBOya1lcp0j1NsDQTPEQJ0iQCgwVlzn5NbcsSZJKnzqZaAyXVoyOAAoIP+ r4g+xh7w5/gCKPfHETVzA3W3 =SAmy -----END PGP SIGNATURE-----
* 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 ---- Josh Richards <jrichard@{ geekresearch.com, cubicle.net }> [JTR38/JR539-ARIN] Geek Research, LLC - San Luis Obispo, CA - <URL:http://www.geekresearch.com/> KG6CYK - IP/Unix/telecom/knowledge/coffee/security/crypto/business/geek
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 On Tue, Jun 12, 2001 at 05:36:39PM -0700, Matt Levine wrote: -> -> ->-----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----- ->From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf ->Of Steve Rude ->Sent: Tuesday, June 12, 2001 4:13 PM ->To: Murphy, Brennan ->Cc: 'nanog@merit.edu' ->Subject: Re: cogentco.com technical analysis? -> -> -> ->I believe that this is a topic that has been brought up before. -> ->http://www.merit.edu/mail.archives/nanog/2000-12/threads2.html#00175 -> -> ->- ---- ->Steve Rude ->steve@rudedogg.com -> ->On Tue, 12 Jun 2001, Murphy, Brennan wrote: -> ->> ->> 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 SIGNATURE----- ->Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com> -> ->iQA/AwUBOya1lcp0j1NsDQTPEQJ0iQCgwVlzn5NbcsSZJKnzqZaAyXVoyOAAoIP+ ->r4g+xh7w5/gCKPfHETVzA3W3 ->=SAmy ->-----END PGP SIGNATURE----- ---end quoted text--- -- Andrew Barros <abarros@tjhsst.edu> PGP Key Fingerprint: D3B8 0800 C45A 143E 5CF0 E112 0A1B AB36 B655 1FB8
On Tue, Jun 12, 2001 at 05:36:39PM -0700, Matt Levine wrote: ->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?
--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-- ... -- Omachonu Ogali missnglnk@informationwave.net http://www.informationwave.net
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 On Wed, 13 Jun 2001, Omachonu Ogali wrote:
On Tue, Jun 12, 2001 at 05:36:39PM -0700, Matt Levine wrote: ->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?
--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--
... -- Omachonu Ogali missnglnk@informationwave.net http://www.informationwave.net
-- Alex Rubenstein, AR97, K2AHR, alex@nac.net, latency, Al Reuben -- -- Net Access Corporation, 800-NET-ME-36, http://www.nac.net --
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 ---- Josh Richards <jrichard@{ geekresearch.com, cubicle.net }> [JTR38/JR539-ARIN] Geek Research, LLC - San Luis Obispo, CA - <URL:http://www.geekresearch.com/> KG6CYK - IP/Unix/telecom/knowledge/coffee/security/crypto/business/geek
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Josh Richards Sent: June 14, 2001 11:23 AM To: nanog@merit.edu Subject: Re: What is up with 170.36.0.0/16
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?
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 -- Vivien M. vivienm@dyndns.org Assistant System Administrator Dynamic DNS Network Services http://www.dyndns.org/
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
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...
-- --------------------------- Christopher A. Woodfield rekoil@semihuman.com PGP Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB887618B
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 On Thu, Jun 14, 2001 at 11:28:36AM -0400, Erik Antelman wrote:
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?
-- --------------------------- Christopher A. Woodfield rekoil@semihuman.com PGP Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB887618B
(Thwaps hand against forehead) Oh, you DID lookup the individual IP. never mind. /me crawls back into his cubicle. -Chris On Thu, Jun 14, 2001 at 11:34:04AM -0400, Christopher A. Woodfield wrote:
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
On Thu, Jun 14, 2001 at 11:28:36AM -0400, Erik Antelman wrote:
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?
-- --------------------------- Christopher A. Woodfield rekoil@semihuman.com
PGP Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB887618B
-- --------------------------- Christopher A. Woodfield rekoil@semihuman.com PGP Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB887618B
* 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
On Thu, Jun 14, 2001 at 11:34:04AM -0400, Christopher A. Woodfield wrote:
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.
---- Josh Richards <jrichard@{ geekresearch.com, cubicle.net }> [JTR38/JR539-ARIN] Geek Research, LLC - San Luis Obispo, CA - <URL:http://www.geekresearch.com/> KG6CYK - IP/Unix/telecom/knowledge/coffee/security/crypto/business/geek
participants (10)
-
Alex Rubenstein -
Andrew Barros -
Christopher A. Woodfield -
Erik Antelman -
Josh Richards -
Matt Levine -
Murphy, Brennan -
Omachonu Ogali -
Steve Rude -
Vivien M.