- Test - lists.nanog.org

Most energy efficient (home) setup
by Jeroen van Aart 19 Apr '12

19 Apr '12

After reading a number of threads where people list their huge and wasteful, but undoubtedly fun (and sometimes necessary?), home setups complete with dedicated rooms and aircos I felt inclined to ask who has attempted to make a really energy efficient setup? This may be an interesting read, it uses a plugcomputer: http://www.theregister.co.uk/2010/11/11/diy_zero_energy_home_server/page2.h… Admittedly I don't have a need for a full blown home lab since I am not a network engineer, I'm more of a sysadmin/network admin/programmer kind of person... So I can make do with a somewhat minimal set up. But I *do* have tunneled IPv6 from home ;-) In my current apartment in addition to an el cheapo DSL modem that probably wastes about 10 watts and a "sometimes on" PC workstation I used to have an always on thinkpad (early 2000s model) as my main desktop system and an always on G4 system (pegasos2 in case you care) acting as a mail/web/ssh server. The thinkpad was a refurbished model and it was quite stable, up to 500 days of uptime during its last years. But the hardware slowly disintegrated and when the gfx card died I retired it. Right now my always on server is a VIA artigo 1100 pico-itx system (replacing the G4 system) and my "router/firewall/modem" is still the el cheapo DSL modem (which runs busybox by the way). I have an upgraded workstation that's "sometimes on", it has a mini itx form factor (AMD phenom2 CPU). I use debian on all systems. I haven't measured it but I think if the set up would use 30 watts continuously (only taking the always on systems into account) it'd be a lot. Of course it'll spike when I fire up the workstation. It's not extremely energy efficient but compared to some setups I read about it is. The next step would be to migrate to a plugcomputer or something similar (http://plugcomputer.org/) Any suggestions and ideas appreciated of course. :-) Thanks, Jeroen -- Earthquake Magnitude: 3.0 Date: Wednesday, February 22, 2012 13:57:33 UTC Location: Island of Hawaii, Hawaii Latitude: 19.4252; Longitude: -155.3207 Depth: 3.90 km

24 46

[IPv6] Monitoring BGP IPv6 Sesions
by Carlos Asensio 19 Apr '12

19 Apr '12

Hi all, We're trying to monitor our BGP IPv6 sessions on our 6500. * It's look like Cisco MIB's doesn't support it: o http://www.cisco.com/en/US/docs/ios-xml/ios/ipv6/configuration/12-2sx/ip6-m… * Searching on Nagios' plugins, I don't see how (I suppose it's by the reason above): o http://exchange.nagios.org/index.php?option=com_mtree&task=search&Itemid=74… Anyone can help us on that matter? Thanks in advance, Carlos.

5 5

Re: Colocation in New York for a POP
by Alex Rubenstein 19 Apr '12

19 Apr '12

25 B'way is in the process of being shuttered. ----- Original Message ----- From: Pierce Lynch <p.lynch(a)netappliant.com> To: Abdelkader Chikh Daho <achikhdaho(a)iweb.com> Cc: nanog(a)nanog.org <nanog(a)nanog.org> Sent: Thu Apr 19 11:22:17 2012 Subject: RE: Colocation in New York for a POP Abdelkader, I have had good experiences with TeleHouse America and their 25 Broadway facility, with some solid peering options - although being central New York, co-location can be a little more expensive there. As an alternative, they have an impressive facility in Staten Island, NY which I understand can accommodate for smaller requirements as well. Hope that helps... Kind regards, P. ________________________________________ From: Abdelkader Chikh Daho [achikhdaho(a)iweb.com] Sent: 19 April 2012 16:01 To: nanog(a)nanog.org Subject: Colocation in New York for a POP Hi everyone, Can some one please tell us what is the best Colo in New york to set up a POP (one cabinet) in order to get bandwidth, peering (NIIX, etc). Best regards, -- Abdelkader Chikh Daho Network Architect iWeb Technologies Email : achikhdaho(a)iweb.com Web : www.iweb.com Tel : 514-286-4242 ext 2309

1 0

Four Lit-tle Bytes (an IPv4 song)
by Aaron Davies 19 Apr '12

19 Apr '12

This is a song I've been working on on and off over the last couple years; when I sang it recently at a filk convention, I was told I should post it here. I hope it’s not too OT (or too technically inaccurate!). Sheet music, MIDI, and ABC source are available at http://songs.q-ist.com/. Four Lit-tle Bytes of Ad-dress Code by Aaron Davies ttto “Two Lit-tle Bytes” by Amy Fass after “Three Little Maids from School” by Gilbert & Sullivan chorus: Four little bytes of address code Couldn’t spare any more bandwidth load To indicate the network node Four little bytes of code Four little bytes, all allocated IPv6 is anticipated Sixteen years we’ve already waited! Four little bytes of code (chorus) Four little bytes, a space all used up Fridges and toasters IPs have chewed up When will the ISPs get clued-up? Four little bytes of code (chorus) Four little bytes, a space exhausted Plenty of room, once, but now we’ve lost it v4 is dead, man, it’s time we tossed it[1] Four little bytes of code Four little by———tes of code! Save on your subnets—four bytes! END [1] Thanks to Bob Kanefsky for the rhyme! -- Aaron Davies aaron.davies(a)gmail.com

1 0

Comcast Admin
by chk 19 Apr '12

19 Apr '12

We are having issues with one of our sites being blocked for Comcast home users and going the normal channels is not working. If there is anyone that can contact me off list to get this resolved I would appreciate it.

3 3

letter opposing cybersecurity legislation: looking for signers
by Dan Auerbach 18 Apr '12

18 Apr '12

Dear NANOGers, EFF is looking for sign-ons to a letter expressing concern about some of the proposed "cybersecurity" legislation currently being debated in the US Congress. This legislation has a number of alarming provisions, including incentives for recording massive amounts of network traffic and sharing it with federal agencies; nullification of existing wiretapping and privacy laws; in some cases, new kinds of bureaucracy for backbone and other ISPs who are designated as "critical infrastructure", and provisions that establish intellectual property enforcement as a "cybersecurity" objective. We realize this is potentially a complicated topic in the NANOG community, and we'd prefer not to start a giant OT flamewar, so: if you agree with our concerns and would like to sign on to our letter, let us know by private email by Thursday morning 9am Pacific US time. If you think we have the wrong perspective, you can let us know off-list, or write your own letters, or work with your various policy departments on this. Because there are many "cybersecurity" bills currently being debated in the US House and Senate, the letter is generally framed in opposition to bad aspects of the bills, though it calls out two current proposals that are particularly bad and close to passing: CISPA (H.R. 3523) in the House, and "Secure IT Act" (S. 2151) in the Senate. The letter also is intended to be simple and focused on the civil liberties issues that stem from the broadness of the bills. It does not talk about technical problems with deploying IDS/IPS in the private sector (for a discussion of this, see, e.g. http://harvardnsj.org/wp-content/uploads/2012/01/Vol.-3_Bellovin_Bradner_Di…) or other legitimate technical concerns about effectiveness. We certainly encourage people to raise these concerns separately. The text of the letter is below in triple quotes: """ Dear Lawmakers, We are writing you today as professionals, academics, and experts who have researched, analyzed, and defended against security threats to the Internet and its infrastructure. We have devoted our careers to building security technologies, and to protecting networks, computers, and critical infrastructure against attacks of many stripes. We take security very seriously, but we fervently believe that strong computer and network security does not require Internet users to sacrifice their privacy and civil liberties. The opposite, in fact, is true. The bills currently under consideration, including Rep. Rogers' /Cyber Intelligence Sharing and Protection Act of 2011 /(H.R. 3523) and Sen. McCain's/SECURE IT Act /(S. 2151)/, /are drafted to allow entities who participate in relaying or receiving Internet traffic to freely monitor and redistribute those network communications. The bills nullify current legal protections against wiretapping and similar civil liberties violations for that kind of broad data sharing. By encouraging the transfer of users' private communications to US Federal agencies, and lacking any form of public accountability or transparency, these "cybersecurity" bills falsely trade our civil liberties for the promise of improved network security. As experts in the field, we reject this false trade-off and urge you to oppose any cybersecurity initiative that does not explicitly include appropriate methods to ensure the protection of users' civil liberties. In summary, we urge you to reject legislation that: * Uses vague language to describe network security attacks, threat indicators, and countermeasures, allowing for the possibility that innocuous online activities could be construed as "cybersecurity" threats. * Exempts "cybersecurity" activities from existing laws that protect individuals' privacy and devices, such as the Wiretap Act, the Stored Communications Act, and the Computer Fraud and Abuse Act. * Gives sweeping immunity from liability to companies even if they violate individuals' privacy without good reason. * Allows data originally collected through "cybersecurity" programs to be used to prosecute unrelated crimes. * Includes provisions suggesting a back door for intellectual property enforcement. Computer security is too important an issue to let it be hijacked for the sectional interests of unrelated industries. We appreciate your interest in making our networks more secure, but passing legislation that suffers from the problems above would be a grave mistake for privacy and civil liberties, and will not be a step forward in making us safer. Sincerely, <signers> """ For a more detailed discussion of some of the civil liberties implications and other analyses, please see the following articles: https://www.eff.org/deeplinks/2012/03/dangerously-vague-cybersecurity-legis… https://www.eff.org/deeplinks/2012/03/rogers-cybersecurity-bill-broad-enoug… https://www.eff.org/deeplinks/2012/03/four-unanswered-questions-about-cyber… For discussions of CISPA in particular, see: https://www.eff.org/deeplinks/2012/04/cybersecurity-bill-faq-disturbing-pri… https://cyberspying.eff.org/ Sincerely, Dan Auerbach dan(a)eff.org Staff Technologist Electronic Frontier Foundation Peter Eckersley pde(a)eff.org Technology Projects Director Electronic Frontier Foundation

1 1

any sites about interent networkissue
by Deric Kwok 18 Apr '12

18 Apr '12

Hi Yesterday I have internet nework issue. I checked our interent providers but their answers are fine But the traceroute can't reach to some desintations. eg: gogle and stopped somewhere Any websites can provide about network issue Thank you

4 3

How to xconnect in 111 8th NYC
by Raphael MAUNIER 18 Apr '12

18 Apr '12

Hello, We are trying to connect our carrier in 111 8th NYC. Our carrier is located in Zayo space and we are located in Telx space. We already have our panel to Telx MMR and have a bunch of position available. Our carrier seems to be unable to connect from Zayo MMR to Telx MMR and it seems to be very complicated to both Telx and Zayo to give a real answer. The last time we had to do it, it was half xconnect to the MMR ( telx ) and the other part was Zayo to our carrier. Now, the carrier have to connect to us ( xconnect included in the price) but ZAYO claims more $$$ ( about twice the price of the other way ) and this is exactly the same path !!! So how does it work really in this building ? Honestly, telx and Zayo are doing this for year and each time it's like they are discovering the wheel ( not sure if this expression exist in English). Raphael Maunier Neo Telecoms

1 0

Re: [c-nsp] Possible T1 clocking problem.
by Andrew Koch 17 Apr '12

17 Apr '12

On 4/17/12 13:46 AM, Joseph Mays wrote: > The interface on the remote end (t1 WIC port in a 2600 shows a lot more errors, including a lot of frame errors, for the same time period. [snip] Are these T1 frame errors, or a higher level? If you believe this to be a T1 concern, you should be checking at the T1 level - "show controller T1 1/0:24" for the AS5400 and "show service-module serial x/y performance-statistics" for the WIC on the 2600. Both of these commands will display the T1 statistics in 15min intervals. If you see errors there, most HDSL4 smart-jacks have a serial port for pulling stats and levels, if they are your smart-jacks to be checking. HTH, Andy

2 1

OpenFlow @ GOOG
by Eugen Leitl 17 Apr '12

17 Apr '12

http://www.wired.com/wiredenterprise/2012/04/going-with-the-flow-google/all… Going With The Flow: Google’s Secret Switch To The Next Wave Of Networking By Steven Levy April 17, 2012 | 11:45 am | Categories: Data Centers, Networking In early 1999, an associate computer science professor at UC Santa Barbara climbed the steps to the second floor headquarters of a small startup in Palo Alto, and wound up surprising himself by accepting a job offer. Even so, Urs Hölzle hedged his bet by not resigning from his university post, but taking a year-long leave. He would never return. Hölzle became a fixture in the company — called Google. As its czar of infrastructure, Hölzle oversaw the growth of its network operations from a few cages in a San Jose co-location center to a massive internet power; a 2010 study by Arbor Networks concluded that if Google was an ISP it would be the second largest in the world (the largest is Tier 3, which services over 2,700 major corporations in 450 markets over 100,000 fiber miles.) ‘You have all those multiple devices on a network but you’re not really interested in the devices — you’re interested in the fabric, and the functions the network performs for you,’ Hölzle says. Google treats its infrastructure like a state secret, so Hölzle rarely speaks about it in public. Today is one of those rare days: at the Open Networking Summit in Santa Clara, California, Hölzle is announcing that Google essentially has remade a major part of its massive internal network, providing the company a bonanza in savings and efficiency. Google has done this by brashly adopting a new and radical open-source technology called OpenFlow. Hölzle says that the idea behind this advance is the most significant change in networking in the entire lifetime of Google. In the course of his presentation Hölzle will also confirm for the first time that Google — already famous for making its own servers — has been designing and manufacturing much of its own networking equipment as well. “It’s not hard to build networking hardware,” says Hölzle, in an advance briefing provided exclusively to Wired. “What’s hard is to build the software itself as well.” In this case, Google has used its software expertise to overturn the current networking paradigm. If any company has potential to change the networking game, it is Google. The company has essentially two huge networks: the one that connects users to Google services (Search, Gmail, YouTube, etc.) and another that connects Google data centers to each other. It makes sense to bifurcate the information that way because the data flow in each case has different characteristics and demand. The user network has a smooth flow, generally adopting a diurnal pattern as users in a geographic region work and sleep. The performance of the user network also has higher standards, as users will get impatient (or leave!) if services are slow. In the user-facing network you also need every packet to arrive intact — customers would be pretty unhappy if a key sentence in a document or e-mail was dropped. The internal backbone, in contrast, has wild swings in demand — it is “bursty” rather than steady. Google is in control of scheduling internal traffic, but it faces difficulties in traffic engineering. Often Google has to move many petabytes of data (indexes of the entire web, millions of backup copies of user Gmail) from one place to another. When Google updates or creates a new service, it wants it available worldwide in a timely fashion — and it wants to be able to predict accurately how quickly the process will take. “There’s a lot of data center to data center traffic that has different business priorities,” says Stephen Stuart, a Google distinguished engineer who specializes in infrastructure. “Figuring out the right thing to move out of the way so that more important traffic could go through was a challenge.” But Google found an answer in OpenFlow, an open source system jointly devised by scientists at Stanford and the University of California at Berkeley. Adopting an approach known as Software Defined Networking (SDN), OpenFlow gives network operators a dramatically increased level of control by separating the two functions of networking equipment: packet switching and management. OpenFlow moves the control functions to servers, allowing for more complexity, efficiency and flexibility. “We were already going down that path, working on an inferior way of doing software-defined networking,” says Hölzle. “But once we looked at OpenFlow, it was clear that this was the way to go. Why invent your own if you don’t have to?” Google became one of several organizations to sign on to the Open Networking Foundation, which is devoted to promoting OpenFlow. (Other members include Yahoo, Microsoft, Facebook, Verizon and Deutsche Telekom, and an innovative startup called Nicira.) But none of the partners so far have announced any implementation as extensive as Google’s. Why is OpenFlow so advantageous to a company like Google? In the traditional model you can think of routers as akin to taxicabs getting passengers from one place to another. If a street is blocked, the taxi driver takes another route — but the detour may be time-consuming. If the weather is lousy, the taxi driver has to go slower. In short, the taxi driver will get you there, but you don’t want to bet the house on your exact arrival time. With the software-defined network Google has implemented, the taxi situation no longer resembles the decentralized model of drivers making their own decisions. Instead you have a system like the one envisioned when all cars are autonomous, and can report their whereabouts and plans to some central repository which also knows of weather conditions and aggregate traffic information. Such a system doesn’t need independent taxi drivers, because the system knows where the quickest routes are and what streets are blocked, and can set an ideal route from the outset. The system knows all the conditions and can institute a more sophisticated set of rules that determines how the taxis proceed, and even figure whether some taxis should stay in their garages while fire trucks pass. Therefore, operators can slate trips with confidence that everyone will get to their destinations in the shortest times, and precisely on schedule. Continue reading ‘Going With The Flow: Google’s Secret Switch To The Next Wave Of Networking‘ … Making Google’s entire internal network work with SDN thus provides all sorts of advantages. In planning big data moves, Google can simulate everything offline with pinpoint accuracy, without having to access a single networking switch. Products can be rolled out more quickly. And since “the control plane” is the element in routers that most often needs updating, networking equipment is simpler and enduring, requiring less labor to service. Most important, the move makes network management much easier. By early this year, all of Google’s internal network was running on OpenFlow. ‘Soon we will able to get very close to 100 percent utilization of our network,’ Hölzle says. “You have all those multiple devices on a network but you’re not really interested in the devices — you’re interested in the fabric, and the functions the network performs for you,” says Hölzle. “Now we don’t have to worry about those devices — we manage the network as an overall thing. The network just sort of understands.” The routers Google built to accommodate OpenFlow on what it is calling “the G-Scale Network” probably did not mark not the company’s first effort in making such devices. (One former Google employee has told Wired’s Cade Metz that the company was designing its own equipment as early as 2005. Google hasn’t confirmed this, but its job postings in the field over the past few years have provided plenty of evidence of such activities.) With SDN, though, Google absolutely had to go its own way in that regard. “In 2010, when we were seriously starting the project, you could not buy any piece of equipment that was even remotely suitable for this task,” says Hotzle. “It was not an option.” The process was conducted, naturally, with stealth — even the academics who were Google’s closest collaborators in hammering out the OpenFlow standards weren’t briefed on the extent of the implementation. In early 2010, Google established its first SDN links, among its triangle of data centers in North Carolina, South Carolina and Georgia. Then it began replacing the old internal network with G-Scale machines and software — a tricky process since everything had to be done without disrupting normal business operations. As Hölzle explains in his speech, the method was to pre-deploy the equipment at a site, take down half the site’s networking machines, and hook them up to the new system. After testing to see if the upgrade worked, Google’s engineers would then repeat the process for the remaining 50 percent of the networking in the site. The process went briskly in Google’s data centers around the world. By early this year, all of Google’s internal network was running on OpenFlow. Though Google says it’s too soon to get a measurement of the benefits, Hölzle does confirm that they are considerable. “Soon we will able to get very close to 100 percent utilization of our network,” he says. In other words, all the lanes in Google’s humongous internal data highway can be occupied, with information moving at top speed. The industry considers thirty or forty percent utilization a reasonable payload — so this implementation is like boosting network capacity two or three times. (This doesn’t apply to the user-facing network, of course.) Though Google has made a considerable investment in the transformation — hundreds of engineers were involved, and the equipment itself (when design and engineering expenses are considered) may cost more than buying vendor equipment — Hölzle clearly thinks it’s worth it. Hölzle doesn’t want people to make too big a deal of the confirmation that Google is making its own networking switches — and he emphatically says that it would be wrong to conclude that because of this announcement Google intends to compete with Cisco and Juniper. “Our general philosophy is that we’ll only build something ourselves if there’s an advantage to do it — which means that we’re getting something we can’t get elsewhere.” To Hölzle, this news is all about the new paradigm. He does acknowledge that challenges still remain in the shift to SDN, but thinks they are all surmountable. If SDN is widely adopted across the industry, that’s great for Google, because virtually anything that happens to make the internet run more efficiently is a boon for the company. As for Cisco and Juniper, he hopes that as more big operations seek to adopt OpenFlow, those networking manufacturers will design equipment that supports it. If so, Hölzle says, Google will probably be a customer. “That’s actually part of the reason for giving the talk and being open,” he says. “To encourage the industry — hardware, software and ISP’s — to look down this path and say, ‘I can benefit from this.’” For proof, big players in networking can now look to Google. The search giant claims that it’s already reaping benefits from its bet on the new revolution in networking. Big time. Steven Levy Steven Levy's deep dive into Google, In The Plex: How Google Thinks, Works And Shapes Our Lives, was published in April, 2011. Steven also blogs at StevenLevy.com. Check out Steve's Google+ Profile . Read more by Steven Levy Follow @StevenLevy on Twitter.

2 1