Just a brief recap of Cisco Live 2010 in photos:
![]() |
Cisco Live 2010 |
Musings on computer stuff, and things... and other stuff.
I just wanted to drop a quick note here to let everyone know that I plan on blogging a little more frequently this week, as I’ll be in Las Vegas for the annual North American Cisco conference: Cisco Networkers/Live. I can’t promise I’ll be in my room slaving over long, elaborate breakdowns of technology–maybe an in depth review of whiskey selections by bar–but I will try to post some pictures and information about what I’m seeing and hearing during the show. In years where I haven’t been able to attend the show, I always liked seeing and hearing from folks who did. Now it’s my turn to give back something, so watch this space…
Oh, and keep up with real-time information on twitter where I hide behind the handle @someclown, or G+ where I can be found at: http://gplus.to/someclown.
So, nostalgia about computers and the “good ole’ days” gets strong with me whenever I turn on my old Apple II, or pull out any old magazines from the early 80’s or 90’s. My wife laughs at me because I still get goosebumps and a light in my eye describing how I felt when I first saw the Apple IIgs or the Amiga 1000, and how bad I wanted them. It takes me back to when computers were fun, magical, and represented a brave new world to my young mind (with apologies to Aldous Huxley).
So it is with great excitement that I now have in my possession a book on that early time, written about one of the pioneering companies subject to more historical revisionism than most people realize.
“Commodore, a company on the edge” by Brian Bagnall is an in-depth, interesting, and more historically accurate portrayal of the early history of microcomputers in general, but Commodore in particular, than many I’ve read. Most early histories are written by revisionist authors like Robert Cringely and tend to dramatically overstate Apple and IBM’s contributions at the expense of Commodore and Atari, among others.
I’ll post a complete review when I’m done with the book, but just what I’ve read so far has me pining for simpler times. Before I knew acronyms like CCIE, OSPF, NX-OS and had a global enterprise network to tame, I had my Apple II, the Commodore 64, the Amiga 1000 and the Atari ST. They say you can’t go back again, but I’m trying.
This post will be a short one, and mostly just comes from a discussion I had the other day with another engineer. It turns out that even among people who are comfortable with IPv6, and maybe even have experience deploying it, a lot of misinformation still persists. Hopefully I can correct a couple of those today. I also tossed in a hot-potato at the end just to see how many folks get hopped up. Discussion is welcome, and in addition to comments here I can be found on twitter hiding behind the handle: @someclown.
You must turn on IPv6 by using the IPv6 unicast-routing command.
Not true. This is one of the more persistent, yet wildly incorrect, pieces of information regarding IPv6. I have even seen many training centers and instructors at the CCIE level get this one wrong and it falls into the category of attention to detail. What this command actually does is enable unicast routing for IPv6, just as it says. To actually enable IPv6 you simply need to go to any interface and use the ipv6 enable command. And yes, you can enable IPv6 on the interface without enabling unicast routing. Of course, it would be helpful to have an address on the interface as well.
Yes, but if you don’t turn on unicast routing you can’t route IPv6 traffic.
Not strictly speaking true. You can still set up a default route for IPv6 traffic and get it off of your system. To the extent that you want to argue whether or not this is actually routing is fine, but you can move IPv6 traffic off of your local device using a default route, and never have enabled routing for IPv6.
Using a /127 address on point-to-point links is wrong, wrong, wrong.
This is an interesting one, and usually sparks a fair amount of debate. Up until very recently, the recommendation across the board (RFC 4291) was to use /64 addresses even on point-to-point links, ostensibly because the IPv6 space is so big anyhow, and because several protocols will break (notably subnet-router anycast, specified in RFC 3627). While I’m not disputing that this is what the current best-practices reflect, I will say that RFC 6164 which has a status of Proposed Standard makes a fairly compelling case for using /127 on point-to-point links. I’m sure this won’t be resolved anytime soon, standards or no, but I would say that if you have a compelling reason for using /127 and know what you’re doing it for, go for it. Just be aware that standards can change, and you don’t want to leave a steaming pile for the poor person who has to follow you.
(1) My study hours don’t always match well with what slots the online rack vendors have available.
(2) I just like physical equipment and the flexibility it provides in both studying and in research.
Also, I just wanna.
With that said, one of the next things people want to know is what gear it is that I have, and how do I have it configured. Therefore, with the recent posting frequency here severely lacking, writing about my lab is a nice way to get something fresh on the blog and hopefully it provides something useful to someone out there. I’m going to break this down into two general categories: equipment that I have purely for my Cisco CCIE lab, and other equipment that I have either for my home network or for random reasons.
Random Non-Lab Specific Equipment List:
Non-plugged in Equipment
Computer storage:
Cisco Lab Equipment:
All of this is cabled and wired almost identically to the CCBootCamp lab topology. This is because I have all of their workbooks and wanted to be able to study with my own equipment. A couple of the details are different, mostly around interface numbers and the specifics of the backbone routers and such. Also, the switches I have are way overkill but satisfy the lab requirements. Given the actual topology from just about any mainstream training provider, I can copy it with the equipment I have, and that’s exactly what I wanted to be able to do. As always, contact me here or on twitter with questions and comments.
Pictures of the lab and sundries are included below.
Everyone has been posting their schedules for Cisco Live to Twitter, Facebook and wherever else, so I thought I’d better jump in with the cool kids and publish mine as well. I can’t guarantee this won’t change, but for now it stands as my best guess and current planned schedule.