Links between cabinets at commercial datacentre
Folks, Wishing to set up an alternative peering point in our fair city, we have run into a problem with the data center administration. The data center prohibits direct cabling between clients cabinets, even if the clients agree. Our peering point is not in the data center, but is in the same building, and will necessitate data center clients separately running fibre to our room, and paying not only for installation but also monthly fees proportional to bandwidth carried. We are in South Africa, the monthly fees are related to wireline costs, even though the monopoly wireline provider, Telkom, is not involved. Without this rule, we would run one fibre between the datacenter and the peering point, and have peers in the datacenter hop on that fibre. While acknowledging that a data center may make any rules it likes, I am asking nanog how common this practice is. If people mail me offlist, I would be willing to summarise if there is enough interest. Cheers,Andy!
Re: Links between cabinets at commercial datacentre
The data center prohibits direct cabling between clients cabinets, even if the clients agree. They require that all cables from customer racks go to a meet-me room and crossconnect there? If so, are you also allowed into the meet-me room? Or are they simply not allowed to purchase unlit service at all? That is, are tenants in the data center only allowed to purchase circuits from the telco, as opposed to crossconnects? While acknowledging that a data center may make any rules it likes, I am asking nanog how common this practice is. This is very uncommon. Rules like these do exist, but facilities with such rules very rarely attract enough customers to be worthy of interest to people building exchanges. -Bill
Re: Links between cabinets at commercial datacentre
On Wed, 17 Apr 2002, Bill Woodcock wrote: Or are they simply not allowed to purchase unlit service at all? That is, are tenants in the data center only allowed to purchase circuits from the telco, as opposed to crossconnects? This is not the Telco - this is a commercial, large, datacenter. No connections between cabinets. Period. While acknowledging that a data center may make any rules it likes, I am asking nanog how common this practice is. This is very uncommon. Rules like these do exist, but facilities with such rules very rarely attract enough customers to be worthy of interest to people building exchanges. That is exactly why we are locating the exchange outside the datacenter. However, we are still a prisoner of this rule, as peers must separately 'purchase' connectivity to us - basically a fee for connectivity. South Africa has few large colo facilities. Because of the large expense of cross-town connects, an artifact of Telkom as a monopoly provider, we are obliged to locate in the same building as the datacenter. To reiterate, Telkom is not a factor in costing the peering point connectivity to the datacenter. Cheers, Andy!
Does anyone no if Global Crossing is having Outages in the New York Area
Title: Message Is Global Crossing experiencing outages in the New York Area? Peter Berson Consultant Service Engineer Quallaby Corporation Tel # (978) 539-0743 http://www.quallaby.com
Re: Does anyone no if Global Crossing is having Outages in the New Yo rk Area
Bankruptcy might qualify... Mark. From: Berson, Peter [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Does anyone no if Global Crossing is having Outages in the New Yo rk Area Date: Wed, 17 Apr 2002 13:41:26 -0400 Is Global Crossing experiencing outages in the New York Area? Peter Berson Consultant Service Engineer Quallaby Corporation Tel # (978) 539-0743 http://www.quallaby.com http://www.quallaby.com/ _ Send and receive Hotmail on your mobile device: http://mobile.msn.com
RE: Korean server security?
Title: RE: Korean server security? Looks like someone actually hacked their main server, and not the one that was the target. Anyone that signed up for the contest got an email something like the following: Regards, We should all respect the fact that Korea Digital Works is very brave for releasing their products to the public like this, and openly inviting all hackers, to find any possible exploits. One has to keep in mind that no matter how many preventions you take, there will always potentially be a way to hack the system. Anyway, the contest server was only simulation, not a real world environment, and you have to ask yourself who will have a webserver running with this small amount of services activated. No body. The real world environment provided in this contest was not the simulation server at all, it was the overall contest in general. This is why we decided to take the contest to the next level. We chose to skip the games and festivals, and go straight to the main server (where you registered for the contest). By taking this step, we achieve a real time environment with a system that has many services running, just like many other web servers. We also gain access to the server that contains all of the entries for the contest that is taking place, thus granting us the ability to manipulate those entries to our liking (keep in mind your prize money relies on your registration entry). Theres more, but didn't want to pollute the list with to much off topic ASC. -Joe
RE: references on non-central authority network protocols
This appears to have bounced due to a configuration error on my end... -Original Message- From: Tony Hain [mailto:[EMAIL PROTECTED]] Sent: Monday, April 15, 2002 11:40 AM To: Stephen Sprunk; Scott A Crosby Cc: Patrick Thomas; [EMAIL PROTECTED] Subject: RE: references on non-central authority network protocols Stephen Sprunk wrote: Interesting idea though. Perhaps someone will write an i-d on autonomous numbering for IPv6. RFC 3041 http://www.tml.hut.fi/~pnr/publications/cam2001.pdf Jasper Wallace wrote: Location - either distribute all the addresses evenly over the planet or try to map to population density. (the higher your density of sites, the more accurate your coordinates need to be). you could aggregate addresses by doing something like: 2 hemispheres 36 'triangular' chunks spaced every 10 degrees latitude. then split up in longditudernal stripes. http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-02.txt but i think you'd be better allocation on the basis of population density. How exactly you'd make the social and economic changes to get to a system like this vs, the telcos/isps we have now is probably more trouble than it's worth ;-P http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-use-02.txt Tony
Re: Links between cabinets at commercial datacentre
Just saw this release.. http://biz.yahoo.com/rb/020417/tech_cisco_technology_1.html Bri On Wed, 17 Apr 2002, Joe Abley wrote: On Wednesday, April 17, 2002, at 02:29 , Kevin Loch wrote: Rubens Kuhl Jr. wrote: Spread-spectrum radio systems are not that easy to DoS, a good benefit from the original military applications. Actually, at close range it should be trivial to Dos an 802.11 system. Just throw up a strong enough carrier anywhere within the receivers passband and it will have trouble hearing the desired traffic. Or you could just microwave a bunch of burritos. Joe
OT: Looking for BSTDX-9000 Cards and Chassis
Is there anyone on NANOG that has, or know of anyone that has any BSTDX-9000 Chassis, Processor or Line Cards? Please reply off-list. Thanks in advance, Alexander Kiwerski
XO problems?
Title: XO problems? Anyone seeing issues with XO routing? /root# traceroute www.cisco.com traceroute to www.cisco.com (198.133.219.25), 30 hops max, 38 byte packets 1 132.237.9.3 (132.237.9.3) 3.510 ms 0.448 ms 0.443 ms 2 132.237.245.1 (132.237.245.1) 0.739 ms 0.791 ms 0.790 ms 3 67.104.110.113 (67.104.110.113) 1.826 ms 2.091 ms 1.860 ms 4 p4-3-0.MAR1.Fremont-CA.us.xo.net (207.88.80.9) 2.044 ms 2.088 ms 2.112 ms 5 p5-1-0-0.RAR1.SanJose-CA.us.xo.net (65.106.5.141) 2.438 ms 2.371 ms 2.368 ms 6 p1-0-0.RAR1.Washington-DC.us.xo.net (65.106.0.37) 82.448 ms 87.242 ms 82. 110 ms 7 p6-0-0.RAR2.NYC-NY.us.xo.net (65.106.0.1) 86.110 ms 86.055 ms 86.090 ms 8 ge5-0.dist1.hud-ny.us.xo.net (64.220.3.65) 86.688 ms 86.560 ms 86.586 ms 9 ge6-0.edge1.hud-ny.us.xo.net (64.220.3.83) 86.734 ms 86.715 ms 86.835 ms 10 * * * 11 * * agr1-loopback.NewYork.cw.net (206.24.194.101) 3100.552 ms 12 * * *
Re: references on non-central authority network protocols
At 03:40 PM 4/14/2002 -0500, Stephen Sprunk wrote: No, the trick is for a distributed algorithm to generate a non-trivial number of unique values for a (short) fixed-length field. This line of suggestion indicates a goal of identification, rather than addressing. Addressing is supposed to have relevance to the infrastructure topology, so that it indicates a place within the topology. As to the larger goal of non-centralized address assignment, the usual distinction is between administrative method, versus basis of assignment authority. Distributed (non-centralized) administration is not very difficult. As noted, the RIRs are a version of that. Independent assignment (multiple authorities) has not been achieved so far. Activities that appear to have this feature actually rely on a logical central authority, with operational coordination among the participants. The central authority in these cases is either some sort of statute or the cooperative enforcement of the participation community. d/ -- Dave Crocker mailto:[EMAIL PROTECTED] TribalWise, Inc. http://www.tribalwise.com tel +1.408.246.8253; fax +1.408.850.1850
RE: XO problems?
Before there is wild speculation since cw.net shows up in the path We are not experiencing any issues in DC or NY that would cause the problem below. I have dropped in traceroutes from the ingress to our network from XO to Cisco.com, and back to the first hop in the traceroute in Joe's traceroute to demonstrate that CW is forwarding packets as we are supposed to do. :-) If there are questions regarding routing issues within AS3561, [EMAIL PROTECTED] would be happy to investigate and respond. Regards, Mark Kasten Cable Wireless [EMAIL PROTECTED] traceroute www.cisco.com traceroute to www.cisco.com (198.133.219.25), 30 hops max, 40 byte packets 1 agr2-loopback.NewYork.cw.net (206.24.194.102) 1.131 ms agr1-loopback.NewYork.cw.net (206.24.194.101) 1.077 ms 1.001 ms 2 dcr2-so-7-1-0.NewYork.cw.net (206.24.207.197) 0.789 ms 0.650 ms dcr2-so-6-0-0.NewYork.cw.net (206.24.207.177) 0.610 ms 3 agr4-so-4-0-0.NewYork.cw.net (206.24.207.78) 0.758 ms agr3-so-2-0-0.NewYork.cw.net (206.24.207.186) 0.671 ms 0.704 ms 4 acr1-loopback.NewYork.cw.net (206.24.194.61) 1.026 ms 1.039 ms 0.912 ms 5 206.24.195.202 (206.24.195.202) 0.843 ms 0.799 ms 0.814 ms 6 gbr2-p70.n54ny.ip.att.net (12.123.1.134) 1.037 ms 0.863 ms 0.852 ms 7 tbr1-p013301.n54ny.ip.att.net (12.122.11.5) 1.261 ms 3.661 ms 1.650 ms 8 tbr1-cl1.cgcil.ip.att.net (12.122.10.5) 68.805 ms 68.180 ms 68.625 ms 9 tbr1-p013302.sffca.ip.att.net (12.122.11.217) 68.233 ms 68.018 ms 67.755 ms 10 gbr5-p100.sffca.ip.att.net (12.122.11.74) 66.266 ms 66.326 ms 66.368 ms 11 gar1-p360.sj2ca.ip.att.net (12.122.2.253) 67.636 ms 67.600 ms 67.711 ms 12 12.127.200.82 (12.127.200.82) 67.434 ms 67.357 ms 67.478 ms 13 sjck-dirty-gw1.cisco.com (128.107.239.9) 66.229 ms 66.220 ms 66.134 ms 14 sjck-sdf-ciod-gw1.cisco.com (128.107.239.106) 67.582 ms 67.750 ms 67.504 ms ^C [EMAIL PROTECTED] ping www.cisco.com PING www.cisco.com (198.133.219.25): 56 data bytes 64 bytes from 198.133.219.25: icmp_seq=0 ttl=244 time=66.618 ms 64 bytes from 198.133.219.25: icmp_seq=1 ttl=244 time=66.287 ms [EMAIL PROTECTED] traceroute 132.237.9.3 traceroute to 132.237.9.3 (132.237.9.3), 30 hops max, 40 byte packets 1 agr1-loopback.NewYork.cw.net (206.24.194.101) 1.152 ms agr2-loopback.NewYork.cw.net (206.24.194.102) 1.081 ms 0.823 ms 2 dcr2-so-6-0-0.NewYork.cw.net (206.24.207.177) 9.728 ms dcr1-so-7-0-0.NewYork.cw.net (206.24.207.65) 0.797 ms dcr2-so-7-1-0.NewYork.cw.net (206.24.207.197) 0.803 ms 3 dcr1-loopback.Washington.cw.net (206.24.226.99) 4.954 ms dcr2-loopback.Washington.cw.net (206.24.226.100) 5.144 ms dcr1-loopback.Washington.cw.net (206.24.226.99) 4.943 ms 4 agr2-so-0-0-0.Washington.cw.net (206.24.238.54) 4.851 ms agr2-so-2-0-0.Washington.cw.net (206.24.238.182) 4.770 ms 4.692 ms 5 iar2-loopback.Washington.cw.net (206.24.226.13) 5.180 ms 5.167 ms 5.065 ms 6 xo-communication-telc-audit.Washington.cw.net (208.173.10.70) 5.402 ms 4.883 ms 5.632 ms 7 ge5-3-1.RAR1.Washington-DC.us.xo.net (64.220.0.222) 6.359 ms 6.010 ms 6.067 ms 8 p1-0-0.RAR1.SanJose-CA.us.xo.net (65.106.0.38) 78.736 ms 78.773 ms 79.209 ms 9 p4-0-0.MAR1.Fremont-CA.us.xo.net (65.106.5.142) 78.519 ms 78.741 ms 78.407 ms 10 p0-0.CHR1.Fremont-CA.us.xo.net (207.88.80.10) 79.890 ms 79.791 ms 80.193 ms 11 67.104.110.114 (67.104.110.114) 81.329 ms 82.717 ms 81.717 ms 12 * * * 13 * * * 14 * * * -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Joe Blanchard Sent: Wednesday, April 17, 2002 4:03 PM To: '[EMAIL PROTECTED]' Subject: XO problems? Anyone seeing issues with XO routing? /root# traceroute www.cisco.com traceroute to www.cisco.com (198.133.219.25), 30 hops max, 38 byte packets 1 132.237.9.3 (132.237.9.3) 3.510 ms 0.448 ms 0.443 ms 2 132.237.245.1 (132.237.245.1) 0.739 ms 0.791 ms 0.790 ms 3 67.104.110.113 (67.104.110.113) 1.826 ms 2.091 ms 1.860 ms 4 p4-3-0.MAR1.Fremont-CA.us.xo.net (207.88.80.9) 2.044 ms 2.088 ms 2.112 ms 5 p5-1-0-0.RAR1.SanJose-CA.us.xo.net (65.106.5.141) 2.438 ms 2.371 ms 2.368 ms 6 p1-0-0.RAR1.Washington-DC.us.xo.net (65.106.0.37) 82.448 ms 87.242 ms 82. 110 ms 7 p6-0-0.RAR2.NYC-NY.us.xo.net (65.106.0.1) 86.110 ms 86.055 ms 86.090 ms 8 ge5-0.dist1.hud-ny.us.xo.net (64.220.3.65) 86.688 ms 86.560 ms 86.586 ms 9 ge6-0.edge1.hud-ny.us.xo.net (64.220.3.83) 86.734 ms 86.715 ms 86.835 ms 10 * * * 11 * * agr1-loopback.NewYork.cw.net (206.24.194.101) 3100.552 ms 12 * * *
Re: Links between cabinets at commercial datacentre
While acknowledging that a data center may make any rules it likes, I am asking nanog how common this practice is. data center is too amorphous a term to be used here. private data centers owned by banks or insurance companies aren't relevant at all. telco motels aren't really data centers but the issue does come up there. someone like exodus or qwest or att or uunet or abovenet would be very likely to prevent their customers from directly cross-connecting. mae-west (55 s market) won't allow it either. paix, equinix, switch and data, and other neutral colos won't allow it to occur without a fee but the fees are reasonable (unlike, say, the cross connect fees at mae-west.) there's no answer to the question, as posed. can you be more specific?
More on Telco/ISP practices in Africa..
The recent thread related to an exchange point in South Africa reminded me of something I stumbled upon yesterday.. The great African internet robbery http://news.bbc.co.uk/hi/english/world/africa/newsid_1931000/1931120.stm I feel it's a rather ignorant article, primarily because it is written from a financial/social equality standpoint with no regard for anything technical. Nonetheless, it seems to have received quite the hype (thanks a lot /.): http://slashdot.org/articles/02/04/16/1235211.shtml?tid=95 I'm curious as to what the consensus is among US network operators..
Re: Links between cabinets at commercial datacentre
there's no answer to the question, as posed. can you be more specific? I think the poster was inquiring as to common practice. Yes, but there isn't going to be a common practice for data centers as a whole. There's going to be a common practice for telco/fiber hotels, and a common practice for hosting centers, and a common practice for exchange points, and a common practice for shellcore, and so on. Each kind of data center drives toward its own common practice, and asking about common practices for data centers is therefore a nonquestion.
Re: XO problems?
On 04/17/02, Joe Blanchard [EMAIL PROTECTED] wrote: Anyone seeing issues with XO routing? Yep, I was seeing 3000+ ms from SBC into XO earlier this afternoon. Seems to have cleared up now. -- J.D. Falk say your peace -- Scott Nelson [EMAIL PROTECTED](probably a typo, but I like it)
Re: XO problems?
On Wed, 17 Apr 2002, J.D. Falk wrote: Anyone seeing issues with XO routing? Yep, I was seeing 3000+ ms from SBC into XO earlier this afternoon. Seems to have cleared up now. You that that is bad, try ordering a few hundred DS1s. Nathan Stratton CTO, Exario Networks, Inc. nathan at robotics.net nathan at exario.net http://www.robotics.net http://www.exario.net
Re: Links between cabinets at commercial datacentre
Hi Yes, but there isn't going to be a common practice for data centers as a whole. There's going to be a common practice for telco/fiber hotels, and a common practice for hosting centers, and a common practice for exchange points, and a common practice for shellcore, and so on. Each kind of data center drives toward its own common practice, and asking about common practices for data centers is therefore a nonquestion. in this case, it's servers, and to be more specific, mainly webservers and some ASP type stuff. Not colo-routers/networks. --Rob
Re: XO problems?
You that that is bad, try ordering a few hundred DS1s. so don't order so many ckts. that is, somewhat, part of the reason we are in this mess... if the price is so low then maybe one should look elsewhere. best price != best [company|service|deal|blah..] /rf
