January 2012 - Test - lists.nanog.org

DC wiring standards
by Leigh Porter 26 Jan '12

26 Jan '12

Hi all, Does anybody know where I can find standards for DC cabling for -48v systems? I'm looking for general best common practices, cable colouring etc. Thanks, -- Leigh Porter ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________

7 8

Re: using ULA for 'hidden' v6 devices?
by Owen DeLong 26 Jan '12

26 Jan '12

On Jan 26, 2012, at 6:39 AM, Jima wrote: > On 2012-01-26, Owen DeLong wrote: >> If you can't point to some specific advantage of ULA over secondary >> non-routed GUA prefixes, then, ULA doesn't have a reason to live. > > My biggest concern with secondary non-routed GUA would be source address > selection. If you're trying to talk to something in 2000::/3, it's > obvious to the OS that it should be using its address in 2000::/3 rather > than the one in fc00::/7. When both the "external" and "internal" > addresses live in 2000::/3, more care has to be taken to ensure the > system DTRT. > It's very easy to configure SAS to handle this. Frankly, you have the same challenge with ULA in many scenarios. >> I'm not sure where DNS64/NAT64 comes into play here for v6 to v6 >> communication. For IPv4, I don't see any advantage in ULA+NAT64 vs. the >> more reliable and easier RFC-1918 with NAT44 possibilities, even if you >> have to run multiple RFC-1918 domains to get enough addresses, that will >> generally be less complicated and break fewer things than a NAT64 >> implementation. > > My best guess there is the ability to a) only manage a single-stack > network (I really wish more software supported IPv6 so this could be a > more feasible reality), and b) use the same NAT64 prefix across various > NAT64 instances (64:ff9b::/96 is a blocker if you actually want to allow > NAT64 to RFC1918 space). While I can see the potential appeal of the > second point, I'm not sure I'd agree with it myself. > But with NAT64, you're supporting both stacks, you just move the problem around. Having done experiments with both methods, I assure you it is a true statement based on experience. NAT64 really offers more problems than it solves, not the least of which is the stateful DNS interaction problem. Owen

2 1

is it -really- global?
by bmanning＠vacation.karoshi.com 26 Jan '12

26 Jan '12

anyone keeping track of their RTTs? i'm finishing up some work on latency and all i have are my numbers. its going to be highly variable based on where you are and where you go, but it would be nice to have other sets of numbers. roughly my targets are :: 43% are "cloud" oriented - CBN stuff that tried to place bits near me 22% are US/CA targets 14% are kcj 12% are eu 4% are africaan 5% are other and the source moves, East/Best coast of the US, Africa, Japan, NZ /bill

3 2

Populating BGP from Connected or IGP routes
by Eric C. Miller 26 Jan '12

26 Jan '12

Hi all, I'm looking for a best practice sort of answer, plus maybe comments on why your network may or may not follow this. First, when running a small ISP with about the equivilent of a /18 or /19 in different blocks, how should you decide what should be in the IGP and what should be in BGP? I assume that it's somewhere between all and none, and one site that I found made some good sense saying something to the following, "Use a link-state protocol to track interconnections and loopbacks only, and place all of the networks including customer networks into BGP." Secondly, when is it ok, or preferable to utilize "redistribute connected" for gathering networks for BGP over using a network statement? I know that this influences the origin code, but past that, why else? Would it ever be permissible to redistribute from the IGP into BGP? Thanks for everyone's input! Eric Miller

5 4

Re: NANOG Digest, Vol 48, Issue 89
by Rafael Cresci 25 Jan '12

25 Jan '12

On 25/01/2012, at 20:51, nanog-request(a)nanog.org wrote: > Message: 4 > Date: Wed, 25 Jan 2012 15:11:42 -0500 (EST) > From: Jay Ashworth <jra(a)baylink.com> > To: NANOG <nanog(a)nanog.org> > Subject: Equinix Miami 1 condemnation > Message-ID: > <22786388.6606.1327522302701.JavaMail.root(a)benjamin.baylink.com> > Content-Type: text/plain; charset=utf-8 > > Last week, we saw some traffic about the Lightfiber problems because EqM1 > is apparently in a building that's been condemned by the city or county > of Miami. > > That struck me curious, so I wanted to look into it further. > > Amazingly, there doesn't seem to be any coverage of the incident, even in > technical circles. Does anyone know anything they're permitted to tell > about how a building which contained a datacenter managed to get itself > condemned? > This was the Metro Mall facility, operated by Switch and Data until > Equinix's acquisition of S&D a few years ago. It is now known as > Equinix-Miami 1. 1 NE 1st Street. > And... > The issue here has nothing to do with any hurricanes in the past. My > opinion is that they lacked proper documentation and planning. Having a > bit of insider knowledge here and knowing where this fiber came from > originally (ACSI) and how FiberLight came to acquire it, I'm fairly sure > I'm on the money. I have no NDA on this so I can talk better in details. Equinix Miami 1 (formerly Switch & Data, formerly another company name I don't recall now) was the temporary building that the NAP was built on, before moving to the current location that Terremark is (if not wrong, they called it the "T-Rex project" and the NOTA exchange started there in that place). Thus, (nearly) every major fiber strands that come from the submarine cable landing stations in SFl come into EQX MIA1 first, physically, before going into Terremark at 9th Street. The building itself (Metromall) is not a datacenter by design, it's a normal commercial building. Some handfuls of jewelry stores, coffee shop, travel agency, a hair dresser, in the lobby and ground and basement levels. The loading dock of the building is on the same alley as Equinix Miami 2 (36 NE 2nd Street/Telesource building/Telx/Colohouse/Fibermedia/Savvis) loading dock entrance. Global Crossing's datacenter also was in the Metromall at another floor before going into Terremark's 6th floor. Equinix/S&D was on the 5th floor (whole floor). They were the biggest lease there, but they had no word on the building administration or maintenance, only on their own floor, that was pretty empty (no more than two or three dozen of customers). S&D considered Miami more of a strategic network PoP than a real customer datacenter (as does Savvis, that has a full floor in the 36 NE 2nd St building, but no customers, and doesn't announce it as a datacenter/colocation PoP even having all that square footage and huge generators), they had only a small number of customers and the two facilities (MIA1 and MIA2) were acquisitions of former small/broken telco companies. They were not built by S&D, less yet by Equinix. The building failed the 40-year inspection by the city of Miami. The landlord/owner of the building decided not to fix the numerous issues that were presented by the inspectors, and then decided to just let it go, close everything, expel all stores (mostly were on monthly leases) with little to no notice, and maybe sell the building or the ruins to someone who wanted it to fix or to demolish. Equinix (or better, Switch and Data) was in negotiations with a company I worked for as an outsourced partner, to build a pipe between both buildings, when they faced a long delay on approval by the landlord, When they pressed, they got the real reason why he was holding it. Last June Equinix started to evacuate the building preemptively, moving all customers to Miami 2 (it's in the same block, just two corners or a backdoor away) and paying their moving costs (materials, manpower, telco circuit movings) up to a ceiling of $10k (in service credits, not cash, power install was covered by Equinix). They did some preparation work on Miami 2 for receiving these customers - not many - and started that, with an ETA to move everybody out by October 2011. The "secret" ingredient was more of a "let's not annouce it so no one tries to signup to Miami 1 and then take advantage of service credits", until the unavoidable was unavoidable and until Miami 2 was ready for deployment of these customers. Only the customers, partners and the Digital Realty Trust management (Miami 2 is a DRL building)/security were aware of that while the move was not completed or at least mass moved. Some competitors got to the knowledge after the customers were notified (in June 2011) and some customers leaked that information by accident or intentionally at that time. AFAIK, Fiberlight spliced all Fiber on the manhole during 3 nights in July/August 2011, to reroute them out of MIA1. What happened these couple days ago was something completely different and probably the result of something they forgot to do on that manhole, or pure stupidity of doing maintenance/upgrades on both sides of the ring at the same time. -- rc

1 0

Interesting Articles regarding more colocation space in the DC area
by Jared Scott 25 Jan '12

25 Jan '12

http://www.washingtonpost.com/business/capitalbusiness/after-dramatic-growt… http://www.datacenterknowledge.com/archives/2012/01/18/the-coming-colo-crun…

1 0

Polling Bandwidth as an Aggregate
by Keegan Holley 25 Jan '12

25 Jan '12

Has anyone had to aggregate bandwidth data from multiple interfaces for billing. For example I'd like to poll with an open source tool and aggregate data from multiple interfaces connected to the same customer or multiple customers for the purpose of billing and capacity management. Is there an easy way to do this with cacti/rrd or another open source kit? Keegan Holley ▪ Network Architect ▪ SunGard Availability Services ▪ 401 North Broad St. Philadelphia, PA 19108 ▪ (215) 446-1242 ▪ keegan.holley(a)sungard.com Keeping People and Information Connected® ▪ http://www.availability.sungard.com/ Think before you print CONFIDENTIALITY: This e-mail (including any attachments) may contain confidential, proprietary and privileged information, and unauthorized disclosure or use is prohibited. If you received this e-mail in error, please notify the sender and delete this e-mail from your system.

13 17

Equinix Miami 1 condemnation
by Jay Ashworth 25 Jan '12

25 Jan '12

Last week, we saw some traffic about the Lightfiber problems because EqM1 is apparently in a building that's been condemned by the city or county of Miami. That struck me curious, so I wanted to look into it further. Amazingly, there doesn't seem to be any coverage of the incident, even in technical circles. Does anyone know anything they're permitted to tell about how a building which contained a datacenter managed to get itself condemned? Cheers, -- jra -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274

4 3

[NANOG-announce] Lightning talks open for NANOG 54
by Greg Dendy 25 Jan '12

25 Jan '12

Submit yours now at https://pc.nanog.org/ See you in San Diego! Greg NANOG Program Committee _______________________________________________ NANOG-announce mailing list NANOG-announce(a)nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce

1 0

How are you doing DHCPv6 ?
by A. Gregory Rabil 24 Jan '12

24 Jan '12

Hello folks, I would like to chime in on this thread. I have great interest in how this plays out. The Jagornet DHCPv6 Server is capable of providing specific addresses to clients based upon DUID and IAID using a filtering mechanism supported in the configuration file. Of course, predicting what the DUID/IAID may be from various clients is still a challenge. However, if this information is available, the Jagornet DHCPv6 server can support this model. Also, specific binding reservations will soon be supported. Logging is rather extensive as well. The server is Certified IPv6 Phase II Ready. Furthermore, version 2.0 beta will be available soon, which will include support for DHCPv4! Please find the free, open-source version of the IPv6 Phase II Ready Jagornet DHCPv6 server here: http://code.google.com/p/jagornet-dhcpv6/ Best regards, Greg Rabil Jagornet Technologies, LLC.

1 0