When I started studying in earnest for my CCIE, I started a log of how I was spending my time studying, which books and papers I'd read, videos I'd watched, and so on. I thought it would be a neat exercise to look back afterwards at what it took to achieve this goal. I'm also somewhat self-deprecating and tend to minimize my accomplishments, so having this data is a way for me to remember that this wasn't a small accomplishment at all.

And now the big reveal. The reason I haven't been blogging or doing much of anything for some time now is because I've had a teeny tiny side project going on:

And this week I passed the lab exam! I am CCIE 47321 (Routing and Switching).

Although I wasn't actively blogging this year, I've still been tracking views on the site and keeping an eye on number of visitors. I am looking forward to blogging again in 2015 so I wanted to collect the 2014 viewership statistics so I had something to compare to at the end of 2015.

Despite the lack of new content, I'm pretty happy that people are reading the existing articles and continue to post comments and email me questions. Please keep them coming!

I debated whether to write an article like this. It seems to be the "in vogue" thing to do if you're a blog author but I wasn't inclined to do it until I started looking at the data (I heart data). When I started looking at the data, I saw not only number of visitors and so on to the blog, but a breakdown of browser versions and operating systems (thank you Google Analytics for the rich reports). As is often the case, your data set can tell you more than you initially bargained on.

I was preparing a presentation the other day about the high level differences between IOS, IOS-XE and NX-OS and one of the things I included in the presentation was the various platform and branch identifiers that's used in each OS. It's just a bit of trivia that I thought would be interesting and might come in handy one day. I'm posting the information I collected below so everyone can reference it.

It seems appropriate to write a FFF post about Virtual Extensible LAN (VXLAN) now since VXLAN is the new hotness in the data center these days. With VMware's NSX using VLXAN (among other overlays) as a core part of its overall solution and the recent announcement of Cisco's Application Centric Infrastructure (ACI) and the accompanying Nexus 9000 switch, both of which leverage VXLAN for delivering a network fabric, it seems inevitable that network engineers will have to use and understand VXLAN in the not too distant future.

As usual, this post is not meant to be an introduction to the technology; I assume you have at least a passing familiarity with VXLAN. Instead, I will jump right into 5 operational/technical/functional aspects of the protocol.

For more information on VXLAN, check out the draft at the IETF.

I was prompted to write this when I observed someone the other day who was sitting in the same training as me taking notes in a self-addressed email. No offense to people who do this, but W. T. F. How are you going to keep track of that email among the dozens/hundreds you receive every single day?

I take a lot of notes for research, certification study, and training. I use MediaWiki for almost all of these notes. Here's why.

Following on from my previous "triple-F" article (Five Functional Facts about FabricPath), I thought I would apply the same concept to the topic of Overlay Transport Virtualization (OTV). This post will not describe much of the foundational concepts of OTV, but will dive right into how it actually functions in practice. A reasonable introduction to OTV can be found in my series on Data Center Interconnects.

So without any more preamble, here are five functional facts about OTV.

Normally I talk about overlays in the context of data center/SDN/cloud but today I'm going out into left field and am going to talk about voice! :-)

I freely admit that I'm a noob when it comes to Cisco voice so I'm not sure if the behavior I'm about to describe is obvious or not. It wasn't obvious to me and I only figured it out after running into the issue for real and troubleshooting it to resolution.

The issue stems from my misunderstanding about how dual-line ephone-dns function when used in an overlay.

This post is about finding and fixing a memory leak I discovered in the SNMP daemon, snmpd(8), in OpenBSD. This sort of analysis is foreign territory for me; I'm not a software hacker by day. However, using instructions written by Otto Moerbeek as my Rosetta stone and Google to fill in the blanks when it came to usage of the GNU debugger, gdb(1), I was able to find and fix the memory leak.

I'm documenting the steps I used for my future self and for others.