Re: Note change in IANA registry URLs
On 2010.04.02. 6:16, Leo Vegoda wrote: On Mar 31, 2010, at 8:22 PM, Dan White wrote: […] http://www.iana.org/assignments/ipv4-address-space/ I think it's worth pointing out again that the URLs for IANA registries have changed and the old URLs, like the one above, will be going away from next week. Anyone automatically parsing the registries should make sure they adjust their scripts before then. I don't know what good reasons you might have to pull down the current URLs. Please keep them working. Recommended reading: http://www.w3.org/Provider/Style/URI Robert
Re: Note change in IANA registry URLs
On Fri, Apr 02, 2010 at 11:42:25AM +0200, Robert Kisteleki rob...@ripe.net wrote a message of 20 lines which said: I don't know what good reasons you might have to pull down the current URLs. Please keep them working. I strongly agree and, by the way, it seems this was partially mentioned in the original announcement: The old URLs will contain information for the location of the new versions available (TXT, XML and XHTML).
Books for the NOC guys...
This morning I went digging for a book to recommend that someone in our NOC read in order to understand at a high level how Internet infrastructure works (bgp, igps, etc) and discovered that the old standbys (Huitema, Halabi, Perlman) have all not been updated in a decade or so. On the one hand, they're all still quite relevant since there hasn't been anything really earth-shattering in that department, but they are all going to be lean to nonexistent on stuff like IPv6 and NLRI negotiation. So, what are you having your up-and-coming NOC staff read? Thanks, -r
Re: Books for the NOC guys...
On Apr 2, 2010, at 7:09 PM, Robert E. Seastrom wrote: So, what are you having your up-and-coming NOC staff read? http://www.amazon.com/Router-Security-Strategies-Securing-Network/dp/1587053365/ref=sr_1_2?ie=UTF8s=booksqid=1270210783sr=8-2 http://www.amazon.com/Practical-BGP-Russ-White/dp/0321127005/ref=sr_1_1?ie=UTF8s=booksqid=1270210821sr=1-1 http://www.amazon.com/TCP-Guide-Comprehensive-Illustrated-Protocols/dp/159327047X/ref=sr_1_1?ie=UTF8s=booksqid=1270210859sr=1-1 http://www.amazon.com/TCP-Illustrated-Volumes-1-3-Boxed/dp/0201776316/ref=sr_1_1?ie=UTF8s=booksqid=1270210884sr=1-1 --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
Re: Books for the NOC guys...
So, what are you having your up-and-coming NOC staff read? In an attempt to wean them off of unmanageable PERL scripts http://www.complete.org/FoundationsOfPythonNetworkProgramming There are tons of tutorials and articles on the web, often with links to other useful stuff http://www.howstuffworks.com/internet-infrastructure.htm/printable http://www.inetdaemon.com/tutorials/internet/ip/routing/bgp/troubleshooting/ And let's not forget all of the NANOG presentations. Sometimes the slides are quite good on their own but if not, the audio is there too. http://www.nanog.org/meetings/nanog29/presentations/smith.pdf I would encourage them to download PDFs, videos and websites for future reference and to share with colleagues. Also, set up a wiki, and ask them all to record any useful bits of info there and to track Recent Changes every week or so to see what colleagues are sharing. --Michael Dillon
RE: Books for the NOC guys...
So, what are you having your up-and-coming NOC staff read? While not specifically a NOC book, we find that it lays a great foundation to build from (if, perhaps, a bit basic in certain areas): Network Warrior by Gary A. Donahue http://www.amazon.com/Network-Warrior-Everything-need-wasnt/dp/0596101511/ This is a great book with an easy to read style. Tom Walsh
Re: Books for the NOC guys...
On Fri, 02 Apr 2010 08:09:29 -0400 Robert E. Seastrom r...@seastrom.com wrote: This morning I went digging for a book to recommend that someone in our NOC read in order to understand at a high level how Internet infrastructure works (bgp, igps, etc) and discovered that the old standbys (Huitema, Halabi, Perlman) have all not been updated in a decade or so. [...] So, what are you having your up-and-coming NOC staff read? That is an excellent question Rob. I still recommend and prefer to use Radia's book when I teach networking classes. There are lots of books that regurgitate the specs or spend a fair amount of time on the core algorithms and mechanisms, but few go into the why and what if like she does that makes it so exceptional and particularly relevant from an operations perspective. I often will play a clip or two from past meetings like NANOG and discuss that in class to make up for the lack of reference and discussion material elsewhere. Perhaps point them at a few of your favorite presentations on a particular operationally relevant topic you want them to know more about? John
Re: Books for the NOC guys...
On Fri, 02 Apr 2010 13:48:48 BST, Michael Dillon said: So, what are you having your up-and-coming NOC staff read? In an attempt to wean them off of unmanageable PERL scripts There is not, and there never will be, a useful programming language that makes it the least bit difficult to write totally abominable creeping-horror unmaintainable code in. The ability of a programmer to write totally obtuse code is entirely orthogonal to the choice of implementation language. Some people just don't have good taste, and will produce train wrecks in any language. Remember that it's possible to write Fortran-IV code in any language. :) Unless you teach them stuff like Document the sources and expected types of input data, add useful comments that explain your choice of algorithms rather than a++; /* Add one to A */, and If the language supports operator overloading, don't be a bozo and abuse it, the code will be unmaintainable. pgpE3Du9vFmnG.pgp Description: PGP signature
Re: Books for the NOC guys...
On 4/2/2010 08:39, valdis.kletni...@vt.edu wrote: On Fri, 02 Apr 2010 13:48:48 BST, Michael Dillon said: So, what are you having your up-and-coming NOC staff read? In an attempt to wean them off of unmanageable PERL scripts There is not, and there never will be, a useful programming language that makes it the least bit difficult to write totally abominable creeping-horror unmaintainable code in. The ability of a programmer to write totally obtuse code is entirely orthogonal to the choice of implementation language. Some people just don't have good taste, and will produce train wrecks in any language. Remember that it's possible to write Fortran-IV code in any language. :) Unless you teach them stuff like Document the sources and expected types of input data, add useful comments that explain your choice of algorithms rather than a++; /* Add one to A */, and If the language supports operator overloading, don't be a bozo and abuse it, the code will be unmaintainable. Teach them. Train them. Have standards. Enforce them (pay according to compliance). What a concept! We did that using Autocoder and COBOL. What next? Manage them? Is that even legal? -- Democracy: Three wolves and a sheep voting on the dinner menu. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
RE: Books for the NOC guys...
I just show them this: http://warriorsofthe.net/ -Scott -Original Message- From: Larry Sheldon [mailto:larryshel...@cox.net] Sent: Friday, April 02, 2010 9:46 AM To: nanog@nanog.org Subject: Re: Books for the NOC guys... On 4/2/2010 08:39, valdis.kletni...@vt.edu wrote: On Fri, 02 Apr 2010 13:48:48 BST, Michael Dillon said: So, what are you having your up-and-coming NOC staff read? In an attempt to wean them off of unmanageable PERL scripts There is not, and there never will be, a useful programming language that makes it the least bit difficult to write totally abominable creeping-horror unmaintainable code in. The ability of a programmer to write totally obtuse code is entirely orthogonal to the choice of implementation language. Some people just don't have good taste, and will produce train wrecks in any language. Remember that it's possible to write Fortran-IV code in any language. :) Unless you teach them stuff like Document the sources and expected types of input data, add useful comments that explain your choice of algorithms rather than a++; /* Add one to A */, and If the language supports operator overloading, don't be a bozo and abuse it, the code will be unmaintainable. Teach them. Train them. Have standards. Enforce them (pay according to compliance). What a concept! We did that using Autocoder and COBOL. What next? Manage them? Is that even legal? -- Democracy: Three wolves and a sheep voting on the dinner menu. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
Re: Books for the NOC guys...
On Apr 2, 2010, at 7:09 AM, Robert E. Seastrom wrote: This morning I went digging for a book to recommend that someone in our NOC read in order to understand at a high level how Internet infrastructure works (bgp, igps, etc) and discovered that the old standbys (Huitema, Halabi, Perlman) have all not been updated in a decade or so. On the one hand, they're all still quite relevant since there hasn't been anything really earth-shattering in that department, but they are all going to be lean to nonexistent on stuff like IPv6 and NLRI negotiation. So, what are you having your up-and-coming NOC staff read? Thanks, -r It kind of depends on what you want from your NOC folk and (at least a little bit) which level NOC people need the resource. In addition to the ones already listed, we encourage Tier 1 and Tier 2 people to read and understand these two books: T1: A Survival Guide http://www.amazon.com/T1-Survival-Guide-Matthew-Gast/dp/0596001274/ref=sr_1_1?ie=UTF8s=booksqid=1270216284sr=8-1 Network Maintenance and Troubleshooting Guide http://www.amazon.com/Network-Maintenance-Troubleshooting-Guide-Solutions/dp/0321647416/ref=sr_1_1?ie=UTF8s=booksqid=1270216655sr=1-1 We find these are both pretty solid resources, especially for our Tier 1 folks. Since much of what they eventually deal with are Layer 1 problems, having resources that focus on Layer 1 helps get their mind moving that direction. If we have a routing problem, that generally needs to get bumped up anyway since it means somethings misconfigured or a routing protocol is acting up. -- Brad Fleming
Re: Finding content in your job title
On 3/31/10 8:14 PM, Jorge Amodio jmamo...@gmail.com wrote: I agree with the misuse of the term Engineer in IT. I think it should only be used for the official protected title of civil engineer. Which I believe is a very respectable job. Sad but true, in IT too many people have some form of engineer in their job title but are almost totally clueless. [ X-Operational_Content = 0 ] Can't resist. When I read your message it brought back to my memory a nice guy that used to work for me eons ago, very clever, smart and hands-on, he had a Bachelor's Degree in Psychology. One day, we had some sort of outage and I found him in the computer room sitting in front of one of the racks with some routing gear, I still have that image in my memory he looked like he was doing some sort of group therapy with the routers, I couldn't resist and told him Hey Joey, Freud won't help you, get your butt off of the chair and follow the default procedure, power cycle the damn beast. There were also several folks with various degrees in Physics, experts on blowing up stuff. Again, IMHO, in this field a title may help or may provide others a relative idea where you fit in a large organization, or help the HR folks know how much to put on your paycheck or what kind of benefits/perks go associated with that level, but I still believe that substance is more important. Regards Jorge COOK Chief Old Operations Knucklehead HAH! My self chosen job title is Chief Pest, Annoyer of Developers, and Destroyer of Misconceptions. All in all, it's fairly accurate. Among other things I manage a team of developers, I often have to disabuse management of some silly idea or other, and frequently have to play gladfly to enable change.
Re: Raised floor, Solid floor... or carpet?
On Thursday 01 April 2010 02:36:56 pm telmn...@757.org wrote: Its an april fools joke for them. Dare I say that I have actually seen DCs with carpeting. My jaw dropped but it does exist. We had carpeted floor tiles in a data center where I used to work. It was bound to the raised floor panels, and I was told it had anti static properties. Never noticed a static issue, but the room had proper air handlers with humidity control. We here at PARI have 30,000 square feet of carpeted raised floor. 18,000 square feet of that is two levels of one whole wing of one of the main buildings, with recessed subfloors so there are no ramps or steps; the transition from normal to raised is seamless. A large portion of the other 12,000 square feet is, pardon the usage, 'puke yellow' in color. The 18,000 sq feet is a nice gray color. All have static draining foil and/or wires woven in the carpet for static control. Thankfully no zinc whiskers on any of ours. (I'm posting this on April 2 specifically so that statement won't be misunderstood). The puller to lift floor tiles had evil teeth, not suction cups. It could bite. Again, I'm posting this on April 2 specifically so that this won't be taken as a joke, but, PARI being in the sticks, so to speak, that is, right in the middle of the Pisgah National Forest, I've often carried a puller with me outside when going to the pickup at night, along with my flashlight (we're an observatory; there are no outside lights on at night). We have seen bobcats, coyotes, eastern cougars (rare, but around), black bears, and wild hogs; rumor has it that there are wolves within 50 miles. I've often thought one of the pullers would be a fantastic close quarters defensive non-fatal weapon.but haven't had to use one yet. I have, however, had a puller slip and get my knee before
Re: Books for the NOC guys...
Robert E. Seastrom r...@seastrom.com writes: So, what are you having your up-and-coming NOC staff read? http://www.amazon.com/Illustrated-Network-Modern-Kaufmann-Metworking/dp/0123745411/ I think it's quite good and covers many modern topics. One drawback: It mentions ethereal and not wireshark. At the time of writing ethereal must have been dead for about 2 years. Jens -- - | Foelderichstr. 40 | 13595 Berlin, Germany| +49-151-18721264 | | http://blog.quux.de | jabber: jensl...@guug.de | --- | -
Re: Books for the NOC guys...
On 4/2/10 2:09 PM, Robert E. Seastrom wrote: So, what are you having your up-and-coming NOC staff read? Practice of System and Network Administration by Limoncelli, Hogan, and Challup. I may be biased, being married to Hogan. Eliot
Re: Raised floor, Solid floor... or carpet?
On Friday 02 April 2010 10:29:10 am Lamar Owen wrote: A large portion of the other 12,000 square feet is, pardon the usage, 'puke yellow' in color. The 18,000 sq feet is a nice gray color. All have static draining foil and/or wires woven in the carpet for static control. A couple of pictures (links are each on one line): http://www.pari.edu/about_pari/pari-photos/archived-photos/volunteers/friends- of-pari-volunteer-weekend-march-28-2009/IMG_5156.JPG/view http://www.pari.edu/about_pari/pari-photos/archived-photos/volunteers/friends- of-pari-volunteer-weekend-march-28-2009/IMG_5153.JPG/view These were taken last year on the day a group of volunteers helped pull 60+ shielded Cat6 ethernet drops from the data center to the multimedia room; this was done to reduce RFI to the radio telescopes.
Re: Books for the NOC guys...
The Limoncelli etc book is brilliant. There's phil smith and barry greene's old Cisco ISP Essentials too. Very good if somewhat outdated And then there's this if you just want security - http://www.amazon.com/Router-Security-Strategies-Securing-Network/dp/1587053365/ref=sr_1_1?ie=UTF8s=booksqid=1270223489sr=1-1 On Fri, Apr 2, 2010 at 9:06 PM, Eliot Lear l...@cisco.com wrote: On 4/2/10 2:09 PM, Robert E. Seastrom wrote: So, what are you having your up-and-coming NOC staff read? Practice of System and Network Administration by Limoncelli, Hogan, and Challup. I may be biased, being married to Hogan. -- Suresh Ramasubramanian (ops.li...@gmail.com)
Re: New Linksys CPE, IPv6 ?
On Apr 1, 2010, at 2:25 PM, George Bonser wrote: I beg to differ. I know several ISPs that have been quietly putting quite a bit of engineering resource behind IPv6. The public announcement of residential IPv6 trials by Comcast was not the beginning of a serious commitment to IPv6 by Comcast, but, rather more towards the middle. Comcast has had substantial engineering resources on IPv6 for several years now. None of my transit providers currently offer native ipv6 where we are located. One recent vendor said they could tunnel 6 over 4 but any network address blocks assigned to that network would change at some point in the future. In other words, we could do v6 over 4 now but we would have to renumber later. You can get a permanent IPv6 address from the tunnel brokers at Hurricane or SIXXS. You can get an IPv6 PI Block from an RIR and route that via BGP over an HE tunnel. (Some people get upset when I say this and don't mention I work for HE. I work for HE because I think the above free services are cool and I like what they're doing with IPv6.) What I heard at a recent (within the past six months) conference was that there is no customer demand for v6 so it isn't on the immediate needs list. He said they had a lot of inquiries about v6, but to date not having native v6 wasn't a deal breaker with anyone. I watched a vendor at one conference tell 20 people in a row that each one of them was the only one asking for IPv6. I mentioned to him that he should have his short-term memory loss checked out by a physician. At first he was confused. When I pointed out what I had just seen him do, he went from confused to embarrassed and admitted that it was the party line from his marketing department and they knew IPv6 was important, but, didn't have a story to tell yet, so, they were trying to spin for delay. So my instincts tell me that until not being native v6 capable IS a deal breaker with potential clients, it isn't really going to go on the front burner. Many companies operate on the it isn't a problem until it is a problem model. It _IS_ a deal breaker for some potential clients. It _WILL_ be a deal breaker for an increasingly large number of clients over the next couple of years. I suspect that it will be less than 2 years before you see every client insisting that they need IPv6 capability RIGHT NOW. Owen
Re: Books for the NOC guys...
On Fri, Apr 2, 2010 at 6:02 AM, Express Web Systems mailingli...@expresswebsystems.com wrote: So, what are you having your up-and-coming NOC staff read? While not specifically a NOC book, we find that it lays a great foundation to build from (if, perhaps, a bit basic in certain areas): Network Warrior by Gary A. Donahue http://www.amazon.com/Network-Warrior-Everything-need-wasnt/dp/0596101511/ This is a great book with an easy to read style. +1 Network Warrior. -B
Re: Note change in IANA registry URLs
On Apr 1, 2010, at 11:42 PM, Robert Kisteleki wrote: I don't know what good reasons you might have to pull down the current URLs. Because the content has changed from arbitrary ASCII text files into more easily parseable XML and backporting to those arbitrary ASCII text files has proven too error prone and labor intensive. Regards, -drc
RE: Finding content in your job title
-Original Message- From: Jimi Thompson [mailto:jimi.thomp...@gmail.com] Sent: Friday, April 02, 2010 9:20 AM To: Jorge Amodio; Jeroen van Aart Cc: nanog@nanog.org Subject: Re: Finding content in your job title On 3/31/10 8:14 PM, Jorge Amodio jmamo...@gmail.com wrote: I agree with the misuse of the term Engineer in IT. I think it should only be used for the official protected title of civil engineer. Which I believe is a very respectable job. Sad but true, in IT too many people have some form of engineer in their job title but are almost totally clueless. [ X-Operational_Content = 0 ] Can't resist. When I read your message it brought back to my memory a nice guy that used to work for me eons ago, very clever, smart and hands-on, he had a Bachelor's Degree in Psychology. One day, we had some sort of outage and I found him in the computer room sitting in front of one of the racks with some routing gear, I still have that image in my memory he looked like he was doing some sort of group therapy with the routers, I couldn't resist and told him Hey Joey, Freud won't help you, get your butt off of the chair and follow the default procedure, power cycle the damn beast. There were also several folks with various degrees in Physics, experts on blowing up stuff. Again, IMHO, in this field a title may help or may provide others a relative idea where you fit in a large organization, or help the HR folks know how much to put on your paycheck or what kind of benefits/perks go associated with that level, but I still believe that substance is more important. Regards Jorge COOK Chief Old Operations Knucklehead HAH! My self chosen job title is Chief Pest, Annoyer of Developers, and Destroyer of Misconceptions. All in all, it's fairly accurate. Among other things I manage a team of developers, I often have to disabuse management of some silly idea or other, and frequently have to play gladfly to enable change. When I call a company and ask for an accountant, I get the companies accountant, when I ask for an account manager, that's what I get. That's what titles are, and that's why they are important. I know the type of person I need to talk to, but I don't know who it is I need to talk to. Its why standardization in titles is good, when I go digging through my pile of business cards looking for the Network Engineer/Architect at company X, I'll probably not notice a custom/weird title. It does not define you, it does not make you any less or more important, it does however answer the question of Who is responsible for... which I believe to be extremely valuable. Then again, I might be weird. ~J
Re: Note change in IANA registry URLs
On 2 Apr 2010, at 2:53, Stephane Bortzmeyer wrote: On Fri, Apr 02, 2010 at 11:42:25AM +0200, Robert Kisteleki rob...@ripe.net wrote a message of 20 lines which said: I don't know what good reasons you might have to pull down the current URLs. Please keep them working. I strongly agree and, by the way, it seems this was partially mentioned in the original announcement: The old URLs will contain information for the location of the new versions available (TXT, XML and XHTML). Yes, I was not as clear as I should have been. The URLs will continue to exist but the current content will go away and be replaced with a short file explaining where to find it. Regards, Leo
Re: Note change in IANA registry URLs
On 2010.04.02. 18:16, David Conrad wrote: On Apr 1, 2010, at 11:42 PM, Robert Kisteleki wrote: I don't know what good reasons you might have to pull down the current URLs. Because the content has changed from arbitrary ASCII text files into more easily parseable XML and backporting to those arbitrary ASCII text files has proven too error prone and labor intensive. Regards, -drc You're confusing two things: URL and content. According to the announcement, TXT files will be generated still. Why, again, must the URL change? Robert
Re: Finding content in your job title
On Friday 02 April 2010 12:25:12 pm Justin Horstman wrote: [Your title] does however answer the question of Who is responsible for... which I believe to be extremely valuable. Then again, I might be weird. No, this is exactly how 'business at large' uses the idea of title. In some companies, Official Title is used to determine salary (or even whether you're an exempt employee or not). And the company's bylaws may invest particular responsibilities and privileges on particular people by title. Secretary, for instance, is a particular title used in bylaws for a particular purpose for an officer of the company. When troubleshooting an operational issue, which do you prefer: traceroutes with useful interface names (so you can locate them) or cutesy names? Would you prefer (for your eyes, of course; you do run split DNS, right?) POS1/0 on a 7206 used for PE in the data center be called pos1-0.dc1-7206- pe.example.com, or bhp.example.com (BHP=Big Honking Pipe)? I know, you might prefer bhp.example.com for other people's eyes, but suppose you didn't name it that, you're new on the job, the guy who named it is not available, and you are having problems. Then which is your preference? I guess what you want your title to be depends on what your role actually is in the company, and whether someone outside (or someone inside who doesn't know you) can find you when they need to using the company's directory or a second or third-hand business card (yes, I've done that too, make a photocopy or e-copy of a business card, and then pass it along to a third-party (after getting card holder's permission to do so) as a contact). Or when putting a card under the acrylic sheeting on the tables in a local restaurant (I've actually made useful connections reading the business cards on corkboards and under the Plexiglas at restaurants before). We have standardized abuse, postmaster, and webmaster e-mail aliases, too, and that works when you see a slow brute-forcer originating from somewhere, or someone has blackholed someone and their BGP announcements leak, or whatever. It's nice to get to the right person when you don't know the person, don't know the company, and don't have time to get 'into' the culture. So, I guess that your title should at least semi-adequately give your role to someone who is completely clueless about your role.
Re: Books for the NOC guys...
On Friday 02 April 2010 11:36:53 am Eliot Lear wrote: Practice of System and Network Administration by Limoncelli, Hogan, and Challup. I may be biased, being married to Hogan. +1 on PSNA. I like it as much for its non-technical content as for its technical content (a similar book, by Limncelli, Time Management for System Administrators is also on my shelf, with great non-technical content, and should be a must-read for any technical personnel, IMO). +1 also on Network Warrior, although not for everything. I also have 'Cisco Network Professional's Advanced Internetworking Guide' by Patrick J. Conlan, published by Sybex. Comes with the full text on CD in PDF form, too. The URL is pretty long, so use the search on sybex.com to find it. Here's the ToC: 1. Enterprise Network Design. 2. Switching. 3. Spanning Tree Protocol (STP). 4. Routing Concepts and Distance Vector Routing Protocols. 5. Advanced Distance Vector Protocols. 6. Link State Routing Protocols. 7. Exterior Routing Protocols. 8. Multicast. 9. IP Version 6. 10. Redundancy Protocols. 11. WAN and Teleworker Connections. 12. Virtual Private Networks (VPN). 13. Device Security. 14. Switch Security. 15. Cisco IOS Firewall. 16. Cisco IOS IPS. 17. Voice. 18. DiffServ Quality of Service (QOS). 19. Wireless Devices and Topologies. 20. Wireless Management and Security. Which pretty much, I think, covers the bases asked about in the OP. The copyright is May 2009, so it's not too bad out of date.
Re: Books for the NOC guys...
On 02/04/2010 14:39, valdis.kletni...@vt.edu wrote: On Fri, 02 Apr 2010 13:48:48 BST, Michael Dillon said: So, what are you having your up-and-coming NOC staff read? In an attempt to wean them off of unmanageable PERL scripts There is not, and there never will be, a useful programming language that makes it the least bit difficult to write totally abominable creeping-horror unmaintainable code in. +n Whatever language you write in, your task as a programmer is to do the best you can with the tools at hand. A good programmer can overcome a poor language or a clumsy operating system, but even a great programming environment will not rescue a bad programmer. (Kernighan and Pike) Although language zealots are loth to admit it, certain languages are better suited to some things than to others. Perl's syntactical support for text processing are second to none, but for web stuff, it's hideous. PHP stinks on the command line and text processing, yet its web integration makes it a good candidate for small web projects. Shell scripts are designed specifically for command line tool management, pipes and all that sort of thing, and just because other languages support popen() and system, that doesn't necessarily make them good choices for stuff which involves unix scripting. I write readable and maintainable code in all three. Java elicits strong reactions. No doubt, you can use Java plumbing libraries to scale to impressively large systems. On the other hand, Cisco Configuration Professional (the new SDM) provides an excellent example of how badly you can screw up a good idea by using the wrong tool - I'm not interesting in using or recommending a desktop tool which takes 2 minutes to start on a fast computer. You can write unimaginably awful code in python and ruby, and irrtoolset's code is a prime example of what you can do with c++. Yet, we all acknowledge that python, ruby and c++ are high quality languages. In short: less zealotry, more pragmatism and a realisation that each language has its own strengths and weaknesses. Bad code is bad code in any language. Nick
Re: Important: IPv4 Future Allocation Concept RFC
On Thu, Apr 1, 2010 at 6:41 PM, Joe Greco jgr...@ns.sol.net wrote: Someone suggested this be posted more visibly. Joe, Been there, done that: http://bill.herrin.us/network/ipxl.html Maybe the humor was too subtle... -Bill -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Books for the NOC guys...
On 04/02/2010 10:43 AM, Nick Hilliard wrote: In short: less zealotry, more pragmatism and a realisation that each language has its own strengths and weaknesses. Bad code is bad code in any language. All true, but I'd still say there's a special rung in hell for bad perl. Mike
Re: Books for the NOC guys...
Once upon a time, Michael Thomas m...@mtcc.com said: All true, but I'd still say there's a special rung in hell for bad perl. Ehh, bad perl is still more readable than good APL. At least I can reformat the perl! :-) -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
RE: Books for the NOC guys...
Well, speaking as one who wrote an ISP-specific, although not NOC-specific book about a decade ago, it doesn't seem as if there is a commercial motivation to update them. For the record, it's _Building Service Provider Networks_ (Wiley, 2001), and I'm proud of it. Nevertheless, I'm not opposed to trying to create updated open-source guidance. I do a good deal of work with http://en.citizendium.org, a real-name Wiki that is trying to reach critical mass. Anybody interested in collaborating? I'd actually started more on RPSL and peering than first-tier ops, but hadn't done anything more for lack of activity there. Certainly, I could port some of my NANOG tutorials, not that I have the PPT for many but just the PDF. -Original Message- From: Robert E. Seastrom [mailto:r...@seastrom.com] Sent: Friday, April 02, 2010 8:09 AM To: nanog@nanog.org Subject: Books for the NOC guys... This morning I went digging for a book to recommend that someone in our NOC read in order to understand at a high level how Internet infrastructure works (bgp, igps, etc) and discovered that the old standbys (Huitema, Halabi, Perlman) have all not been updated in a decade or so. On the one hand, they're all still quite relevant since there hasn't been anything really earth-shattering in that department, but they are all going to be lean to nonexistent on stuff like IPv6 and NLRI negotiation. So, what are you having your up-and-coming NOC staff read? Thanks, -r
Re: Books for the NOC guys...
On Fri, Apr 2, 2010 at 10:53 AM, Chris Adams cmad...@hiwaay.net wrote: Once upon a time, Michael Thomas m...@mtcc.com said: All true, but I'd still say there's a special rung in hell for bad perl. Ehh, bad perl is still more readable than good APL. At least I can reformat the perl! :-) In my experience bad perl usually consists of using system() a lot to run shell commands and read the input. Creative well-written perl, now there's something unreadable and unmaintainable! :-) -B
Re: Books for the NOC guys...
It's the same level reserved for child molesters and people who talk at the theater... Michael Thomas wrote: On 04/02/2010 10:43 AM, Nick Hilliard wrote: In short: less zealotry, more pragmatism and a realisation that each language has its own strengths and weaknesses. Bad code is bad code in any language. All true, but I'd still say there's a special rung in hell for bad perl. Mike No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.800 / Virus Database: 271.1.1/2785 - Release Date: 04/01/10 23:32:00 -- -Prediction is very difficult, especially about the future. -Niels Bohr -- Ray Sanders Linux Administrator Village Voice Media Office: 602-744-6547 Cell: 602-300-4344
Re: Books for the NOC guys...
Aside from the ones already mentioned, troubleshooting books are a great asset, also. Here are some of my favorites: http://www.amazon.com/Network-Analysis-Troubleshooting-Scott-Haugdahl/dp/0201433192/ http://www.amazon.com/Troubleshooting-Campus-Networks-Practical-Protocols/dp/0471210137/ http://www.amazon.com/Network-Maintenance-Troubleshooting-Guide-Solutions/dp/0321647416/ - just ordered the 2nd edition, after having browsed it at a friend ***Stefan Mititelu http://twitter.com/netfortius http://www.linkedin.com/in/netfortius On Fri, Apr 2, 2010 at 9:02 AM, Express Web Systems mailingli...@expresswebsystems.com wrote: So, what are you having your up-and-coming NOC staff read? While not specifically a NOC book, we find that it lays a great foundation to build from (if, perhaps, a bit basic in certain areas): Network Warrior by Gary A. Donahue http://www.amazon.com/Network-Warrior-Everything-need-wasnt/dp/0596101511/ This is a great book with an easy to read style. Tom Walsh
Re: Books for the NOC guys...
While not the stevens book, the illustrated network isbn 978-0-12-374541-5 was a pretty good attempt to do a modern version of the same. any book that attempts to cover all layers of the stack is going to have it's limits, but it has saved my bacon a couple of times now... The author is normally a juniper press author and as a result the examples that aren't done on freebsd or linux systems are done on junos which is either a benifit or a drawback depending on your environment. disclaimer, I did review it for content/accuracy, but wasn't compensated for doing so. joel On 04/02/2010 05:09 AM, Robert E. Seastrom wrote: This morning I went digging for a book to recommend that someone in our NOC read in order to understand at a high level how Internet infrastructure works (bgp, igps, etc) and discovered that the old standbys (Huitema, Halabi, Perlman) have all not been updated in a decade or so. On the one hand, they're all still quite relevant since there hasn't been anything really earth-shattering in that department, but they are all going to be lean to nonexistent on stuff like IPv6 and NLRI negotiation. So, what are you having your up-and-coming NOC staff read? Thanks, -r
Weekly Routing Table Report
This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-st...@lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith pfsi...@gmail.com. Routing Table Report 04:00 +10GMT Sat 03 Apr, 2010 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary BGP routing table entries examined: 316610 Prefixes after maximum aggregation: 146298 Deaggregation factor: 2.16 Unique aggregates announced to Internet: 154026 Total ASes present in the Internet Routing Table: 33705 Prefixes per ASN: 9.39 Origin-only ASes present in the Internet Routing Table: 29263 Origin ASes announcing only one prefix: 14300 Transit ASes present in the Internet Routing Table:4442 Transit-only ASes present in the Internet Routing Table:102 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 24 Max AS path prepend of ASN (32374) 19 Prefixes from unregistered ASNs in the Routing Table: 1001 Unregistered ASNs in the Routing Table: 155 Number of 32-bit ASNs allocated by the RIRs:506 Prefixes from 32-bit ASNs in the Routing Table: 522 Special use prefixes present in the Routing Table:0 Prefixes being announced from unallocated address space:231 Number of addresses announced to Internet: 2193892480 Equivalent to 130 /8s, 196 /16s and 36 /24s Percentage of available address space announced: 59.2 Percentage of allocated address space announced: 65.7 Percentage of available address space allocated: 90.0 Percentage of address space in use by end-sites: 82.0 Total number of prefixes smaller than registry allocations: 151724 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes:75943 Total APNIC prefixes after maximum aggregation: 26376 APNIC Deaggregation factor:2.88 Prefixes being announced from the APNIC address blocks: 72600 Unique aggregates announced from the APNIC address blocks:31920 APNIC Region origin ASes present in the Internet Routing Table:3990 APNIC Prefixes per ASN: 18.20 APNIC Region origin ASes announcing only one prefix: 1098 APNIC Region transit ASes present in the Internet Routing Table:620 Average APNIC Region AS path length visible:3.6 Max APNIC Region AS path length visible: 15 Number of APNIC addresses announced to Internet: 507205440 Equivalent to 30 /8s, 59 /16s and 87 /24s Percentage of available APNIC address space announced: 79.6 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 1/8, 27/8, 43/8, 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes:132528 Total ARIN prefixes after maximum aggregation:68590 ARIN Deaggregation factor: 1.93 Prefixes being announced from the ARIN address blocks: 105688 Unique aggregates announced from the ARIN address blocks: 40308 ARIN Region origin ASes present in the Internet Routing Table:13615 ARIN Prefixes per ASN: 7.76 ARIN Region origin ASes announcing only one prefix:5276 ARIN Region transit ASes present in the Internet Routing Table:1352 Average ARIN Region AS path length visible: 3.4 Max ARIN Region AS path length visible: 22 Number of ARIN addresses announced to Internet: 724817568 Equivalent to 43 /8s, 51 /16s and 214 /24s Percentage of available ARIN address space
Re: Books for the NOC guys...
In short: less zealotry, more pragmatism and a realisation that each language has its own strengths and weaknesses. Bad code is bad code in any language. All true, but I'd still say there's a special rung in hell for bad perl. And it is exacerbated by the huge volume of bad PERL books out there and the fact that entry level NOC monkeys often get the idea that PERL is cool and therefore learn it as their first and only language without a lot of critical thinking. Also, please note that the original request was for books, or in other words documents containing guidance. I supplied the name of such a document providing guidance using Python. If someone wanted to play the game and trump me, then they would quote the title of another book, or at least a substantial website tutorial, that uses another programming language. --Michael Dillon
Re: Books for the NOC guys...
On Apr 2, 2010, at 1:53 44PM, Chris Adams wrote: Once upon a time, Michael Thomas m...@mtcc.com said: All true, but I'd still say there's a special rung in hell for bad perl. Ehh, bad perl is still more readable than good APL. At least I can reformat the perl! :-) -- Oh, I don't know about that -- you an often reformat APL, too. Just because something can be written in one line doesn't mean it should be! And bad APL -- well, that's produced either by people who are trying to be too clever, or who haven't grokked APL's array-as-a-whole philosophy, and try to use its (very poor) looping or conditional control flow primitives. --Steve Bellovin, http://www.cs.columbia.edu/~smb
Re: Books for the NOC guys...
On Fri, Apr 2, 2010 at 8:36 AM, Eliot Lear l...@cisco.com wrote: On 4/2/10 2:09 PM, Robert E. Seastrom wrote: So, what are you having your up-and-coming NOC staff read? Practice of System and Network Administration by Limoncelli, Hogan, and Challup. I may be biased, being married to Hogan. Chalup with one L (though of course she didn't have that name when you and I first met her...) -- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
legacy /8
I am curious. Once we're nearing exhausting all IPv4 space will there ever come a time to ask/demand/force returning all these legacy /8 allocations? I think I understand the difficulty in that, but then running out of IPs is also a difficult issue. :-) For some reason I sooner see all IPv4 space being exhausted than IPv6 being actually implemented globally. Greetings, Jeroen
Re: legacy /8
On Fri, Apr 02, 2010 at 02:01:45PM -0700, Jeroen van Aart wrote: I am curious. Once we're nearing exhausting all IPv4 space will there ever come a time to ask/demand/force returning all these legacy /8 allocations? I think I understand the difficulty in that, but then running out of IPs is also a difficult issue. :-) For some reason I sooner see all IPv4 space being exhausted than IPv6 being actually implemented globally. Because it's no more than a delaying action. Even presuming you get people to cooperate (and they really, have no incentive to because they don't necessarily have any agreement covering the space with the RIRs) rather than fire up their legal department A couple of /8s doesn't last long enough to really make a dent in the pain. You might buy yourself a few months at most. It might actually do more harm than good, by convincing people that they can still get v4 space rather than worry about what they are going to do in the future. --msa
Re: legacy /8
Hmmm... it is 2pm on a Friday afternoon. I guess it's the appropriate time for this thread. *grabs popcorn and sits back to watch the fun*
Re: Books for the NOC guys...
On Friday 02 April 2010 04:08:03 pm Michael Dillon wrote: If someone wanted to play the game and trump me, then they would quote the title of another book, or at least a substantial website tutorial, that uses another programming language. I wish I could reply to this yesterday Then, I would have simply pointed to http://www.catb.org/~esr/intercal/intercal.ps.gz and let that hang out there for a while. One of the finest examples of a write-only language. Or, better yet, I could point you to a non-April 1st CGI programming example: http://www.fcc.gov/mb/audio/bickel/archive/colorit-fortran-get-cgi-example.txt Please at least look at that last link even if you already know better than to read the PostScript document at the first link. Look at where the CGI example came from, and consider doing something like rancid in either of those two languages. There is worse out there than perl. Also consider that the second link was originally written for VAX/VMS. I've personally used expect (and the tcl underpinnings) for a number of years, but I wouldn't call it very readable. If you want to force people to write things that are readable, choose COBOL. See http://theamericanprogrammer.com/books/books.cobol.shtml for a list of pertinent books. Having said all that, I'll agree with Michael on using Python, as it is very readable even when you try to obfuscate it, thanks in no small part to the whole 'indentation is significant' design decision.
Re: legacy /8
Must resist urge to bash v6... must start weekend... must turn off computer for my own good. On Fri, Apr 2, 2010 at 6:08 PM, Charles N Wyble char...@knownelement.com wrote: Hmmm... it is 2pm on a Friday afternoon. I guess it's the appropriate time for this thread. *grabs popcorn and sits back to watch the fun*
Re: legacy /8
On Fri, Apr 2, 2010 at 15:01, Jeroen van Aart jer...@mompl.net wrote: I am curious. Once we're nearing exhausting all IPv4 space will there ever come a time to ask/demand/force returning all these legacy /8 allocations? snip Legacy vs RIR allocated/assigned space is not a proper distinction, in-use vs not-in-use is a much better defining line for this debate. Folks have been asked to return unused space for quite some time now, see https://tools.ietf.org/html/rfc1917. Unless/until governments get involved, there is no one to demand or force the return of any space. If that happens, we likely all lose. Greetings, Jeroen -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.coisoc.org
Re: legacy /8
On 4/2/2010 16:08, Charles N Wyble wrote: Hmmm... it is 2pm on a Friday afternoon. I guess it's the appropriate time for this thread. *grabs popcorn and sits back to watch the fun* While it is true that this is likely to be one of the less productive windmill jousts. I used to work for a holder of a /16 and strongly believe that they (because of NAT-for-security and other reasons) actually using a small fraction of the /16, and that that is being used is largely miss-managed. Ob. declaration--I was fired from that organization for being too old. -- Democracy: Three wolves and a sheep voting on the dinner menu. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
BGP Update Report
BGP Update Report Interval: 25-Mar-10 -to- 01-Apr-10 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS30890 43018 4.0% 95.6 -- EVOLVA Evolva Telecom s.r.l. 2 - AS845214685 1.4% 22.5 -- TEDATA TEDATA 3 - AS982912720 1.2% 20.4 -- BSNL-NIB National Internet Backbone 4 - AS33475 11273 1.0% 48.0 -- RSN-1 - RockSolid Network, Inc. 5 - AS764311138 1.0% 36.4 -- VNPT-AS-VN Vietnam Posts and Telecommunications (VNPT) 6 - AS28477 10394 1.0%1154.9 -- Universidad Autonoma del Esstado de Morelos 7 - AS358059516 0.9% 15.5 -- UTG-AS United Telecom AS 8 - AS124798925 0.8% 207.6 -- UNI2-AS Uni2 - Lince telecomunicaciones 9 - AS260258497 0.8%8497.0 -- COC - City of Calgary 10 - AS165698082 0.8%8082.0 -- ASN-CITY-OF-CALGARY - City of Calgary 11 - AS1785 5828 0.5% 3.5 -- AS-PAETEC-NET - PaeTec Communications, Inc. 12 - AS5800 5751 0.5% 29.5 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 13 - AS8151 5649 0.5% 6.0 -- Uninet S.A. de C.V. 14 - AS270665520 0.5% 22.2 -- DNIC-ASBLK-27032-27159 - DoD Network Information Center 15 - AS337765402 0.5% 20.6 -- STARCOMMS-ASN 16 - AS179745303 0.5% 9.1 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 17 - AS111395060 0.5% 10.4 -- CWRIN CW BARBADOS 18 - AS201154962 0.5% 7.1 -- CHARTER-NET-HKY-NC - Charter Communications 19 - AS6713 4925 0.5% 41.4 -- IAM-AS 20 - AS4847 4661 0.4% 66.6 -- CNIX-AP China Networks Inter-Exchange TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS260258497 0.8%8497.0 -- COC - City of Calgary 2 - AS165698082 0.8%8082.0 -- ASN-CITY-OF-CALGARY - City of Calgary 3 - AS422142868 0.3%2868.0 -- IWC-AS SC International Work Company SRL 4 - AS28477 10394 1.0%1154.9 -- Universidad Autonoma del Esstado de Morelos 5 - AS5691 2250 0.2%1125.0 -- MITRE-AS-5 - The MITRE Corporation 6 - AS22395 596 0.1% 596.0 -- GHCO-INTERNAP - Goldenberg Hehmeyer 7 - AS327941120 0.1% 560.0 -- ICFG - International Church of the Foursquare Gospel 8 - AS3 518 0.1% 18.0 -- LASERCRAFT Ural Electronics Factory Ltd. 9 - AS53353 920 0.1% 460.0 -- PROGRAMMERSAS1234 - Programmers Investment Corp 10 - AS35291 781 0.1% 390.5 -- ICOMM-AS SC Internet Communication Systems SRL 11 - AS38820 382 0.0% 382.0 -- THAIDEVINSURANCE-CSLOXINFO-AS-TH CSLOXINFO Project for Thai Development Insurance 12 - AS45960 359 0.0% 359.0 -- YTLCOMMS-AS-AP YTL COMMUNICATIONS SDN BHD 13 - AS104452132 0.2% 355.3 -- HTG - Huntleigh Telcom 14 - AS28052 345 0.0% 345.0 -- Arte Radiotelevisivo Argentino 15 - AS11613 332 0.0% 332.0 -- U-SAVE - U-Save Auto Rental of America, Inc. 16 - AS196474550 0.4% 303.3 -- HPOD20001 - Hewlett-Packard Operation Division 17 - AS259693359 0.3% 279.9 -- SLU - St. Louis University 18 - AS21135 521 0.1% 260.5 -- MTT-AS MTT AS (Russia) 19 - AS37932 230 0.0% 230.0 -- RMUTI-AS-AP Rajamangala University of Technology Isan 20 - AS9475 230 0.0% 230.0 -- WU-TH-AP Walailuk University TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 200.13.36.0/2410306 0.9% AS28477 -- Universidad Autonoma del Esstado de Morelos 2 - 208.98.231.0/248497 0.7% AS26025 -- COC - City of Calgary 3 - 208.98.230.0/248082 0.7% AS16569 -- ASN-CITY-OF-CALGARY - City of Calgary 4 - 85.60.194.0/23 2909 0.2% AS12479 -- UNI2-AS Uni2 - Lince telecomunicaciones 5 - 89.42.72.0/21 2868 0.2% AS42214 -- IWC-AS SC International Work Company SRL 6 - 206.184.16.0/242826 0.2% AS174 -- COGENT Cogent/PSI 7 - 222.255.186.0/25 2702 0.2% AS7643 -- VNPT-AS-VN Vietnam Posts and Telecommunications (VNPT) 8 - 203.162.118.128/ 2677 0.2% AS7643 -- VNPT-AS-VN Vietnam Posts and Telecommunications (VNPT) 11 - 85.60.192.0/23 2269 0.2% AS12479 -- UNI2-AS Uni2 - Lince telecomunicaciones 12 - 192.12.120.0/242245 0.2% AS5691 -- MITRE-AS-5 - The MITRE Corporation 13 - 93.81.216.0/22 2018 0.2% AS8402 -- CORBINA-AS Corbina Telecom 14 - 85.204.64.0/23 1831 0.2% AS6746 -- ASTRAL UPC Romania Srl, Romania 15 - 143.138.107.0/24 1805 0.1% AS747 -- TAEGU-AS - Headquarters, USAISC 16 - 165.134.1.0/24 1665 0.1% AS25969 -- SLU - St. Louis
Re: legacy /8
I also just got a fresh box of popcorn. I will sit by and wait for Jeroen to do a business analysis and tell me the return on investment. (Assuming that he can find any legal grounds for demanding return of legacy /8 allocations.) All of the analysis results I have seen mention figuratively beating oneself [..painfully..] with combat boots. Running out of IP addresses is not a soon realized scenario for IPv6. If an organization runs out of IP addresses, the difficulty is with top management, not the network or address space. I think this is a many-iterated discussion, also know by some as a rathole. On Apr 2, 2010, at 5:01 PM, Jeroen van Aart wrote: I am curious. Once we're nearing exhausting all IPv4 space will there ever come a time to ask/demand/force returning all these legacy /8 allocations? I think I understand the difficulty in that, but then running out of IPs is also a difficult issue. :-) For some reason I sooner see all IPv4 space being exhausted than IPv6 being actually implemented globally. Greetings, Jeroen James R. Cutler james.cut...@consultant.com
The Cidr Report
This report has been generated at Fri Apr 2 21:11:30 2010 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
26-03-10318754 195266
27-03-10318878 195578
28-03-10318925 195640
29-03-10318973 195849
30-03-10319150 195752
31-03-10318826 196124
01-04-10319366 196113
02-04-10319323 196230
AS Summary
34044 Number of ASes in routing system
14531 Number of ASes announcing only one prefix
4414 Largest number of prefixes announced by an AS
AS4323 : TWTC - tw telecom holdings, inc.
96812544 Largest address span announced by an AS (/32s)
AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 02Apr10 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 319114 196172 12294238.5% All ASes
AS6389 4055 315 374092.2% BELLSOUTH-NET-BLK -
BellSouth.net Inc.
AS4323 4414 1309 310570.3% TWTC - tw telecom holdings,
inc.
AS4766 1837 492 134573.2% KIXS-AS-KR Korea Telecom
AS4755 1298 195 110385.0% TATACOMM-AS TATA
Communications formerly VSNL
is Leading ISP
AS22773 1139 75 106493.4% ASN-CXA-ALL-CCI-22773-RDC -
Cox Communications Inc.
AS1785 1751 706 104559.7% AS-PAETEC-NET - PaeTec
Communications, Inc.
AS18566 1059 33 102696.9% COVAD - Covad Communications
Co.
AS17488 1307 340 96774.0% HATHWAY-NET-AP Hathway IP Over
Cable Internet
AS8151 1537 623 91459.5% Uninet S.A. de C.V.
AS7545 1097 240 85778.1% TPG-INTERNET-AP TPG Internet
Pty Ltd
AS10620 1027 184 84382.1% Telmex Colombia S.A.
AS19262 1087 246 84177.4% VZGNI-TRANSIT - Verizon
Internet Services Inc.
AS6478 1179 428 75163.7% ATT-INTERNET3 - ATT WorldNet
Services
AS18101 759 53 70693.0% RIL-IDC Reliance Infocom Ltd
Internet Data Centre,
AS24560 873 240 63372.5% AIRTELBROADBAND-AS-AP Bharti
Airtel Ltd., Telemedia
Services
AS5668 808 192 61676.2% AS-5668 - CenturyTel Internet
Holdings, Inc.
AS4808 843 243 60071.2% CHINA169-BJ CNCGROUP IP
network China169 Beijing
Province Network
AS4804 678 84 59487.6% MPX-AS Microplex PTY LTD
AS4134 1027 435 59257.6% CHINANET-BACKBONE
No.31,Jin-rong Street
AS7303 700 109 59184.4% Telecom Argentina S.A.
AS7018 1568 1000 56836.2% ATT-INTERNET4 - ATT WorldNet
Services
AS8452 890 346 54461.1% TEDATA TEDATA
AS17908 772 234 53869.7% TCISL Tata Communications
AS3356 1228 699 52943.1% LEVEL3 Level 3 Communications
AS35805 612 96 51684.3% UTG-AS United Telecom AS
AS4780 654 155 49976.3% SEEDNET Digital United Inc.
AS22047 541 47 49491.3% VTR BANDA ANCHA S.A.
AS17676 572 84 48885.3% GIGAINFRA Softbank BB Corp.
AS9443 555 74 48186.7% INTERNETPRIMUS-AS-AP Primus
Telecommunications
AS7738 477 30 44793.7% Telecomunicacoes da Bahia S.A.
Total 36344 93072703774.4% Top 30 total
Possible Bogus Routes
2.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project
2.1.0.0/21 AS12654
Re: legacy /8
Sigh... Guess you missed the last several go-arounds of Running out of IPv4 will create some hardships. That cannot be avoided. Even if we were to reclaim the supposed unused legacy /8s, we'd still only extend the date of IPv4 runout by a few months. The amount of effort required to reclaim those few IPv4 addresses would vastly exceed the return on that effort. Far better for that effort to be directed towards the addition of IPv6 capabilities to existing IPv4 deployments so as to minimize the impact of IPv4 exhaustion. Owen On Apr 2, 2010, at 2:01 PM, Jeroen van Aart wrote: I am curious. Once we're nearing exhausting all IPv4 space will there ever come a time to ask/demand/force returning all these legacy /8 allocations? I think I understand the difficulty in that, but then running out of IPs is also a difficult issue. :-) For some reason I sooner see all IPv4 space being exhausted than IPv6 being actually implemented globally. Greetings, Jeroen
Re: legacy /8
On Apr 2, 2010, at 2:16 PM, Chris Grundemann wrote: On Fri, Apr 2, 2010 at 15:01, Jeroen van Aart jer...@mompl.net wrote: I am curious. Once we're nearing exhausting all IPv4 space will there ever come a time to ask/demand/force returning all these legacy /8 allocations? snip Legacy vs RIR allocated/assigned space is not a proper distinction, in-use vs not-in-use is a much better defining line for this debate. True, but... Folks have been asked to return unused space for quite some time now, see https://tools.ietf.org/html/rfc1917. Also true. Unless/until governments get involved, there is no one to demand or force the return of any space. If that happens, we likely all lose. This is where Legacy vs. RIR becomes meaningful. Legacy holders have no contractual obligation to return unused space. RIR recipients, on the other hand, do. Owen
RE: legacy /8
Owen DeLong wrote: The amount of effort required to reclaim those few IPv4 addresses would vastly exceed the return on that effort. Far better for that effort to be directed towards the addition of IPv6 capabilities to existing IPv4 deployments so as to minimize the impact of IPv4 exhaustion. Maybe encourage people like Apple, Xerox, HP or Ford to migrate their operations completely to IPv6 and return their /8? j
Re: legacy /8
On Fri, Apr 02, 2010 at 05:19:12PM -0500, Joe Johnson wrote: Maybe encourage people like Apple, Xerox, HP or Ford to migrate their operations completely to IPv6 and return their /8? How are they going to completely migrate to v6 while there is a demand for v4 space (specifically, THEIR v4 space.)? As long as the beast is getting fed, there will be customers without v6, and they're not going to isolate themselves for the commercial benefit of an unrelated third party. And even if they did, it's only going to buy you a few months. --msa
Re: legacy /8
Cutler James R wrote: I also just got a fresh box of popcorn. I will sit by and wait I honestly am not trying to be a troll. It's just everytime I glance over the IANA IPv4 Address Space Registry I feel rather annoyed about all those /8s that were assigned back in the day without apparently realising we might run out. It was explained to me that many companies with /8s use it for their internal network and migrating to 10/8 instead is a major pain. Running out of IP addresses is not a soon realized scenario for IPv6. If an organization runs out of IP addresses, the difficulty is with top management, not the network or address space. I also don't try to bash IPv6, I don't know enough about it yet to do that and I doubt I would. From a casual observer's point of view having that much more IP space to allocate can only be a good thing. But from the same observer's POV you can also reason it is taking very long to gain acceptance. Regards, Jeroen
Re: legacy /8
Jeroen van Aart writes: Cutler James R wrote: I also just got a fresh box of popcorn. I will sit by and wait I honestly am not trying to be a troll. It's just everytime I glance over the IANA IPv4 Address Space Registry I feel rather annoyed about all those /8s that were assigned back in the day without apparently realising we might run out. It was explained to me that many companies with /8s use it for their internal network and migrating to 10/8 instead is a major pain. You know, I've felt the same irritation before, but one thing I am wondering and perhaps some folks around here have been around long enough to know - what was the original thinking behind doing those /8s? I understand that they were A classes and assigned to large companies, etc. but was it just not believed there would be more than 126(-ish) of these entities at the time? Or was it thought we would move on to larger address space before we did? Or was it that things were just more free-flowing back in the day? Why were A classes even created? RFC 791 at least doesn't seem to provide much insight as to the 'whys'. - Andrew
Re: legacy /8
On Friday 02 April 2010 06:14:33 pm Owen DeLong wrote: This is where Legacy vs. RIR becomes meaningful. Legacy holders have no contractual obligation to return unused space. RIR recipients, on the other hand, do. Some legacy holders might, I imagine, be 'squatting' on that legacy space and are getting ready to 'sell' some to the highest bidder, generating who knows how much revenue, if their agreement allows them to do so. A few of those same legacy holders might even want to impede IPv6 uptake to make their /8 more valuable when the crunch comes. Perhaps I'm too paranoid. But I'm sure I'm not the first person to think of these possibilities (in my case, however, I have no legacy space, and wouldn't go that route even if I did).
Re: legacy /8
Jeroen van Aart wrote: Cutler James R wrote: I also just got a fresh box of popcorn. I will sit by and wait I honestly am not trying to be a troll. It's just everytime I glance over the IANA IPv4 Address Space Registry I feel rather annoyed about all those /8s that were assigned back in the day without apparently realising we might run out. Yes. We should all jump up and down and complain about the early adopters who were present at the time and helped develop (and fund the development of) the Internet into something that pays most of our paychecks today. Or not. And of course some of the folks who got /8s early on have turned them back. Others have merged into entities who use a whole lot of the space. Matthew Kaufman
Re: legacy /8
On the topic of IP4 exhaustion: 1/8, 2/8 and 5/8 have all been assigned in the last 3 months yet I don't see them being allocated out to customers (users) yet. Is this perhaps a bit of hoarding in advance of the complete depletion of /8's? - Original Message - From: Majdi S. Abbas m...@latt.net To: Jeroen van Aart jer...@mompl.net Cc: NANOG list nanog@nanog.org Sent: Friday, April 02, 2010 4:06 PM Subject: Re: legacy /8 On Fri, Apr 02, 2010 at 02:01:45PM -0700, Jeroen van Aart wrote: I am curious. Once we're nearing exhausting all IPv4 space will there ever come a time to ask/demand/force returning all these legacy /8 allocations? I think I understand the difficulty in that, but then running out of IPs is also a difficult issue. :-) For some reason I sooner see all IPv4 space being exhausted than IPv6 being actually implemented globally. Because it's no more than a delaying action. Even presuming you get people to cooperate (and they really, have no incentive to because they don't necessarily have any agreement covering the space with the RIRs) rather than fire up their legal department A couple of /8s doesn't last long enough to really make a dent in the pain. You might buy yourself a few months at most. It might actually do more harm than good, by convincing people that they can still get v4 space rather than worry about what they are going to do in the future. --msa
Re: legacy /8
On Fri, Apr 02, 2010 at 05:48:44PM -0500, John Palmer (NANOG Acct) wrote: On the topic of IP4 exhaustion: 1/8, 2/8 and 5/8 have all been assigned in the last 3 months yet I don't see them being allocated out to customers (users) yet. Is this perhaps a bit of hoarding in advance of the complete depletion of /8's? Doubt it. 1/8 is still being evaluated to determine just how usable portions of it are, thanks to silly people of the world that decided 1.1.1.x and the like were 1918 space. As for the others, the RIR requests it when they are running low, but certainly not exhausted, and as slow as people are to update their bogon filters, it sounds like general good practice not to assign out of a new /8 until pre-existing resources are exhausted. Can we put the tinfoil hats away and let this thread die now? --msa
Re: Books for the NOC guys...
On Apr 2, 2010, at 8:10 AM, Jens Link wrote: Robert E. Seastrom r...@seastrom.com writes: So, what are you having your up-and-coming NOC staff read? http://www.amazon.com/Illustrated-Network-Modern-Kaufmann-Metworking/dp/0123745411/ I think it's quite good and covers many modern topics. One drawback: It mentions ethereal and not wireshark. At the time of writing ethereal must have been dead for about 2 years. Heh.. GUIs they come and GUIs they go... tcpdump works forever. Owen
Re: New Linksys CPE, IPv6 ?
I've gotten multiple emails about this... Yes, this is a known issue at the moment due to an upgrade put in place at DeLong. There is an open ticket with Juniper on why the 6in4 tunnels are not working on the SRX-100 and why traffic coming in through the alternate path is not being correctly processed. I hope to have my IPv6 services back on line shortly and I apologize for any inconvenience and the unfortunate timing. Owen On Apr 2, 2010, at 2:22 PM, Jim Burwell wrote: FYI ... I can't get to delong.com's IPv6 space from my HE tunnel provided IPv6 space (2001:470:8332::/48). When I traceroute using UDP or ICMP or tcptrace it stops in HE's core. BGP issue? Last hop I see is: 10gigabitethernet1-1.core1.sjc2.ipv6.he.net (2001:470:0:31::2) - Jim
Re: legacy /8
On Apr 2, 2010, at 3:38 PM, Andrew Gray wrote: Jeroen van Aart writes: Cutler James R wrote: I also just got a fresh box of popcorn. I will sit by and wait I honestly am not trying to be a troll. It's just everytime I glance over the IANA IPv4 Address Space Registry I feel rather annoyed about all those /8s that were assigned back in the day without apparently realising we might run out. It was explained to me that many companies with /8s use it for their internal network and migrating to 10/8 instead is a major pain. You know, I've felt the same irritation before, but one thing I am wondering and perhaps some folks around here have been around long enough to know - what was the original thinking behind doing those /8s? The original thinking was based on an environment where the Internet was expected to consist only of a few corporate entities providing services and products to research institutions and the government. There was no WWW, no browsers, and Windows couldn't even spell TCP/IP at the time. The expectation was that those /8s would be subnetted into vast arrays of Class C sized chunks and that subnets within a given /8 all had to be the same size (this used to be necessary to keep RIP happy and every machine participating in RIP routing had to have an /etc/netmasks (or equivalent) table that tracked THE subnet mask for each natural prefix). Sure, a /8 is a lot of addresses in today's world. However, back then, it was much like a /48 today. Just a way to give someone 65,500+ subnets (for any given X/8, then X.0/16, X.255/16, X.Y.0/24, X.Y.255/24 were unusable in these days). I understand that they were A classes and assigned to large companies, etc. but was it just not believed there would be more than 126(-ish) of these entities at the time? Or was it thought we would move on to larger address space before we did? Or was it that things were just more free-flowing back in the day? Why were A classes even created? RFC 791 at least doesn't seem to provide much insight as to the 'whys'. - Andrew It was thought that we would not have nearly so many people connected to the internet. It was expected that most things connecting to the internet would be minicomputers and mainframes. Owen
Re: legacy /8
On Apr 2, 2010, at 6:38 26PM, Andrew Gray wrote: Jeroen van Aart writes: Cutler James R wrote: I also just got a fresh box of popcorn. I will sit by and wait I honestly am not trying to be a troll. It's just everytime I glance over the IANA IPv4 Address Space Registry I feel rather annoyed about all those /8s that were assigned back in the day without apparently realising we might run out. It was explained to me that many companies with /8s use it for their internal network and migrating to 10/8 instead is a major pain. You know, I've felt the same irritation before, but one thing I am wondering and perhaps some folks around here have been around long enough to know - what was the original thinking behind doing those /8s? I understand that they were A classes and assigned to large companies, etc. but was it just not believed there would be more than 126(-ish) of these entities at the time? Or was it thought we would move on to larger address space before we did? Or was it that things were just more free-flowing back in the day? Why were A classes even created? RFC 791 at least doesn't seem to provide much insight as to the 'whys'. Many large companies found that class A nets weren't very useful. Multiple levels of subnetting didn't exist, which meant that you couldn't assign a /16 to a location and a /24 to each piece of thick yellow cable within the location, for example. ATT got 12/8 moderately early. We realized we couldn't easily use it, and offered it back in exchange for the equivalent in class B space. Postel gave us the latter (135/8), but told us to keep 12/8 -- other people were discovering the same problem, so there was little demand for class A networks. (This was circa 1987, if memory serves, and possibly a year or two earlier.) --Steve Bellovin, http://www.cs.columbia.edu/~smb
Re: legacy /8
You know, I've felt the same irritation before, but one thing I am wondering and perhaps some folks around here have been around long enough to know - what was the original thinking behind doing those /8s? Read your network history. In the beginning all allocations were /8s, in fact the slash notation hadn't been invented yet. Network numbers were 8 bits and there was a 24 bit host id appended. Then someone realised that the net was growing really fast, so they invented class A, B and C addresses in which the network numbers were 8, 16 or 24 bits respectively. You could tell which class by looking at the first two bits of the address. In that time period only very big organizations got class A allocations. Mid-sized ones got class B and small ones got class C. In fact what happened was that some smaller organizations got multiple non-aggregatable class C blocks (and aggregation didn't exist anyway). Later on some clever folks invented VLSM for the routers which allowed network ops folks to invent CIDR. That was when people really got interested in justifying the size of an allocation, and working based on 3 months, or 6 months requirements. This is when ARIN was created so that the community had some input into how things were done. But nobody could really unroll the past, just clean up the bits where people were changing things around anyway. For instance this is how Stanford's /8 ended up being returned. Lots of folks believed that VLSM and CIDR were only stopgap measures so around the same time they invented IPv6. It was released into network operations around 10 years ago which is why most of your network equipment and servers already support it. But that's all water under the bridge. It's too late to do anything about IPv4. The ROI just isn't there any more, and it doesn't escape the need to invest in IPv6. The network industry has now reached consensus that IPv6 is the way forward, and you have to catch the wave, or you will drown in the undertow. --Michael Dillon
Re: legacy /8
On 04/02/2010 06:38 PM, Andrew Gray wrote: I understand that they were A classes and assigned to large companies, etc. but was it just not believed there would be more than 126(-ish) of these entities at the time? Or was it thought we would move on to larger address space before we did? Or was it that things were just more free-flowing back in the day? Why were A classes even created? RFC 791 at least doesn't seem to provide much insight as to the 'whys'. /8's were not given out to large companies. They were given out to *everyone*! In the beginning there was the ARPANET and it was considered a large network (it was certainly an expensive network!). The notion was that there would only be a small number of large networks, so 8 bits was enough to enumerate them. The original IP plan didn't have classes of networks at all. It was 8 bits of network and 24 bits of host-on-that-network. It was only after network numbers started to hit the early thirties that folks realized that there needed to be more networks and the class-full approach was invented. So most of the existing class A holders just happened to be the very early adopters (actually the original research and government organizations that were connected to the network). -Jeff -- Jeffrey I. Schiller MIT Network Manager/Security Architect PCI Compliance Officer Information Services and Technology Massachusetts Institute of Technology 77 Massachusetts Avenue Room W92-190 Cambridge, MA 02139-4307 617.253.0161 - Voice j...@mit.edu http://jis.qyv.name signature.asc Description: OpenPGP digital signature
Re: legacy /8
- Original Message - From: Majdi S. Abbas m...@latt.net To: John Palmer (NANOG Acct) nan...@adns.net Cc: NANOG list nanog@nanog.org Sent: Friday, April 02, 2010 5:52 PM Subject: Re: legacy /8 On Fri, Apr 02, 2010 at 05:48:44PM -0500, John Palmer (NANOG Acct) wrote: On the topic of IP4 exhaustion: 1/8, 2/8 and 5/8 have all been assigned in the last 3 months yet I don't see them being allocated out to customers (users) yet. Is this perhaps a bit of hoarding in advance of the complete depletion of /8's? Doubt it. 1/8 is still being evaluated to determine just how usable portions of it are, thanks to silly people of the world that decided 1.1.1.x and the like were 1918 space. As for the others, the RIR requests it when they are running low, but certainly not exhausted, and as slow as people are to update their bogon filters, it sounds like general good practice not to assign out of a new /8 until pre-existing resources are exhausted. Was looking for the allocated file on the ARIN website, but can't remember where it is. They used to have a file with one line per allocation that started like this arin|US|ipv4. Is that still public somewhere? Can we put the tinfoil hats away and let this thread die now? --msa Good luck with that one :-
Re: Note change in IANA registry URLs
On Apr 2, 2010, at 7:13 AM, Robert Kisteleki wrote: You're confusing two things: URL and content. According to the announcement, TXT files will be generated still. Why, again, must the URL change? As Leo pointed out, a message will be displayed at the historical URL. Does this address your concerns? Regards, -drc
Re: legacy /8
On 4/2/10 3:01 PM, Jeroen van Aart wrote: I am curious. Once we're nearing exhausting all IPv4 space will there ever come a time to ask/demand/force returning all these legacy /8 allocations? I think I understand the difficulty in that, but then running out of IPs is also a difficult issue. :-) For some reason I sooner see all IPv4 space being exhausted than IPv6 being actually implemented globally. Greetings, Jeroen I've got a rather stupidly simple and straightforward plan, since we're all throwing ideas out. Take back all the IP space from China and give them a single /20 and tell them to make do. They're already behind a great firewall, so they should have no problem using NAT with their citizens for easier restricting of freedoms, and for the actual services they need to run, they can assign a limited amount of static IP addresses for servers, and the rest NAT as well, and port forward for specific services. If they want to be an intranet, I say, lets help them achieve that goal. They get to play in their own sandbox, and we get some IP space back to buy us more time. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org/ http://www.ahbl.org
Re: legacy /8
On April 2, 2010 at 15:25 jer...@mompl.net (Jeroen van Aart) wrote: I honestly am not trying to be a troll. It's just everytime I glance over the IANA IPv4 Address Space Registry I feel rather annoyed about all those /8s that were assigned back in the day without apparently realising we might run out. Aha! Someone else who believes the internet should model a justice system. -- -Barry Shein The World | b...@theworld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD| Dial-Up: US, PR, Canada Software Tool Die| Public Access Internet | SINCE 1989 *oo*
Re: legacy /8
On Fri, Apr 02, 2010 at 03:13:16PM -0700, Owen DeLong wrote: Sigh... Guess you missed the last several go-arounds of Running out of IPv4 will create some hardships. That cannot be avoided. we won't run out, we won't exaust, we are -NOT- killing the last tuna. what we are doing is roughly what was anticipated in RFC 2050, we will get more efficent utilization of all the space. Even if we were to reclaim the supposed unused legacy /8s, we'd still only extend the date of IPv4 runout by a few months. wrong analogy. there won't be green field space - but there will still be lots to go around... for legacy style use (e.g. the Internet as we know it today) -- want to do something different? then use IPv6. The amount of effort required to reclaim those few IPv4 addresses would vastly exceed the return on that effort. Far better for that effort to be directed towards the addition of IPv6 capabilities to existing IPv4 deployments so as to minimize the impact of IPv4 exhaustion. here we disagree. Im all in favor of demonstrating 85% utilization of the IPv4 address pool before handing out new address space. --bill Owen On Apr 2, 2010, at 2:01 PM, Jeroen van Aart wrote: I am curious. Once we're nearing exhausting all IPv4 space will there ever come a time to ask/demand/force returning all these legacy /8 allocations? I think I understand the difficulty in that, but then running out of IPs is also a difficult issue. :-) For some reason I sooner see all IPv4 space being exhausted than IPv6 being actually implemented globally. Greetings, Jeroen
Re: legacy /8
On Fri, Apr 02, 2010 at 03:25:22PM -0700, Jeroen van Aart wrote: Cutler James R wrote: I also just got a fresh box of popcorn. I will sit by and wait I honestly am not trying to be a troll. It's just everytime I glance over the IANA IPv4 Address Space Registry I feel rather annoyed about all those /8s that were assigned back in the day without apparently realising we might run out. its well to remember that when they got that space, the minimum allocation was a /8. you couldn't get anything smaller because classful addressing wasn;t invented yet. Only (much) later could you get B or C space... and after classful died in v4, we had CIDR. IPv6 as effectively reindroduced classful addressing. Regards, Jeroen --bill
Re: legacy /8
On Fri, Apr 02, 2010 at 03:46:55PM -0700, Owen DeLong wrote: The expectation was that those /8s would be subnetted into vast arrays of Class C sized chunks and that subnets within a given /8 all had to be the same size (this used to be necessary to keep RIP happy and every machine participating in RIP routing had to have an /etc/netmasks (or equivalent) table that tracked THE subnet mask for each natural prefix). er, again, not true. the space was originally, net/host - the mantra was bridge where you can, route when you must - there were expected to be a few networks with millions of hosts within each broadcast domain. (anyone else remember the ARP storms of the 1970s/1980s?) routing came into its own later, along with classful addressing. Owen --bill
Re: legacy /8
ipv4 spae is not 'running out.' the rirs are running out of a free resource which they then rent to us. breaks my little black heart. even if, and that's an if, ipv6 takes off, ipv4 is gonna be around for a lng while. when 95% of the world has end-to-end ipv6, do you think amazon et alia are gonna blow 5% of their market by decomissioning ipv4? we are gonna learn how to distribute and use ipv4 more efficiently. it's not that hard, we know how to do it. internet engineers have worked through and around a lot of problems, it's our job. making connectivity continue work for folk who, for whatever reason, delay migration from ipv4 is just part of our job. not to panic. the hard part is figuring out how the rirs make money off ipv4 holders redistributing it among themselves. if that becomes a non-goal, things get a lot simpler. randy
Re: legacy /8
IPv6 as effectively reindroduced classful addressing. but it's not gonna be a problem this time, right? after all, 32^h^h128^h^h^h64 bits is more than we will ever need, right? randy
Re: legacy /8
On Sat, Apr 03, 2010 at 09:25:08AM +0900, Randy Bush wrote: IPv6 as effectively reindroduced classful addressing. but it's not gonna be a problem this time, right? after all, 32^h^h128^h^h^h64 bits is more than we will ever need, right? randy well... looking at a diet analogy, when .gt. 50% of your diet is HFCS and filler, its not real healthy. the way most folks are using IPv6, .gt. 50% of the bits are wasted as filler (got to love me some ::) so it seems like a lot, yet folks have already predicted the demise of IPv6 in the next 20years. (Klensin I think it was) --bill
Re: legacy /8
Just like 640k or memory :) On Fri, Apr 2, 2010 at 9:25 PM, Randy Bush ra...@psg.com wrote: IPv6 as effectively reindroduced classful addressing. but it's not gonna be a problem this time, right? after all, 32^h^h128^h^h^h64 bits is more than we will ever need, right? randy
Re: legacy /8
On Apr 2, 2010, at 1:40 PM, Brielle Bruns wrote: Take back all the IP space from China and give them a single /20 and tell them to make do. At current consumption rates, that'd buy us another year or so. Then what? Regards, -drc
Re: legacy /8
On 4/2/10 6:36 PM, David Conrad wrote: On Apr 2, 2010, at 1:40 PM, Brielle Bruns wrote: Take back all the IP space from China and give them a single /20 and tell them to make do. At current consumption rates, that'd buy us another year or so. Then what? Regards, -drc To quote: we get some IP space back to buy us more time Didn't say it was a solution, but we're all talking about buying more time for ipv6 transition. Its no worse then any other suggestion people have proposed. :) -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org/ http://www.ahbl.org
Anyone observing latency and dropped packets at peering points in Seattle?
I've been troubleshooting an issue all day. Traffic leaving our site, on Verizon public transport, destined for the Spokane area is routing to Qwest and hitting 400ms rapidly. The offending router seems to be a Verizon router (number 6 here). On top of that, we're seeing this via Level3 coming in from Spokane towards Seattle (targeting our Verizon IPs). 3. 116.atm2-0.xr2.sea4.alter.net 0.0% 81437.4 1.7 1.1 100.6 10.3 4. 0.so-6-0-0.xt2.sea1.alter.net 0.0% 81432.6 4.2 2.1 148.5 14.8 5. pos7-0.br1.sea1.alter.net 0.0% 81422.6 2.2 2.0 38.1 1.6 6. 204.255.169.30 0.0% 8142 431.3 405.0 320.2 469.8 22.2 7. sea-core-01.inet.qwest.net 0.0% 8142 430.5 407.3 324.0 541.3 24.2 8. spk-core-01.inet.qwest.net 0.0% 8142 440.4 414.0 324.9 470.6 22.2 9. spk-edge-04.inet.qwest.net 0.0% 8142 441.1 414.9 323.7 539.6 22.6 Testing on XO looks a lot different. 66.236.9.5.ptr.us.xo.net -1 | 1034 | 1031 |1 | 47 | 112 | 53 | | p6-0-0d0.mar1.seattle-wa.us.xo.net -1 | 1033 | 1030 |1 | 48 | 170 | 50 | | p4-2-0d0.rar1.seattle-wa.us.xo.net -1 | 1033 | 1031 |1 | 47 | 168 | 51 | | te-3-1-0.rar3.seattle-wa.us.xo.net -0 | 1033 | 1033 |2 | 46 | 170 | 54 | | 207.88.13.145.ptr.us.xo.net -1 | 1033 | 1032 |1 | 48 | 113 | 52 | |216.156.100.18.ptr.us.xo.net -0 | 1033 | 1033 |2 | 49 | 297 | 50 | | agg1-sea-p10.bb.spectrumnet.us -0 | 1033 | 1033 |2 | 47 | 239 | 52 | |tierpoint-sea-1000m.demarc.spectrumnet.us -1 | 1033 | 1032 |9 | 54 | 249 | 56 | Any assistance would be appreciated, confirmation would be excellent, this is causing issues. Thank you E ps - I will turn off my MTR shortly, I don't use it much anymore.
Re: legacy /8
On 4/2/2010 17:22, Randy Bush wrote: ipv4 spae is not 'running out.' the rirs are running out of a free resource which they then rent to us. breaks my little black heart. even if, and that's an if, ipv6 takes off, ipv4 is gonna be around for a lng while. when 95% of the world has end-to-end ipv6, do you think amazon et alia are gonna blow 5% of their market by decomissioning ipv4? we are gonna learn how to distribute and use ipv4 more efficiently. it's not that hard, we know how to do it. internet engineers have worked through and around a lot of problems, it's our job. making connectivity continue work for folk who, for whatever reason, delay migration from ipv4 is just part of our job. not to panic. the hard part is figuring out how the rirs make money off ipv4 holders redistributing it among themselves. if that becomes a non-goal, things get a lot simpler. So, jump through hoops to kludge up IPv4 so it continues to provide address space for new allocations through multiple levels of NAT (or whatever), and buy a bit more time, or jump through the hoops required to deploy IPv6 and eliminate the exhaustion problem? And also, if the IPv4 space is horse-traded among RIRs and customers as you allude to above, IPv6 will look even more attactive as the price and preciousness of IPv4 addresses increases. The idea isn't for IPv4 to be replaced (decommissioned). The idea is for IPv6 to be added, then things will slowly transition. IPv4 will be around for a long time indeed, but increasingly, new sites/services, and old sites/services will be adding IPv6 as a way to connect to them. Then at some point, IPv6 will become the normal way to connect, and IPv4 will be a the legacy way, with fewer and fewer using it. Also, reading your other post, if you don't understand the difference between 2^32 and 2^128, please start here: http://en.wikipedia.org/wiki/Exponential_growth Anyway, I see it as pretty much moot, since many major players (Comcast, Google, etc) are in the midst of major IPv6 deployments as we speak. Eventually you will have to jump on the bandwagon too. :-) - Jim
Re: legacy /8
On 4/2/2010 19:25, Randy Bush wrote: IPv6 as effectively reindroduced classful addressing. but it's not gonna be a problem this time, right? after all, 32^h^h128^h^h^h64 bits is more than we will ever need, right? Just like last time. -- Democracy: Three wolves and a sheep voting on the dinner menu. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
Re: legacy /8
Larry Sheldon wrote: On 4/2/2010 19:25, Randy Bush wrote: IPv6 as effectively reindroduced classful addressing. but it's not gonna be a problem this time, right? after all, 32^h^h128^h^h^h64 bits is more than we will ever need, right? Just like last time. Oh brother. Last time everybody thought it was a geek science experiment at best. With IPv6, IP at least had conquered the known universe. Mike
Re: legacy /8
On 03/04/10 00:09 +, bmann...@vacation.karoshi.com wrote: On Fri, Apr 02, 2010 at 03:13:16PM -0700, Owen DeLong wrote: Sigh... Guess you missed the last several go-arounds of Running out of IPv4 will create some hardships. That cannot be avoided. we won't run out, we won't exaust, we are -NOT- killing the last tuna. what we are doing is roughly what was anticipated in RFC 2050, we will get more efficent utilization of all the space. That statement becomes less truthy when more realistic definitions of 'we' are used. I'd suggest that attempts to stretch v4 addresses is going to fall over on its side, for large segments of we. Address exchanges on the free market, and RIR reclamation will certainly be sufficient for other large segments. However, there will be a point in the next 3-5 years in which neither of these methods will be able to keep up with the tide of technological advancement. Even if we were to reclaim the supposed unused legacy /8s, we'd still only extend the date of IPv4 runout by a few months. wrong analogy. there won't be green field space - but there will still be lots to go around... for legacy style use (e.g. the Internet as we know it today) -- want to do something different? then use IPv6. I already feel like a dinosaur sitting in front of my desktop, with a keyboard. The Internet as we know it today only has 2-3 years of v4 address supply left. The more we stretch address usage, the more we create something that does not resemble the Internet as we know it today. The amount of effort required to reclaim those few IPv4 addresses would vastly exceed the return on that effort. Far better for that effort to be directed towards the addition of IPv6 capabilities to existing IPv4 deployments so as to minimize the impact of IPv4 exhaustion. here we disagree. Im all in favor of demonstrating 85% utilization of the IPv4 address pool before handing out new address space. -- Dan White
Re: legacy /8
The last time I discussed IP Address needs with a company the builds automobiles, they wanted forty million addresses for robots, sensors, and the like for manufacturing. A single /8, were it available, would only yield about 20% of that requirement. On Apr 2, 2010, at 6:46 PM, Owen DeLong wrote: Sure, a /8 is a lot of addresses in today's world. James R. Cutler james.cut...@consultant.com
RE: legacy /8
-Original Message- From: Jim Burwell [mailto:j...@jsbc.cc] Sent: Friday, April 02, 2010 6:00 PM To: nanog@nanog.org Subject: Re: legacy /8 So, jump through hoops to kludge up IPv4 so it continues to provide address space for new allocations through multiple levels of NAT (or whatever), and buy a bit more time, or jump through the hoops required to deploy IPv6 and eliminate the exhaustion problem? And also, if the IPv4 space is horse-traded among RIRs and customers as you allude to above, IPv6 will look even more attactive as the price and preciousness of IPv4 addresses increases. No problem, everyone tunnels v4 in v4 and the outer ip address is your 32-bit ASN and you get an entire /0 of legacy ip space inside your ASN. Just need to get rid of BGP and go to some sort of label switching with the border routers having an ASN to upstream label table and there ya go. Oh, and probably create an AA RR in DNS that is in ASN:x.x.x.x format. Increase the MTU a little and whammo! There ya go! Done. :)
Re: legacy /8
I'm old but maybe not old nuff to know if this was discussed before or not, but I've been asking people last few months why we don't just do something like this. don't even need to get rid of BGP, just add some extension, we see ok to add extensions to BGP to do other things, this makes at least if not more sence. -jim On Fri, Apr 2, 2010 at 11:13 PM, George Bonser gbon...@seven.com wrote: -Original Message- From: Jim Burwell [mailto:j...@jsbc.cc] Sent: Friday, April 02, 2010 6:00 PM To: nanog@nanog.org Subject: Re: legacy /8 So, jump through hoops to kludge up IPv4 so it continues to provide address space for new allocations through multiple levels of NAT (or whatever), and buy a bit more time, or jump through the hoops required to deploy IPv6 and eliminate the exhaustion problem? And also, if the IPv4 space is horse-traded among RIRs and customers as you allude to above, IPv6 will look even more attactive as the price and preciousness of IPv4 addresses increases. No problem, everyone tunnels v4 in v4 and the outer ip address is your 32-bit ASN and you get an entire /0 of legacy ip space inside your ASN. Just need to get rid of BGP and go to some sort of label switching with the border routers having an ASN to upstream label table and there ya go. Oh, and probably create an AA RR in DNS that is in ASN:x.x.x.x format. Increase the MTU a little and whammo! There ya go! Done. :)
Re: legacy /8
Is someone volunteering to work on an RFC? Or, has someone done so for this already? - Original Message - From: jim deleskie deles...@gmail.com To: nanog@nanog.org Sent: Friday, April 02, 2010 9:17 PM Subject: Re: legacy /8 I'm old but maybe not old nuff to know if this was discussed before or not, but I've been asking people last few months why we don't just do something like this. don't even need to get rid of BGP, just add some extension, we see ok to add extensions to BGP to do other things, this makes at least if not more sence. -jim On Fri, Apr 2, 2010 at 11:13 PM, George Bonser gbon...@seven.com wrote: -Original Message- From: Jim Burwell [mailto:j...@jsbc.cc] Sent: Friday, April 02, 2010 6:00 PM To: nanog@nanog.org Subject: Re: legacy /8 So, jump through hoops to kludge up IPv4 so it continues to provide address space for new allocations through multiple levels of NAT (or whatever), and buy a bit more time, or jump through the hoops required to deploy IPv6 and eliminate the exhaustion problem? And also, if the IPv4 space is horse-traded among RIRs and customers as you allude to above, IPv6 will look even more attactive as the price and preciousness of IPv4 addresses increases. No problem, everyone tunnels v4 in v4 and the outer ip address is your 32-bit ASN and you get an entire /0 of legacy ip space inside your ASN. Just need to get rid of BGP and go to some sort of label switching with the border routers having an ASN to upstream label table and there ya go. Oh, and probably create an AA RR in DNS that is in ASN:x.x.x.x format. Increase the MTU a little and whammo! There ya go! Done. :)
RE: legacy /8
On Fri, 2 Apr 2010, Joe Johnson wrote: Maybe encourage people like Apple, Xerox, HP or Ford to migrate their operations completely to IPv6 and return their /8? Perhaps 45.0.0.0/8 can start, that shouldn't be too hard to migrate out of? :P -- Mikael Abrahamssonemail: swm...@swm.pp.se
RE: legacy /8
-Original Message- From: jim deleskie Sent: Friday, April 02, 2010 7:17 PM To: nanog@nanog.org Subject: Re: legacy /8 I'm old but maybe not old nuff to know if this was discussed before or not, but I've been asking people last few months why we don't just do something like this. don't even need to get rid of BGP, just add some extension, we see ok to add extensions to BGP to do other things, this makes at least if not more sence. -jim We wouldn't really need to get rid of BGP, it would just be that there would be potentially one route per ASN with no (or very little) aggregation. Some form of label switching where you map ASNs to peers might just be a little more efficient as you would only see the number of labels that you have peers. If the vendors are prepared to grow their capabilities along with the number of ASNs assigned, then there is no problem. Currently that would not be a problem. There are only 56,218 allocated 16-bit ASNs and 5120 allocated 32-bit ASNs for a current total of only about 61,000-ish routes. Any peering router in use today that takes full routes would be able to handle this in its sleep.
Re: legacy /8
On Fri, 02 Apr 2010 15:38:26 -0700 Andrew Gray 3...@blargh.com wrote: Jeroen van Aart writes: Cutler James R wrote: I also just got a fresh box of popcorn. I will sit by and wait I honestly am not trying to be a troll. It's just everytime I glance over the IANA IPv4 Address Space Registry I feel rather annoyed about all those /8s that were assigned back in the day without apparently realising we might run out. It was explained to me that many companies with /8s use it for their internal network and migrating to 10/8 instead is a major pain. You know, I've felt the same irritation before, but one thing I am wondering and perhaps some folks around here have been around long enough to know - what was the original thinking behind doing those /8s? I understand that they were A classes and assigned to large companies, etc. but was it just not believed there would be more than 126(-ish) of these entities at the time? Or was it thought we would move on to larger address space before we did? Or was it that things were just more free-flowing back in the day? Why were A classes even created? RFC 791 at least doesn't seem to provide much insight as to the 'whys'. That's because RFC791 is a long way from the original design assumptions of the Internet Protocols. A Protocol for Packet Network Intercommunication, Vinton G. Cerf and Robert E. Kahn, 1974, says - The choice for network identification (8 bits) allows up to 256 distinct networks. This size seems sufficient for the foreseeable future. That view seems to have persisted up until at least RFC761, January 1980, which still specified the single 8 bit network, 24 bit node address format. RFC791, September 1981, introduces classes. So somewhere within that period it was recognised that 256 networks wasn't going to be enough. I'm not sure why the 32 bit address size was persisted with at that point - maybe it was because there would be significant performance loss in handling addresses greater than what was probably the most common host word size at the time. If you start looking into the history of IPv4 addressing, and arguably why it is so hard to understand and teach compared to other protocols such as Novell's IPX, Appletalk etc., everything that has been added to allow increasing the use of IP (classes, subnets, classless) while avoiding increasing the address size past 32 bits is a series of very neat hacks. IPv4 is a 1970s protocol that has had to cope with dramatic and unforeseen success. It's not a state of the art protocol any more, and shouldn't be used as an example of how things should be done today (As a minimum, I think later protocols like Novell's IPX and Appletalk are far better candidates). It is, however, a testament to how successfully something can be hacked over time to continue to work far, far beyond it's original design parameters and assumptions. (IMO, if you want to understand the design philosophies of IPv6 you're better off studying IPX and Appletalk than using your IPv4 knowledge. I think IPv6 is a much closer relative to those protocols than it is to IPv4. For example, router anycast addresses was implemented and used in Appletalk.) Possibly Vint Cerf might be willing to clear up some of these questions about the origins of IPv4 addressing. Regards, Mark.
Re: legacy /8
On Fri, 02 Apr 2010 18:49:58 MDT, Brielle Bruns said: we get some IP space back to buy us more time Didn't say it was a solution, but we're all talking about buying more time for ipv6 transition. Its no worse then any other suggestion people have proposed. :) They've had plenty of time to plan ahead for this one. I'm having a really hard time finding any sympathy for any organization that is just now waking up to the fact that they need to do something. pgpga3jgeulVp.pgp Description: PGP signature
RE: legacy /8
-Original Message- From: John Palmer (NANOG Acct) [mailto:nan...@adns.net] Sent: Friday, April 02, 2010 7:29 PM To: nanog@nanog.org Subject: Re: legacy /8 Is someone volunteering to work on an RFC? Or, has someone done so for this already? I have never heard of anything along that line. It is just something that has wandered through my mind from time to time wondering why nobody had ever done such a thing as it seems so easy. All you need is to increase the standard transit MTU a little bit so your encapsulation doesn't result in a bunch of additional packet fragmentation due to the encap overhead and create the new DNS AA RR and that would be about all that is required. If your network is an end user, you just announce one route ... your ASN ... to your transit providers and any peers. A transit operation announces their ASN and any they are collecting from peers. They hard part is getting all the end nodes to use IPIP tunneling as their primary protocol by default. It is doable but that is the hard part.
Re: legacy /8
On Fri, 2 Apr 2010 21:29:20 -0500 John Palmer \(NANOG Acct\) nan...@adns.net wrote: Is someone volunteering to work on an RFC? Or, has someone done so for this already? Probably similar to this (and others that remove end-site knowledge from the Internet core) - The Locator Identifier Separation Protocol (LISP) http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_11-1/111_lisp.html - Original Message - From: jim deleskie deles...@gmail.com To: nanog@nanog.org Sent: Friday, April 02, 2010 9:17 PM Subject: Re: legacy /8 I'm old but maybe not old nuff to know if this was discussed before or not, but I've been asking people last few months why we don't just do something like this. don't even need to get rid of BGP, just add some extension, we see ok to add extensions to BGP to do other things, this makes at least if not more sence. -jim On Fri, Apr 2, 2010 at 11:13 PM, George Bonser gbon...@seven.com wrote: -Original Message- From: Jim Burwell [mailto:j...@jsbc.cc] Sent: Friday, April 02, 2010 6:00 PM To: nanog@nanog.org Subject: Re: legacy /8 So, jump through hoops to kludge up IPv4 so it continues to provide address space for new allocations through multiple levels of NAT (or whatever), and buy a bit more time, or jump through the hoops required to deploy IPv6 and eliminate the exhaustion problem? And also, if the IPv4 space is horse-traded among RIRs and customers as you allude to above, IPv6 will look even more attactive as the price and preciousness of IPv4 addresses increases. No problem, everyone tunnels v4 in v4 and the outer ip address is your 32-bit ASN and you get an entire /0 of legacy ip space inside your ASN. Just need to get rid of BGP and go to some sort of label switching with the border routers having an ASN to upstream label table and there ya go. Oh, and probably create an AA RR in DNS that is in ASN:x.x.x.x format. Increase the MTU a little and whammo! There ya go! Done. :)
Re: legacy /8
Anyway, I see it as pretty much moot, since many major players (Comcast, Google, etc) are in the midst of major IPv6 deployments as we speak. Eventually you will have to jump on the bandwagon too. :-) clue0: the isp for which i work deployed ipv6 in the '90s. we were the world's first commercial ipv6 isp deployment. clue1: not only can i do the math, but i can remember history randy
RE: legacy /8
-Original Message- From: George Bonser [mailto:gbon...@seven.com] Sent: Friday, April 02, 2010 7:53 PM To: John Palmer (NANOG Acct); nanog@nanog.org Subject: RE: legacy /8 They hard part is getting all the end nodes to use IPIP tunneling as their primary protocol by default. It is doable but that is the hard part. Actually, both methods could exist side by side. If a standard packet arrives, the destination AS is looked up using conventional routing information, it is encapsulated and sent to the destination AS. In other words, a standard packet is assumed to be a legacy address space packet. An encapsulated packet handled in the new way. But you know, the fact that the network techies has not exactly spent the past 10 years busting down the doors for v6 should tell people something really important. That they are willing to wait until the wolf is at the door to switch means something that needs to be paid your attention. v6 could well be the protocol that broke the Internet because it is sort of like replacing a Jeep with a bus built by Rube Goldberg. That adoption is so low at this point really says that it has failed.
Re: legacy /8
i had a bet w/ some folks when RFC 1918 came into existance. I postulated that it might be better for the Internet if the RFC 1918 space was used to address the public Internet and the rest of the space be used inside folks walled gardens... circa 1996 or so. --bill On Fri, Apr 02, 2010 at 11:17:28PM -0300, jim deleskie wrote: I'm old but maybe not old nuff to know if this was discussed before or not, but I've been asking people last few months why we don't just do something like this. don't even need to get rid of BGP, just add some extension, we see ok to add extensions to BGP to do other things, this makes at least if not more sence. -jim On Fri, Apr 2, 2010 at 11:13 PM, George Bonser gbon...@seven.com wrote: -Original Message- From: Jim Burwell [mailto:j...@jsbc.cc] Sent: Friday, April 02, 2010 6:00 PM To: nanog@nanog.org Subject: Re: legacy /8 So, jump through hoops to kludge up IPv4 so it continues to provide address space for new allocations through multiple levels of NAT (or whatever), and buy a bit more time, or jump through the hoops required to deploy IPv6 and eliminate the exhaustion problem? And also, if the IPv4 space is horse-traded among RIRs and customers as you allude to above, IPv6 will look even more attactive as the price and preciousness of IPv4 addresses increases. No problem, everyone tunnels v4 in v4 and the outer ip address is your 32-bit ASN and you get an entire /0 of legacy ip space inside your ASN. Just need to get rid of BGP and go to some sort of label switching with the border routers having an ASN to upstream label table and there ya go. Oh, and probably create an AA RR in DNS that is in ASN:x.x.x.x format. Increase the MTU a little and whammo! There ya go! Done. :)
