50 Shades of IT


Lots of things in IT sound much naughtier than they really are.  We’re constantly inserting and removing things.  We have to get down on our hands and knees from time to time.  We even give orders that must be followed.  Needless to say, there’s a fair amount of giggling that goes on sometimes.

Enter mainstream literature.  Specifically, the 50 Shades series by E. L. James.  It’s been a bit of hit from what I understand.  The subject matter is a bit more…mature than the usual paranormal romance or magical coming of age story.  It’s about control and domination and other such heady things.  I’ve never actually read it myself.  But based on the number of people I see on airplanes secreting one of the three volumes under a scarf or blanket, I dare say that many have read it.

These two worlds collide from time to time when someone says something rather saucy in regards to enterprise IT.  On Twitter, I’ve seen hashtags for #50ShadesOfNetworking and #50ShadesOfStorage.  They always elicit a good laugh or two.  In keeping with that idea (and to avoid polluting Twitter streams), I present my list for 50 Shades of IT: The Series.

Note: None of these are inherently bad.  That being said, I’m not going to be responsible for where you mind ends up taking it.


“He bound her ports together in a lovely Etherchannel.”

“She was confident enough to display all her assets in public cloud.”

“The hosting contract defined our relationship.”

“He was pleased everyone’s router recognized him as VRRP Master.”

“He watched as she flapped the tunnel over and over again.”


“His packet inspection was the deepest she’d ever seen.”

“He had to do what he was told.  After all, she was root.”

“He injected a packet flow into her secure tunnel.”

“She wondered if the hackers would be able to penetrate her unsecured backdoor.”


“Quiesce my snapshot.”

“She gasped as he hot swapped the drive into her array.”

“She mounted his disk quickly.”

“I need you to format my partition.”

“I like big LUNs.”

Tom’s Take

If you need me, I’ll be in my bunk.

Objective Lessons


“Experience is a harsh teacher because it gives the test first and the lesson afterwards.” – Vernon Law

When I was in college, I spent a summer working for my father.  He works in the construction business as a superintendent.  I agreed to help him out in exchange for a year’s tuition.  In return, I got exposure to all kinds of fun methods of digging ditches and pouring concrete.  One story that sticks out in my mind over and over taught me the value of the object lesson.

One of the carpenters that worked for my father had a really bad habit of breaking sledgehammer handles.  When he was driving stakes for concrete forms, he never failed to miss the head of the 2×4 by an inch and catch the top of the handle on it instead.  The force of the swing usually caused the head to break off after two or three misses.  After the fourth or fifth broken handle, my father finally had enough.  He took an old sledgehammer head and welded a steel pipe to it to serve as a handle.  When the carpenter brought him his broken hammer yet again, my father handed him the new steel-handle hammer and said, “This is your new tool.  I don’t want to see you using any hammer but this one.”  Sure enough, the carpenter started driving the 2×4 form stakes again.  Only this time when he missed his target, the steel handle didn’t offer the same resistance as the wooden one.  The shock of the vibration caused the carpenter to drop the hammer and shake his hand in a combination of frustration and pain.  When he picked up the hammer again, he made sure to measure his stance and swing to ensure he didn’t miss a second time.  By the end of the summer, he was an expert sledgehammer swinger.

Amusing as it may be, this story does have a purpose.  People need to learn from failure.  For some, the lesson needs to be a bit more direct.  My father’s carpenter had likely been breaking hammer handles his entire life.  Only when confronted with a more resilient handle did he learn to adjust his processes and fix the real issue – his aim.  In technology, we often find that incorrect methods are as much to blame for problems as bad hardware or buggy software.

Thanks to object lessons, I’ve learned to never bridge the two terminals of an analog 66-block connection with a metal screwdriver lest I get a shocking reward.  I’ve watched others try to rack fully populated chassis switches by brute force alone.  And we won’t talk about the time I watched a technician rewire a 220 volt UPS receptacle without turning off the breaker (he lived).  Each time, I knew I needed to step in at some point to prevent physical harm to the person or prevent destruction of the equipment.  But for these folks, the lesson could only be learned after the mistake had been made.  I think this recent tweet from Teren Bryson (@SomeClown) sums it up nicely:

Some people don’t listen to advice.  That’s a fact born out over years and years of working in the industry.  They know that their way is better or more appropriate even against the advice of multiple experts with decades of experience.  For those people that can’t be told anything, a lesson in reality usually serves as the best instructor.  The key is not to immediately jump to the I Told You So mentality afterward.  It is far too easy to watch someone create a bridging loop against your advice and crash a network only to walk up to them and gloat a little about how you knew better.  Instead of stroking your own ego against an embarrassed and potentially worried co-worker, instead take the time to discuss with them why things happened the way they did and coach them to not make the same mistakes again.  Make them learn from their lesson rather than covering it up and making the same mistake again.

Tom’s Take

I’ve screwed up before.  Whether it was deleting mailboxes or creating a routing loop I think I’ve done my fair share of failing.  Object lessons are important because they quickly show the result of failure and give people a chance to learn from it.  You naturally feel embarrassed and upset when it happens.  So long as you gather your thoughts and channel all that frustration into learning from your mistake then things will work out.  It’s only the people that ignore the lesson or assume that the mistake was a one-time occurrence that will continually subject themselves to object lessons.  And those lessons will eventually hit home with the force of a sledgehammer.

I’m Awesome. Really.

Awesome Name Tag

I’ve never been one for titles. People tell me that I should be an engineer or an architect or a senior this or that. Me? I couldn’t care less about what it says on my business card. I want to be known more for what I do. Even when I was working in a “management” position in college I would mop the floors or clean things left and right. Part of that came from the idea that I would never ask anyone to do anything that I wouldn’t do myself. Plus, it does tend to motivate people when they see their boss scrubbing dishes or wiping things down.

When I started getting deeper into the whole blogging and influencer aspect of my career, it became apparent that some people put stock into titles. Since I am the only employee at The Networking Nerd I can call myself whatever I want. The idea of being the CEO is too pretentious to me. I could just as easily call myself “janitor”. I also wanted to stay away from analyst, Chief Content Creator, or any other monikers that made me sound like I was working the news desk at the Washington Post (now proudly owned by Jeff Bezos).

That was when I hit on a brilliant idea. Something I could do to point out my feelings about how useless titles truly are but at the same time have one of those fancy titles that I could put on a name badge at a conference to garner some attention. That’s when I settled on my new official title here at The Networking Nerd.

I’m Awesome.

No, really. I’ve put it on every conference name tag I’ve signed up for including Dell Enterprise Forum, Cisco Live, and even the upcoming VMworld 2013 conference. I did it partially so that people will scan my badge on the expo floor and say this:

“So, you’re…awesome? At The Networking Nerd?”
“Yes. Yes I am.”

It’s silly when you think about it. But it’s also a very humorous reaction. That’s when they start asking me what I really do. I get to launch into my real speech about empowering influencers and coordinating vendor interactions. Something that might get lost if the badge scanner simply saw engineer or architect and assumed that all I did was work with CLIs or Visio.

Past a certain point in your career you aren’t your title. You are the work you do. It doesn’t matter if you are a desktop technician. What matters is that you can do IT work for thousands of systems using scripts and automation. It doesn’t matter that you are a support engineer. It matters that you can diagnose critical network failures quickly without impacting uptime for any other systems. When you fill out your resume which part is more important? Your title? Or your work experience? Title on a resume is a lot like GPA. People want to see it but it doesn’t matter one bit in the long run. They’d rather know what you can do for them.

Being Awesome is a way for me to buck the trend of meaningless titles. I’ve been involved with people insisted on being called Director of Business Development instead of Sales Manager because the former sounded more important. I’ve seen managers offer a title in lieu of a monetary raise because having a big title made you important. Titles mean nothing. The highest praise in my career came not because I was a senior engineer or a network architect. It came when people knew who I was. I was simply “Tom”. When you are known for what you do it speaks volumes about who you are.

Tom’s Take

Awesome is a state of mind for me. I’m awesome at everything I do at The Networking Nerd because I’m the only person here. I also Suck equally as much for the same reason. When you’re the only employee you can do whatever you want. My next round of Networking Nerd business cards will be fun to make. Stephen and I will decide on a much less pretentious title for my work at Gestalt IT. But for my own personal brand it really is cool to be awesome.

A Guide to SDN Spirit Animals

The world of computers and IT has always been linked with animals.  Whether you are referring to Tux the Penguin from the world of Linux or the various zoological specimens that have graced the covers of the O’Reilly Media library you can find almost every member of the animal kingdom represented.  Many of these icons have become mascots for their users.  In the world of software defined networking (SDN), we have our own mascot as well.  However, I’m going to propose that we start considering a few more as well.

The Horned Wonder

If you’ve read any kind of blog post about SDN in the last year, you’ve probably seen reference to a unicorn at some point.  Unicorns are mythical creatures that are full of magic and wonder.  I referenced them once in a post concerning a network where I had trouble understanding how untagged packets were traversing VLANs without causing a meltdown.  When the network admin asked me how it was happening I replied, “They must be getting ferried around on the backs of unicorns!”  That started my association of magical things happening in networks and their subsequent attribution to unicorns.  Greg Ferro (@etherealmind) is fond of saying that new protocols without sufficient documentation must be powered by “unicorn tears”.  Ivan Pepelnjak (@ioshints) is also a huge fan of the unicorn, as evidenced by this picture:

Ivan rides his steed into battle

Ivan rides his steed into battle

The unicorn is popular because it represents a fantastic explanation for a difficult problem.  However, people that I’ve talked to recently are getting tired of attributing mythical properties of various SDN-related technologies to the mighty unicorn.  I thought about it and realized that there are more suitable animals depending on what technology you’re talking about.

King of Beasts


If you ask most SDN companies, they’ll tell you that their spirit animal is the griffin.  The griffin is a mythical creature with the body and hindquarters of a lion combined with the head, wings, and front legs of an eagle.  This regal beast is regarded as a stately amalgam of the king of beasts and the king of birds.  It typically guards important and sacred treasures.  It is also a popular animal in heraldry, where it represents courage and boldness.

You can tell from that description that anyone writing an API for their existing OS or networking stack probably has one of these things hanging in their cubicle.  It stands for the best possible joining of two great ideas.  Those APIs guard the sacred treasures for those that have always wanted insight into the inner workings of a network operating system.  The griffin is the best case scenario for those that want to write an effective API or access methodology for enabling SDN.  But as we all know, something the best strategies are sometimes poorly implemented.

Design by Committee


The opposite of the griffin would have to be the chimera.  A chimera is a mythical beast that has the body, head, and front legs of lion.  It has a goat’s head jutting from the middle of the body and a snake’s head for a tail, although some sources say this is a dragon head with the associated dragon wings as well.  This nightmarish beast comes from Greek mythology where it was an omen of disaster when spotted.

The chimera represents what happens when you try to combine things and end up with the worst possible combination.  Why is there a goat’s head in the middle?  What good does a snake head for a tail really do?  In much the same way, companies that are trying to create SDN strategies by throwing everything they can into the mix will have end results that should use a chimera for a mascot.  Rather than taking the approach of building the product with the best and most useful features, some designers feel the need to attach every thing they can in an effort to replicate existing non-useful functionality.  “Better to have it and not need it” is the rallying cry most often heard.  This leads to the kind of unwieldy and bloated applications that scare people away from SDN and back to traditional networking methodology.

Tom’s Take

Every project needs a mascot.  Every product needs an icon or a fancy drawing on the product page.  Sooner or later, those mascots come to symbolize everything the project stands for.  Content penguins aside, most projects are looking for something cute or cuddly.  Security vendors are notorious for using scary looking animals to get the point across that they aren’t to be messed with.  I think that using mythologic creatures other than the unicorn to symbolize SDN projects is the way to go.  It focuses the developers to ground themselves in real features.  Hopefully it helps them avoid the mentality that could create nightmarish creatures like the chimera.

The SDNquisition


Network Engineer: Trouble in the data center.
Junior Admin: Oh no – what kind of trouble?
Network Engineer: VLAN PoC for VIP is SNAFU.
Junior Admin: Pardon?
Network Engineer: VLAN PoC for VIP is SNAFU.
Junior Admin: I don’t understand what you’re saying.
Network Engineer: [slightly irritatedly and with exaggeratedly clear accent] Virtual LAN Proof of Concept for the Very Important Person is…messed up.
Junior Admin: Well what on earth does that mean?
Network Engineer: *I* don’t know – the CIO just told me to come in here and say that there was trouble in the data center that’s all – I didn’t expect a kind of Spanish Inquisition.


[The door flies open and an SDN Developer  enters, flanked by two junior helpers. An SDN Assistant [Jones] has goggles pushed over his forehead. An SDN Blogger [Gilliam] is taking notes for the next article]

SDN Developer: NOBODY expects the SDNquisition! Our chief weapon is orchestration…orchestration and programmability…programmability and orchestration…. Our two weapons are programmability and orchestration…and Open Source development…. Our *three* weapons are programmability, orchestration, and Open Source development…and an almost fanatical devotion to disliking hardware…. Our *four*…no… *Amongst* our weapons…. Amongst our weaponry…are such elements as programmability, orchestration…. I’ll come in again.

[The Inquisition exits]

Network Engineer: I didn’t expect a kind of Inquisition.


[The cardinals burst in]

SDN Developer: NOBODY expects the SDNquisition! Amongst our weaponry are such diverse elements as: programmability, orchestration, Open Source development, an almost fanatical devotion to disliking hardware, and nice slide decks – Oh damn!
[To Cardinal SDN Assistant] I can’t say it – you’ll have to say it.
SDN Assistant: What?
SDN Developer: You’ll have to say the bit about ‘Our chief weapons are …’
SDN Assistant: [rather horrified]: I couldn’t do that…

[SDN Developer bundles the cardinals outside again]

Network Engineer: I didn’t expect a kind of Inquisition.


[The cardinals enter]

SDN Assistant: Er…. Nobody…um….
SDN Developer: Expects…
SDN Assistant: Expects… Nobody expects the…um…the SDN…um…
SDN Developer: SDNquisition.
SDN Assistant: I know, I know! Nobody expects the SDNquisition. In fact, those who do expect -
SDN Developer: Our chief weapons are…
SDN Assistant: Our chief weapons are…um…er…
SDN Developer: Orchestration…
SDN Assistant: Orchestration and –
SDN Developer: Okay, stop. Stop. Stop there – stop there. Stop. Phew! Ah! … our chief weapons are Orchestration…blah blah blah. Cardinal, read the paradigm shift.
SDN Blogger: You are hereby charged that you did on diverse dates claim that hardware forwarding is preferred to software definition of networking…
SDN Assistant: That’s enough.
[To Junior Admin] Now, how do you plead?
Junior Admin: We’re innocent.
SDN Developer: Ha! Ha! Ha! Ha! Ha!


SDN Assistant: We’ll soon change your mind about that!


SDN Developer: Programmability, orchestration, and Open Source– [controls himself with a supreme effort] Ooooh! Now, Cardinal — the API!

[SDN Assistant produces an API design definition. SDN Developer looks at it and clenches his teeth in an effort not to lose control. He hums heavily to cover his anger]

SDN Developer: You….Right! Open the IDE.

[SDN Blogger and SDN Assistant make a pathetic attempt to launch a cross-platform development kit]

SDN Developer: Right! What function will you software enable?
Junior Admin: VLAN creation?
SDN Developer: Ha! Right! Cardinal, write the API [oh dear] start a NETCONF parser.

[SDN Assistant stands their awkwardly and shrugs his shoulders]

SDN Assistant: I….
SDN Developer: [gritting his teeth] I *know*, I know you can’t. I didn’t want to say anything. I just wanted to try and ignore your dependence on old hardware constructs.
SDN Assistant: I…
SDN Developer: It makes it all seem so stupid.
SDN Assistant: Shall I…?
SDN Developer: No, just pretend for Casado’s sake. Ha! Ha! Ha!

[SDN Assistant types on an invisible keyboard at the IDE screen]

[Cut to them torturing a dear old lady, Marjorie Wilde]

SDN Developer: Now, old woman — you are accused of heresy on three counts — heresy by having no API definition, heresy by failure to virtualize network function, heresy by not purchasing an SDN startup for your own needs, and heresy by failure to have a shipping product — *four* counts. Do you confess?
Wilde: I don’t understand what I’m accused of.
SDN Developer: Ha! Then we’ll make you understand! SDN Assistant! Fetch…THE POWERPOINT!


[SDN Assistant launches a popular presentation program]

SDN Assistant: Here it is, lord.
SDN Developer: Now, old lady — you have one last chance. Confess the heinous sin of heresy, reject the works of the hardware vendors — *two* last chances. And you shall be free — *three* last chances. You have three last chances, the nature of which I have divulged in my previous utterance.
Wilde: I don’t know what you’re talking about.
SDN Developer: Right! If that’s the way you want it — Cardinal! Animate the slides!

[SDN Assistant carries out this rather pathetic torture]

SDN Developer: Confess! Confess! Confess!
SDN Assistant: It doesn’t seem to be advancing to the next slide, lord.
SDN Developer: Have you got all the slides using the window shade dissolve?
SDN Assistant: Yes, lord.
SDN Developer [angrily closing the application]: Hm! She is made of harder stuff! Cardinal SDN Blogger! Fetch…THE NEEDLESSLY COMPLICATED VISIO DIAGRAM!


[Zoom into SDN Blogger's horrified face]

SDN Blogger [terrified]: The…Needlessly Complicated Visio Diagram?

[SDN Assistant produces a cluttered Visio diagram -- a really cluttered one]

SDN Developer: So you think you are strong because you can survive the Powerpoint. Well, we shall see. SDN Assistant! Show her the Needlessly Complicated Visio Diagram!

[They shove the diagram into her face]

SDN Developer [with a cruel leer]: Now — you will study the Needlessly Complicated Visio Diagram until lunch time, with only a list of approved Open Flow primitives. [aside, to SDN Assistant] Is that really all it is?
SDN Assistant: Yes, lord.
SDN Developer: I see. I suppose we make it worse by shouting a lot, do we? Confess, woman. Confess! Confess! Confess! Confess
SDN Assistant: I confess!
SDN Developer: Not you!

Coffee As A Service

tikigiki_misc-coffee-cup-010I have a hard time keeping all the cloud terms straight.  Everything seems to be available As A Service (aaS).  Try as I might to explain them, it just didn’t click for some people.  Since cloud terms are so nebulous some times, I decided I need to put everything in a context that people understand.  Therefore, I present…Coffee as a Service (CaaS):


Software as a Service (SaaS): Anytime you want coffee, it just appears in front of you.  You don’t have to make it or anything.  Sometimes it shows up immediately.  Other times it shows up an hour or so after you wanted it.  You pay a monthly fee, but if you want to have cream or sugar you have to pay a bit more.  Some SaaS coffee vendors don’t have those options, so you’re stuck with whatever you get up front.

Platform as a Service (PaaS): You’ve decided that you want to have coffee, but you want a bit more control over it.  You sign up for a new service that gives you coffee packages.  Dark roast, light roast, and Turkish coffee are all options.  You are still at the mercy of the provider for other options like latte or cappuccino.  It is still mysteriously delivered to you.  Cream and sugar are options in each of the packages for a small fee.  Coffee can still show up late, but you have an agreement with the provider that late coffee gets you a small amount off the monthly bill.

Infrastructure as a service (Iaas): You’ve now decided that you want complete control over your coffee delivery.  You’ve contacted a new provider that is willing to rent you a coffee machine with all the extra hardware needed to make any kind of coffee you want.  You’re going to have to buy your own coffee and creamer and sugar.  Once you have it at the coffee machine, they’ll make the coffee to your exact specifications and send it to you.  Might still show up late depending on how popular the service is or if some technician accidentally restarts the machine on a Friday night.  You get charged either by the cup or by how often the machine is used.  Coffee still tastes okay but you have to worry about renting more machines as it becomes more popular.  Machine rental rates fluctuate if you use the Spot Machine market.

Private Cloud: Okay, forget about the whole renting thing.  Time to go to the coffee warehouse and buy everything yourself.  You max out your credit card, but you come home with a coffee machine and a milk steamer.  You still provide everything yourself.  You find a place to hook everything up with electricity and water supply.  You grind the beans yourself.  You make your own coffee or you hire a barista to do it for you.  The coffee is excellent and on time.  Your credit card bill scares the daylights out of you.  In three years, you have to upgrade your coffee machine again to support hyper foaming milk.

Hybrid Cloud: You can make the basics with your machine.  You still can’t figure out how to make a good cappuccino.  All the easy stuff gets made locally by you or your barista.  For the really odd stuff, like double shot mocha light frappuccinos you send people to the Starbucks down the road.

Cloudbursting: Your fancy coffee machine is really popular around the office.  About once a month, there’s a line that’s 50 people long.  Rather than making them wait for their coffee, you pass out Starbucks gift cards for anyone over the 35th person.  You send them off to get their coffee.  You can justify the gift card cost because you’re only busy that one time a month.

I’m always open for suggestions in the comments below.

Anatomy of a Blog Post

Did the title of the post catch your eye?  It’s probably a play on words or a quote from a movie.  If the title didn’t do it, the picture normally linked right under it should.  It’s probably something goofy or illustrative of the title.  After that, the next few sentences launch into an overview of the problem.  My blog posts all start out like my real life stories – lots of context so we’re all on the same page before we start discussing things.  Without a good setting, the rest of the story is pretty pointless.  The last sentence of the first paragraph is usually a question or statement relating the background to the main point.

This is the paragraph where the central point discussion starts.  Now that everyone is on the same page, the real analysis can start.  With the opening setting in mind, it’s time to lead into whatever the main point of this blog post will be.  I usually bring up commonly discussed aspects of the problem, such as urban legend or commonly held beliefs.  That way, people are nodding their heads as they read along.  Everything should be laid out on the table as an overview before diving into the topics in depth.

This is a section header designed to catch your eye or a central point that I want to reinforce.

Here is where I start dissecting the points from above.  Each point gets a paragraph and a discussion about the salient points.  Falsehoods are refuted.  Truths are reinforced.  If this is a review, there is discussion of a major section or general theme of the reviewed item.  Self contained sections are easy to digest. Plus, I’ll just keep repeating them all until I’ve brought up all the points from the introductory paragraph.  It try to keep these depth discussions to around three paragraphs because it’s easier for people to remember things with less than twenty seven parts.

There's probably some code or output in this section.  It's easier
 to type in one of these boxes.  Plus, you can usually just copy 
and paste whatever it is into your device.

Here’s where I start trying to wrap everything up and bring all the points and discussion together.  That way the big picture has now been fully developed and fleshed out.  If there are any other pieces that aren’t germane to the discussion or forward-looking statements about how the situation may change in the future, I’ll put them here as things to ponder as you get up from your desk to walk around and hope they hit you later and make you want to leave a comment.

Tom’s Take

Alliteration is awesome, right?  This is the section where I offer my own opinion about things.  Yes, many of my posts are already overloaded with opinion, but here is where I relate the whole thing to me and my outlook on things.  This is also the section where I use the “I” word, whereas I try to avoid it above.  I literally draw a line on the page so people realize this is something a bit different that what comes above.  In many ways, this can serve as a too long, didn’t read portion if you’re only interested in opinion.  I freely admit that I borrowed this idea from Stephen Foskett and his “Stephen’s Stance” closers.  I’ll probably make a flippant comment here and there, but I try to keep things coherent and on point.  And finally, when I wrap up, I usually call back to the title of the post or central theme in a funny way to reinforce what I’ve just talked about.  Anatomically speaking, of course.

If you’re curious where I got the idea for this 300th blog post, you can watch the video from Da Vinci’s Notebook for “Title Of The Song”:

IP Addresses in Entertainment

Fake IP

Every time I sit down to watch a TV show or movie and they mention computers or hacking, I get amused.  I know that I’m probably going to see some attempt to make computer hacking look cool or downright scary.  Whether it be highly stylized like Hackers or fairly accurate like the power plant hack in The Matrix Reloaded, there are always little details that get glossed over.  In many cases, one of these is the IP addressing of the systems themselves.  If the producers and writers of the film even choose to show an IP address on the screen, it’s usually so wrong that I laugh at a totally inappropriate moment of drama.

The practice of using fictitious numbering schemes for things in entertainment goes back several decades.  The first known instance of a movie using a fake number for something was in Panic in Year Zero back in 1962.  For the first time, the writers used a fictitious phone number starting with 555 instead of a real telephone number.  Even though 555 prefixes were used for things like directory assistance, they weren’t widely deployed.  As such, the 555 prefix became synonymous with a “fake” phone number.  555-0100 through 555-0199 are the only official numbers in that range set aside for fictitious use, however many people still associate that prefix with a phone number that won’t work in the real world.

Hollywood has been trying for some time to come up with IP addresses that look real enough to pass the sniff test but are totally false.  Sometimes that works.  Other times, you end up with Law and Order.  In particular, the SVU flavor of that show has been known to produce IP address ranges that don’t even come close to looking real.  This page documents a couple of the winners from that show when the police start tracing an offender by their IP address.  Some of them look almost real.  Others seem to have an octet that jumps above 255.  Still others have 4-digit octets or other oddities that don’t quite measure up.  Sure, it heightens the suspense when people can see what the detectives are doing, but for those of us that know enough to be dangerous, it pulls you out of the moment.  It would be like watching ER and hearing the doctors start talking about brain surgery, only to start cutting open a patient’s arm to get to it.

TCP/IP has a large number of address ranges that can be used in a fictitious manner. For instance, Class E experimental addresses ( were set aside and hard coded into most OSes as unavailable.  The address range for example use and documentation purposes can also serve as a safe fictitious range.  Then there’s RFC 1918.  These addresses are used for private network ranges and must be NATed to work correctly on the public internet due to their non-routability.  These would be perfect for use in movies, as they represent networks that most people use daily.  They would look believable to those of us that know what to look for.  However, I think the producers and writers avoid doing that because of the inherent curiosity of people.

The greatest example of this comes courtesy of Tommy Tutone.  The band hit radio gold with their song “867-5309/Jenny” back in 1982.  Unlike 555, 867 is a widely used prefix code in the North American Numbering Plan (NANP).  There are numerous stories of people that have received that phone number and been cursed with popularity.  One story from Brown university tells of unsuspecting freshmen that move into the dorm room with that telephone number.  The phone calls never stop until a request is made to shut down the line.  Even back in 1982, the regional Bell companies were seeing huge spikes in telephone calls to that one number.  In many cases, they had to disconnect it in order to keep the traffic to a reasonable level.  If you’re curious, you can hear some of the messages left for the unfortunate possessors of that cursed number over at http://www.jennynetwork.com

People are compelled to try things they see in movies.  This article in the Chicago Tribune talks about the writer memorizing a realistic looking number from a movie and going home to call it several times before giving up.  The movie Magnolia included the real number 877-TAME-HER which the movie studio used to record Tom Cruise giving an in-character speech about his system for the purposes of marketing.  That’s all well and good in the real world when someone gets a few occasional prank calls or other harmless issues.  What happens in a computer network when someone sees a address on TV and then decides to try and hack it?  What if they call the police and say that the computer address of a murder or a predator is on their network?  This can cause huge issues for network admins.  The nightmare of trying to explain to people that just because the Gibson in Hackers 3 is at doesn’t mean they get to assault the mail server every day would get old really fast.  And when it comes to IPv6, the opportunity for even more trouble arises.

I was a long-time player of the MMORPG City of Heroes.  One of the reasons that I liked playing it so much was the lore and back story to the world.  I was one of the players that read all of the fluff text to get a better sense of what the writers were trying to do.  Imagine my surprise when I was playing a new mission a several months ago and ran across a little Easter egg.  One of the writers decided that the imaginary world of Paragon City had long ago ran out of IPv4 addresses and decided to upgrade to IPv6.  One of the consoles in the game had a reference to an IPv6 address - 3015:db6:97c4:9e1:2420:9b3f:073:8347.  I was excited.  Finally, someone in the entertainment industry realized we were running out of IPv4!  Then I started thinking.  Right now, the allocations to the RIRs all start with 2001.  Eventually, once we get the intergalactic Internet up and running, we might end up getting into the 3000 range.  It might be a hundred years before the address above is allocated to someone.  By then, most everyone will have forgotten City of Heroes ever existed.  Putting real IPv6 addresses in movies and on TV does run the risk of having people “hacking the Gibson” when you least expect it.  I think you’ll see that even in those far-flung ranges, the odds of a fake address on TV coinciding with a real IPv6 server or workstation address, even on a global scale, is pretty slim.  Despite the fact that all our systems will be globally reachable, the IPv6 address space is so large that no two systems are likely to even overlap.  Add in neighbor discovery, duplicate address detection, and the uniqueness of a MAC address (which forms the basis of EUI-64 addressing and SLAAC) and you can see how difficult it would be.

Tom’s Take

In case the name of my blog didn’t warn you…I’m a nerd.  When I see something inaccurate in a movie, I tend to point it out.  That’s why I don’t watch Armageddon any more.  I understand that writers and directors are trying to entertain people.  When you’re trying to do that, sometimes the details get sacrificed for the sake of telling a good story.  However, when it comes to something that can represented easily for the most realistic look possible, the creative team involved should do that.  Whether it be the night sky in Titanic or the address of the mainframe in a techno thriller, I want the people that care about the production values of a movie to show me how much they care.  With the advent of IPv6, I think creating fake addresses to put in movies and other entertainment will be easier.  Given the vast range of available space it doesn’t take too much effort to pull out something “techy sounding” to put in a movie script.  Trust me, the nerds out there will thank you for it.

Velcro for VAR Engineers

When I was younger, I must have watched The Delta Force about a hundred times. One of the things I loved in that movie was the uniforms the Delta guys wore. Jet black, covered in cargo pockets, and very useful. The most compelling feature, however, was the velcro on the shoulders and chest. The Delta troopers could remove the patches on their uniforms whenever they needed to be anonymous, then put them back on at will. I loved this idea. As time has gone on, I’ve notice the same kind of capability on the new military BDUs. Rank insignia, unit affiliation, and even the name tag are all velcro patches that can be removed, reapplied, and changed as needed.

This idea of configurable uniforms finally hit home for me the other day when I was going through my closet looking for a vendor-specific shirt. Yes, I know that Greg has decried the plumage of the vendor in a previous blog post, but as a VAR I’m a bit hamstrung. Sometimes, I need to put on my Aruba shirt or my Cisco jacket or my Aerohive tuxedo. Customers feel a bit reassured when you’re wearing a shirt from a company that you’re pitching. However, I’ve noticed that all these shirts seem to start looking alike after a while. I have the same Dri-Fit Nike polo shirt with four different vendor logos. I have the same dark blue polo with three other different vendor logos. I think I have a Cisco shirt in every color of the rainbow. I even have shirts that don’t fit anymore with fun old logos, like my Master CNE. Why do I need to have that many logo shirts in my closet? Why can’t I have a little more control over my VAR uniform?

That’s when it hit me. Let’s do the velcro configurability on vendor polo shirts. A velcro patch over the left breast and maybe another couple on the sleeves. Think of the possibilities. Now, instead of worrying about what vendor shirt I’m going to wear in the morning, I can just pick out the black one or the red one. Then, when I’m ready to brand myself, I just need to pick out the appropriate patch and slap it on the velcro. No fuss, no muss. If I wear the wrong vendor shirt today, it can cause some embarrasing issues. With the patch system, I just remove the errant patch and replace it in seconds. Much easier than trying to keep track of which shirt I shouldn’t be wearing to a particular site. You could even make a big show of it. When it’s time to get work done, make a big production of taking your patch out and slapping it on. When you need to be “off the record” about something, make a theatrical gesture of ripping the identification patch off your shirt as if to say, “I’m not with this company right now. Here’s what I think.” It would be practical as well as awesome.

Sure, there are details to work out. Even getting the vendors to start offering velcro patches would be a huge step in the right direction. I’m all for this, as it means I can finally take a little more control over my wardrobe. Now where did I put that sewing machine?

Device Naming Conventions

At some point or another, we’ve all been faced with the ominous screen asking us to name a device.  Whether it be a NetBIOS name or a DNS hostname, in those critical minutes we’ve been under as much pressure as any other time in our careers.  What should we call this thing?  Should I name it something memorable?  Should it be useful?  What about some kind of descriptive codename?  I wanted to share a few things with you that I’ve found over the years that might get a chuckle or two.  Hopefully, they’ll also serve as a yardstick for naming things in the future.

More often than not, desktops that are deployed straight out of the box keep the name that they were programmed with at the factory.  This can be some strange combination of manufacturer or serial number or phases of the moon.  Unless you’re on top of things or you have a VAR doing the installation for you (yay me!), you’ve left the name alone because it’s something that you don’t necessarily care about.  Infrastructure devices, on the other hand, are devices that have to be named to function.  These are the ones that engender the most thought into what they should be called.  My first run-in with an odd naming convention came back in high school.  When I was but a wee lad trying out this scary Internet thing for the first time (through Compuserve, no less), I started emailing a friend that went to more tech-savvy school.  Her email address was hosted by the local university on a mail server they built.  It seems that the seven mail servers that hosted the university and its users were named after Disney’s seven dwarfs.  In particular, this server was named Bashful.  I always thought that was interesting, since my friend was anything but bashful.  As time went on, I realized that people started naming their computers funny things because they wanted to remember what it did or make it have some kind of special significance to them.  When it came time to name a whole set of networked computers, that’s when you usually delved into the depths of literature or popular culture to come up with naming sets.  Groups of collected individuals of diverse skill sets that help you remember what it is that your devices do.  It also affords you the chance to show how clever you think you might be.

Far and away, the most popular naming set for servers/routers/stuff is Greek Mythology.  I’ve worked on more Apollos and Zeus’s and Athenas that I have any other device in history.  Usually, you can figure out what a server is doing based on which deity it’s named after.  Zeus is the domain controller/master server.  Athena is the ticketing database or Sharepoint server.  Hermes is the VoIP server.  Funny thing though.  You hardly ever see Hades doing something.  Usually, it’s a server on the fifth or sixth reload that they don’t really care about.  Also, don’t ask what Tartarus is doing.  It’s never anything good, I assure you.  While the Greeks are popular when it comes to server naming, I’m seeing a huge uptick in Lord of the Rings characters.  This is a bit more problematic for me, since I’m not usually inclined to figure out why someone named a server Merry or Pippin.  Depending on how much server sprawl you have, you may even need to reach down to find characters that weren’t in the movies, like Tom Bombadil.  Of course, every time I see a LotR naming setup, I very much want to change the name of the primary domain controller to Mordor and then disable all user accounts on it.  Why?  Because no one simply logs into Mordor.

On the flip side, I’ve seen users that understand that naming things after Greek gods and Ian McKellen characters can be a bit confusing at times.  So they’ve swung to the complete opposite side of the spectrum and come up with their own naming convention for things.  Normally, I applaud this kind of forward-thinking approach.  However, if your code names only make sense to you, it’s not much better than naming your servers after Best Support Actor Academy Award winners.  For instance, does the server name SW2K332DC050 jump right out and tell you anything meaningful?  It took me many tries to finally figure out that this particular server is running Windows Server 2003 32-bit and is serving as a domain controller.  Of course, that was when the server was first installed.  Now, it’s a Windows Server 2008 R2 machine that’s not a domain controller and is instead running some web-based application.  Faced with a whole page full of names like that is like trying to read the phone book.  Someone coming into this environment would need a cheat sheet or at least access to the server admin team to figure out what server you were working on.

I’m a huge fan of naming conventions that convey the device’s type and purpose on one short line.  Being a VAR, it’s usually critical to me to be able to scan an environment quickly and determine what exactly I’m working with.  Calling a switch 7K-Core-1 allows me to know almost instantly that I’m working on a Nexus 7000 in the core and that there should be at least one other switch (Core-2) somewhere close by.  Naming a switch 2960S-IDC1-1 is almost as effective but can lead to issues when I don’t know where IDC1 is located.  Since I work mostly with K-12 education institutions, I usually fall back on familar location info, such as 3560-Lib-1 or 4500-Caf-2 to help me figure out where I need to start my search for these devices.  I’ve always told people that my documentation habits arise from the need for me to remember exactly what was going on when I did something six months ago.  This goes for naming conventions as well.  I may be looking at this device from a stuffy hotel room three time zones away and not have access to all of the pertinent information before a critical change must be made.  The more descriptive I can make a device name, the better the chances that I won’t accidentally remove EIGRP from the core router.

What types of naming conventions do you use?  Are you a dwarf/deity/fictional character type of person?  How about washing the hostname through an MD5 hash tool before applying it?  Maybe you just name it the first thing you see on your desk when you power it up.  I’d be curious to see what your ideas are.