From the blog.

Managing Digital Racket
The more I tune out, the less I miss it. But that has presented me with some complex choices for a nuanced approach to curb
Complexity – My Friend, My Enemy
Over my years of network engineering, I've learned that the fewer features you can implement while still achieving a business goal, the better. Why? Fewer
Brief Me At Interop?
Want to brief me about your product or otherwise have a chat? Send an e-mail to while there's still room on my calendar. I

Managing Digital Racket

I read this article, long by today’s standards of fleeting attention. TL;DR. Information bombardment addicted the author with negative effects on his life. And while he’s not done making changes in his life, he has broken the cycle.

I’ve had similar challenges to him, and continue to hone my approach to managing digital racket. I know I’ve written about this before, but the art is evolving for me. Chronicling progress, however minor, is cathartic.

I mute nearly all notifications. This cuts down tremendously on mental intrusions, improving my focus and reducing FOMO. While you’d think turning off notifications would increase FOMO, you realize over time that you aren’t actually missing anything substantial. Once you believe this, the anxiety borne of FOMO fades away.

The only notifications I currently receive are as follows.

  1. Phone calls. I don’t get many, and most of them are directly related to my business.
  2. Direct messages from my immediate family.
  3. Direct messages from my three co-workers and a few close collaborators.

I have deleted most social media apps from my phone. I have a few for the sake of convenience when abroad, but rarely access them. With notifications turned off, the temptation is practically nil. Twitter is my greatest temptation, and therefore do not keep it on my phone at all except at conferences. Buffer allows me to queue tweets without having to interact with Twitter directly.

The most notable social media app that remains on my phone is Reddit. However, I don’t use Reddit for work, so it’s not a distraction during my working hours.

On my Mac, I use the multiple desktops feature. The main desktop is my working screen. Here, I have my Chrome browser, research documents, and terminal consoles. In one Chrome tab, I have my company’s Slack group, as it’s a critical part of my workflow along with Trello and Buffer. Wunderlist keeps me focused. Scrivener organizes my writing projects.

The secondary desktop contains social media and other distracting things. For instance, I have Safari running Tweetdeck and LinkedIn. I also have the Slack app with the myriad non-company groups I’m in running as a separate window.

To access the other desktop, I must deliberately perform a 4-finger swipe up, and then choose the other desktop with a point-and-click. I have disabled the “Swipe between full-screen apps” feature that allows for quick 4-finger swiping between desktops with my trackpad. This means that switching to the secondary desktop is a conscious choice that puts me in a different mindset. Am I willing to give into temptation and look at that other desktop? Or is it easier to actually stay in the zone and keep working? The swipe, point, and click gives me just enough time to avoid losing my productivity mojo.

Couldn’t I just, in a moment of weakness, open Tweetdeck on my primary, working desktop? Of course. But there’s something that chafes in my brain when I try it. After a couple of weeks of segregated desktops, looking at Twitter on the main desktop feels like an unwelcome intrusion.

I have regular screen moratoriums. Lately, this comes in the form of a weekly outdoor excursion. Assuming I’m not on a plane and weather permitting, I’m outdoors every Saturday, usually hiking a lot of miles in the mountains. I have a GPS watch I use as a tool. I have a phone with me for safety reasons. But for the last several weeks, I haven’t used my phone, even to take a picture. The phone stays in my pack.

While I can’t prove this, my feeling is that putting the screen away for the several hours I’m in the woods each week is important to my mental health. The complete screen disconnect somehow hits a reset button that allows me to function with a clearer brain the next week. Again, this is anecdotal. I can’t prove this yet. But I do know that for the last few weeks, thinking and producing has been easier for me.

Ethan Banks writes & podcasts about IT, new media, and personal tech.
about | subscribe | @ecbanks

In Chicago on October 26? Come think about SD-WAN with me.

On October 26, 2016 at 5:30p, I’m speaking to a couple of Chicago-based MeetUp groups banding together to hear me discuss implementing SD-WAN. Sign up here. Or here.

The talk will be held at Cisco Systems Building – SkylineATS, 9501 Technology Blvd. 3rd Floor, Rosemont, IL.

This SD-WAN discussion is aimed at network engineers and other technologists who need to understand and recommend technology solutions for their organizations, as well as those who need to make the silly things vendors sell us actually work.

My goal is to make sure you’ve got plenty to think about as you explore SD-WAN. The talk will take away some of the, “You don’t know what you don’t know.”

I’ll cover the following.

  • An overview of what SD-WAN really is.
  • Integrating WAN optimization and SD-WAN.
  • Managing existing private WAN contracts.
  • Managing your own internal SLAs.
  • Relating SD-WAN to XaaS you might be using.
  • Considerations for multi-tenant environments.
  • Handling deep packet inspection requirements.
  • Leveraging TDM and other non-Ethernet circuits.
  • Bandwidth scaling.
  • WAN circuit design recommendations.
  • Integration with your existing routing domain.
  • A list of SD-WAN vendors & their products.

I hope to see you there.

Ethan Banks writes & podcasts about IT, new media, and personal tech.
about | subscribe | @ecbanks

Presenting Technical Topics To Technical People

Fred writes, “I’ve got a conference coming up in December that I’ve been invited to speak at. This is something I’ve wanted to do for sometime. However, having never done it, I’m looking for some tips on how to get started.”

Q: What’s the best way to find a topic that is new enough to be interesting, but relevant enough to be useful?

People go to conferences hoping, among other things, to gather information that they didn’t have before. What that is will vary by audience member. Designers, architects, and C-levels who are trying to stay ahead of the curve will want to know about the future — what tech is coming and the likely impact to their business and operations. Engineers and operators — the people down in the blood and guts of IT — will be more interested in hard skills.

By “hard,” I don’t mean difficult. I mean useful tools and techniques that they can bring back to their job with them and put to use.

  • When addressing an engineering audience, the most engaging talks will be technical ones that go into specifics. The catch here is that most talks are in the 30 to 60 minute range. Therefore, the speaker must balance technical specifics with getting through a useful amount of material. If that balance can be struck, there’s a good talk to be delivered.
  • Hardcore techies also like skills that can keep them ahead in their career. Skills related to techniques or products that are growing in demand will garner a lot of attention. For instance, networkers have been excited about programmatic network automation over the last couple of years.

Everyone likes topics that will bring value to their business. For instance, a talk that compares both the soft and hard costs of running a private vs. public vs. hybrid cloud will be a thought-provoking chat. Why? Quantifying such things is difficult, and a talk that breaks down costs of such complex architectures often puts the audience in a situation of, “I would not have considered that on my own.”

Understand the difference between media buzzwords and real-world usefulness. Buzzwords take on lives of their own in media. All of a sudden, everyone is talking about devops, serverless, microservices, and containers. Yes, those terms have a real meaning and are useful to certain organizations. But are they useful to your audience? Or just a trendy curiosity? Don’t chase hype in the hopes of having a well-attended session. Place delivery of value above all else.

Q: How do I prepare? I’m a horrible procrastinator.

Procrastination is the enemy of an effective presentation. The day of delivery is not the deadline. Rather, you need time to prepare your slides, learn your talk, edit the talk, and perfect your delivery. Time is not on your side. Therefore, start now. Only if you realize what’s truly ahead of you will you find the motivation to get started.

This doesn’t mean you’ll have a perfect presentation a few weeks before you head to the podium. If you are the fretful type, you might end up tweaking your deck until moments before you speak. But getting going means that you have a solid starting point. The plane ride should be a time for relaxation, managing the general stress of travel, and locating the nearest Auntie Anne’s or Jersey Mike’s during connections — not stressing out about slides.

Practically speaking, block out a few hours on your calendar. Sixty minutes here. Ninety minutes there. During those times, remain distraction free. Crank through version 1.0 of your presentation as quickly as possible. Don’t stop. Deep work. Get it all out there, even if it sucks. Version 1.0 might be a turd, but it’s the hardest one to push out. Once you’ve got it in front of you, you can get to work polishing.

Q: What are strategies that work well for presentation preparation and delivery?


First, get over imposter syndrome. While there’s no need to be an egomaniac, recognize that you were asked to speak for a reason. Stop with the “I wonder if they’ll like me” inner monologue and get on with it.

Now, onto the content itself.

1. Don’t boil the ocean. You will be tempted as a technical person to explain and justify everything. You can’t. You don’t have time. You must assume a certain baseline of knowledge for your audience.

2. Deliver the right content to the right audience in the right way. When proposing your talk, there was a working title and an abstract — a summary of what your talk will cover. Keep that in mind. Your presentation is a implied promise to deliver certain information. So deliver.

When deciding how to deliver your information, one approach is to think of it like a story. Your presentation has a beginning, middle and end. This perspective will help you with flow.

If your presentation is meant to be persuasive, then it has a main point — a thesis you want your audience to remember when they leave. All points must support that main thesis point, or they belong to another talk. Don’t assume technical talks are not persuasive. Tech talks very often are persuasive, or could be structured in such a way.

Finally, know your audience. Nerds have different buttons to push than C-levels. Structure your content to meet your audience where they are at, and then take them a little higher.

3. Do not start your presentation prep by opening PowerPoint or Keynote. Instead, write out your main points, text, or notes first using an editor of your choosing.

Your slides are not your talk. Rather, slides should have a minimum of information that act merely as a reference point or visual aid for the audience. If your presentation has detailed information, refer people to a URL where they can download a comprehensive companion document.

Remember — text walls suck. Your audience can read your slides or listen to you talk, but they can’t do both. Credit to Slide:ology.

Slides must be necessary. Diagrams must be necessary. Or skip them. You don’t need a lot of them. Most of the world’s public talks were given before screen projection and slides. YOU are the object of your live audience’s attention.

4. Give your talk and time yourself. You must know if you’re too fast or slow, have enough material or too much. Know which slides you can skip if you run short of time. If you’re an experienced speaker and know your own cadence well, you might be able to get away without this. Otherwise, plan on a couple of dry runs.

5. Know your equipment, both hardware and software. You should know how to deal with secondary monitors, and you should know exactly how your presentation software works in a dual-monitor setup.

For example, PowerPoint has a Presenter display + audience display that works with dual outputs. You’ll see a Presenter display on your screen with a timer, your notes, the current slide, and the upcoming slide. The projector screen viewed by the audience will have the actual slides.

6. Include the extras. If you send your slides to a handler who will stage them for you, make sure you include special fonts or other supporting templates, etc. Fonts matter greatly to the overall look and feel of your presentation. Some templates rely on specific fonts to render icons that will render as generic squares or odd characters if the font is missing. A missing font can result in a deck that’s ugly at best and unreadable at worst.

Alternatively, you might export your presentation to PDF or JPEG to ensure that your deck appears exactly how you intended. I have had handlers build decks on their own platform for me using the PDFs or JPEGs I sent to them. In a pinch, it can be done. Just ask.

7. Check out the venue before it’s your time to speak. Talk to the A/V staff ahead of time if you can. You want to know the stage, the screen or screens, and the size of the room. You should also sort out how to hook up your laptop and prove that it works with your connectors and setup. You want to know how you’ll be mic’ed. That could be simply you standing in front of a podium with an attached mic, or via a wireless lavalier mic. 

Be prepared to interface your laptop with anything. VGA, DVI, and HDMI are all common. If you want to use your own laptop, then it’s on you to be able to interface with whatever is at the venue. Have those cables and adapters ready, just in case.

Practice mic technique if you’re not used to being amplified. Hearing your own voice booming over the house sound system can be a little strange at first. If you can work with the mic and get comfortable with how you sound before you start speaking, that can take away some anxiety.

Realize that an empty room will sound loud and boomy compared to a room with fifty or a hundred people in it. From an acoustic standpoint, people are sound-absorbing meatbags. The more bodies in the room, the higher the contrast will be between your empty room practice and live presentation delivery.


1. Do not use “slide builds.” These are slides that use animations or transitions, and build over time as you click. These building features are rarely helpful to the audience, more often serving as distractions. Stick with static slides.

This is also helpful for exports of your deck. By eschewing slide builds, the live audience gets the same product that someone watching your presentation on or other slide archival site will get.

2. Wear something that makes you feel confident. Attire that makes you look your most attractive builds confidence in front of others. But before you pick your favorite Marvel t-shirt…

3. Wear something appropriate. Your clothes need to fit, and should match or exceed the “dressiness” of your average audience member. You are sending a message with your appearance. You might also be live streamed or archived on YouTube in HD. 1080p HD leaves nowhere to hide. So, try to care a little bit.

Most of you reading this will not have the level of notoriety that will give you a pass on your personal appearance. While I might listen to Steve Wozniak deliver a talk in his very finest underpants, there’s no chance I’ll listen to you in yours.

If you’d like more specificity, then I recommend the following.

  • For a west coast / SanFran / Silicon Valley crowd, dark wash jeans paired with a collared shirt works fine. But you can get away with just about any level of nerdy eccentricity that strikes you. I’ve seen multi-colored hair, tattoos, nerdy t-shirts, sockless, shoeless, and bare footed presenters.
  • For an east coast / NYC crowd, consider going upscale. A two piece suit without a tie would not be overkill. Young east coasters are dressing up these days, particularly those working in finance.
  • Las Vegas conferences are a melting pot. I’d go with your west coast vibe. Being sober with most of your body covered is likely to be adequate in this context. It sounds like a low bar to set, but I have sat through sessions where the presenter clearly believed in better presentations through chemicals.
  • Consider that lav mics clip to button-up shirts more easily than t-shirts.

You should also consider vendor logos. Wearing vendor-branded attire could be an implied endorsement. The same concern follows for laptop stickers if that laptop will be visible to your audience or to cameras. Sure, you might love Juniper. But do you want to be that person wearing a Junos hat while delivering a vendor-neutral presentation on layer three campus network design? Or wearing your employer’s shirt when you’re not representing your employer while giving your talk? Maybe you do. Maybe you don’t. It’s worth thinking about.

4. Be yourself. For instance, don’t try to be a comedian if you’re not one — very few are. Lame jokes fall flat and can make people feel awkward. Don’t get me wrong. Humor is fine! Be sarcastic, poke fun — those are good things. But don’t use your presentation as a chance to channel your inner stand-up comedian.

If you’ve never studied how stand-up comedians perform their craft, it’s with a lot of trial and error, as well as practice of fledgling material in front of live audiences. Unless you give this one talk so much that you practice delivering comedic lines to get your wording and timing just right, most punchlines are better left to the pros.

5. You might get introduced. You might not. You might be asked to deliver a “house” message. You might not. Just roll with it. Be a pro. Don’t let the little things throw you.

6. Choose whether to have Q&A during or after your presentation. It’s trendy to set up your talk as if you’re about to start a dialogue. “Let’s keep this interactive,” I’ve heard several presenters say as they open a session. I grasp, and even applaud, the spirit of that, but accepting questions during your presentation is a little bit dangerous. You must keep control of the room, or you’ll never get through your talk.

On the other hand, holding all questions until after you’re done can be dangerous. If you are a talker, you might go right to the end to get through your material. That leaves no time for Q&A in conference settings where folks have to scramble to get to the next thing on their schedules.

7. Repeat audience questions. If someone is asking questions and they are not mic’ed, you need to re-state the question for the audience before answering. This keeps the room together, which is absolutely critical especially as the session wears on. People are easily distracted by their screens, so you need to keep attention focused by making sure everyone knows exactly what question is being answered.

8. Be ready for the afterglow. After the talk, the microphone will turn off, and most folks will disperse. But a few people will want to chat with you. Be ready for this in several different ways.

Anticipate weird questions. Some questions might have had something to do with your talk, but maybe not. Don’t feel like you have to fake an answer right then and there. You don’t. Humbly offer your best opinion if you have one, but don’t be upset if you don’t. Just tell the person honestly that you’ve not been in their situation before.

Remember, you’re not there to give away free consulting. You want to be polite and helpful in the way that all non-sociopaths do, but you have no specific obligation to solve their problem. Even so, if the question is interesting and you’re available, you might be able to engage them as a consultant after the event. Which reminds me…

Have business cards handy. A few folks might want to follow up with you after the event. The easiest way to facilitate this is with a business card. You can get a box of more than you’re likely to ever need for $10 or so. Hand them the card, and they can get on their way to their next event while still being able to get a hold of you later on.

Be ready to say, “Thank you.” Some folks might just want to express their gratitude for your talk. Smile, nod, and thank them. If it gets weird after that, ask them where they work or what they do to de-fuse the awkwardness.

Ethan Banks writes & podcasts about IT, new media, and personal tech.
about | subscribe | @ecbanks

Slack. Less Bad Than The Rest.

A topic I complain about with some regularity is my inability to keep up with incoming messages. I’m too busy creating something for someone else to consume to bother trying to keep up. That’s the way of things. If I successfully keep up with all the input, I never achieve useful output.

In this world of message misery, Slack is my friend. I find that Slack is better at managing input than most other forms of communication.

As Slack groups form (I’m in 8 now), it allows me to interact with people in a private or semi-private manner in a way that’s less intrusive than Google Hangouts or an iMessages chat room.

Slack groups are far better for me than e-mail. I have a passionate dislike for e-mail, although I’ve gotten better at managing it with process and tools. E-mail remains useful to me because it’s the lowest common denominator of communications. If nothing else works, then I can probably send the person an e-mail.

At the moment, Slack is the “least worst” way to manage communication for me.

  • I can mute as well as tune notifications. I often mute entire channels that do not require real-time interaction. I can also set do not disturb times. I can also tailor notifications on mobile differently from notifications on my desktop. I find real-time notification disruptive, so I tend to shut them all off with a few exceptions for co-workers who likely need my attention immediately.
  • I can organize the messages. This is a function of how Slack works. There is a natural hierarchy of groups, public and private channels, private group chats, and one-to-one chats.
  • I can search the messages. Message search is absolutely critical for any message database where the data contains action items. Slack has never failed me. My inbox search has been great with web-native Gmail, which I never use. Airmail, my current favorite IMAP client, does search reasonably well, but I’ve found message search to fall short on all other IMAP clients I’ve tried.
  • I can set reminders. This simple feature is a valuable aid to not forget an action item.
  • I can integrate with other apps. Slack has an API, and there is a good bit of integration with other tools that makes Slack my one-stop shop for keeping up with what’s going on in my company. For instance, Trello activity can be reflected in a Slack channel.

Therefore, Slack becomes chat with the benefit of e-mail search, and without the cryptic clumsiness of IRC. Since I deal with a company team as well as peers spread all over the world, Slack fits. IMO, it’s the best way to deal with a bad problem.

Ethan Banks writes & podcasts about IT, new media, and personal tech.
about | subscribe | @ecbanks

Interview: Dr. Pat McCarthy Of The Giant Magellan Telescope

On the Citizens of Tech Podcast #43, we interviewed Dr. Patrick McCarthy of the Giant Magellan Telescope project, currently under construction in Chile.

The GMT is in a new class of “extremely large telescopes.” Featuring a custom glass formulation, seven asymmetric mirrors being polished in Arizona, and software that will correct in real-time for atmospheric distortion and physical alignment, the GMT will gather images too dim for us to have ever seen before.

Among the anticipated advances is the ability to see planets orbiting distant stars, allowing us to get that planet’s spectrographic signature. That data will help us find planets with the chemical signatures of life. We’ll also be able to look ever further back in time as we observe across light years, clarifying our understanding of the universe’s opening moments.

Pat was an outstanding spokesman for the GMT, clearly explaining the project’s worth to science, construction challenges, and relation to other extremely large telescope projects. He also helped us understand the pros and cons of terrestrial vs. space-based telescopes.

Ethan Banks writes & podcasts about IT, new media, and personal tech.
about | subscribe | @ecbanks

MacBook Battery Replacement Requires Admin Credentials?

Over the weekend, I investigated the possibility of Apple replacing the tired battery in my four year old rMBP13. Yes, they can do it. It’s $199 for that particular model. But they also require an admin-level username and password for the device. Here’s an excerpt from the chat session.

Apple support rep:

What is the Admin Name and password for your Mac?


Will not share. Definitely should not be required for a battery replacement.

Apple support rep:

It is required. When the Mac goes to the repair depot that is required. You can remove that information so there is just an automatic log in. And you can set it up again when you get it back. We do not ask for any information that is not required.


Okay, then we’re done here. Thanks very much for your help!

An automatic log in, while an improvement from a certain point of view, isn’t a fix. No, you don’t have to know the user/pass now to access the system now, but you’re still on the system with admin-level credentials. Anyone with admin equivalent credentials to the system can, with a minimum of effort, get into whatever part of the file system they might like, make changes to the system, etc.

No one should give these level of credentials to anyone, let alone Apple over a chat session. Not even a properly-encrypted-with-a-valid-cert chat session that makes me believe I was, in fact, speaking to an official Apple representative.

Battery replacement in a compact laptop chassis such as a modern MacBook is an arduous affair, which is why I’m happy to pay someone else to do it. But the price of admin equivalency, even temporarily, is a price too high. Whatever the technical reasons might be for this current requirement, Apple should do better. I suggest a service mode that could be used to verify that the replacement battery installation was successful. No doubt it’s not that simple. Nothing ever is.

I’ll try a meatspace Apple store and see if there’s a way I can get the replacement done without having to hand over the admin credentials.

Ethan Banks writes & podcasts about IT, new media, and personal tech.
about | subscribe | @ecbanks

Connecting Python To Slack For Testing And Development

The scripting language Python can retrieve information from or publish information into the messaging app Slack. This means you can write a program that puts info into Slack for you, or accepts your queries using Slack as the interface. This is useful if you spend a lot of time in Slack, as I do.

The hard work of integrating Slack and Python has been done already. Slack offers an API, and there are at least two open source Python libraries that make leveraging these APIs in your Python code a simple task. I chose slacker after a bit of googling, but it’s not a preference borne of experience. The community seems to be behind slacker as opposed to Slack’s own python-slackclient, so I went that direction.


  1. I’ll assume you’ve got Python installed already. My environment is Ubuntu Server 16.04 with Python 2.7.12.
  2. Install the python package manger pip, if you don’t already have it.
    sudo apt install python-pip
  3. Install the slacker python library.
    pip install slacker
  4. Generate a testing and dev token at the Slack API web site.
  5. The token will be everything required for authentication to your Slack group. Protect it like a password.

Armed with the token and slacker library, your Python installation is now Slack-capable.


I took this code right from the slacker github page to make sure things were working without having to read any documentation. I created a channel called #exp to run my test in.

from slacker import Slacker

# Replace abcd-etc. with your testing and dev token
slack = Slacker('abcd-*****-*****-*****-*****')

# Send a message to #exp channel'#exp', 'Python was here.')

I ran the test using python

The result looked as follows.


Ethan Banks writes & podcasts about IT, new media, and personal tech.
about | subscribe | @ecbanks

Chicagoans: TECHunplugged Is Coming October 27, 2016

TECHunplugged is a one-day event where end users, influencers and vendors come together to talk shop. At the Chicago event on October 27, 2016, I’ll be speaking on the following big idea.

How The Network Automation War Might Soon Be Won

Here’s the abstract I proposed to the TECHunplugged team.

Automation in the virtualization world is a long-established feature. A plethora of excellent tools exist to help stand up server infrastructure, operating systems, and applications. This has helped bring much of the IT stack together in a way that makes system deployment a repeatable, predictable task. By contrast, network automation is a struggling, emergent technology. Why is it that the automation of network provisioning has proven so challenging?

Ethan Banks, 20 year IT veteran and co-host of the Packet Pushers podcasts, will explain the network automation challenge from a practitioner’s point of view. He’ll also discuss recent advances in network automation tooling from both the open source and commercial software worlds. Network automation might feel rather behind other IT silos, but there’s significant progress that will change network operations sooner rather than later.

To set context, I’ll explain why automating the network is so hard.

  • No standard way to describe a desired outcome.
  • Proprietary interfaces.
  • Snowflake architectures.
  • Unpredictable ways of measuring results.
  • A surfeit of choice.

And then we’ll talk about what’s being done to enable network automation.

  • Intent.
  • Abstraction.
  • Telemetry.
  • OpenConfig.
  • The simplicity movement.
  • Vendors like Anuta, Apstra, and Glue.

If you’re in the Chicago area, register. You’ll hear me speak along with several other folks. I’ll also be at an “ask me anything” roundtable.

Ethan Banks writes & podcasts about IT, new media, and personal tech.
about | subscribe | @ecbanks

For Your Ears: Citizens of Tech Podcast 40

In this show, we get into what expiration dates on packaged food and drugs really mean. How should you react when the date expires? If you assume, “Throw it out to be safe,” you’d be wrong.

We also chat about dealing with password expiration policies. They must be super complex and changed frequently, right? Maybe not. Super complex and frequently changed means hard to remember, which studies show can lead to less security, not more.

IBM has manufactured an artificial neuron, which isn’t so interesting by itself. We’ve been here before. The interesting bit is the material used to behave like a neuronal membrane. A genuine advance.

Microsoft has announced a smaller XBoxOne S, now with 4K capabilities. Just not gaming 4K capabilities.

Blackberry is on permanent deathwatch now, as they have begun the, “All else has failed, so let’s litigate,” phase of operations.

All that, plus our regular “Content I Like” and “Today I Learned” features.

Expiring Stochastic Passwords – Citizens of Tech 040

Ethan Banks writes & podcasts about IT, new media, and personal tech.
about | subscribe | @ecbanks

I’ll See You At Cisco Live 2016 Las Vegas

I will be at Cisco Live 2016 in Las Vegas. So far, my calendar has me scheduled to attend some Tech Field Day presentations, visit with vendors, hang out in the Social Media Hub, and host a CloudGenix SD-WAN mixer event (free food and drink for all, plus fellow nerds to network with, just register).

I’m just at CLUS on a social media pass, so I won’t be at all of the Cisco-specific events. That pass doesn’t get me into all the things I don’t think, but at least I’ll be around.

If you’re a vendor who would like to brief me at CLUS, I’m happy to chat. Please schedule me. If you like the podcast, I’ll have Packet Pushers stickers for you to decorate your lanyard or laptop with.

At the end of the day, I just like hanging out with nerds, so I hope to see you there. Come up and say “hi.”

Ethan Banks writes & podcasts about IT, new media, and personal tech.
about | subscribe | @ecbanks

Complexity – My Friend, My Enemy

My Twitter blew up after I tweeted thusly.

Why did I tweet this?

Over my years of network engineering, I’ve learned that the fewer features you can implement while still achieving a business goal, the better. Why? Fewer features mean fewer things that can potentially go wrong. The less that goes wrong, the higher the network uptime. That’s a generalization we could pick at, but I believe it holds true overall.

I have an example of a lesson learned.

Going back almost 10 years, I was an architect at a site evaluating Cisco’s VSS. This was early days for VSS, and the code was not fully baked. Still, on a whiteboard it sounded like a good idea, and offered us a tidy way to uplink our dual-homed access switches to a VSS core without having to block uplinks. That was compelling, as we were still in the 1GbE uplink days, and link saturation was happening from time to time.

What is VSS and any of the similar systems that create a virtual chassis or MLAG capability? It is a complex, distributed control plane, where two or more physically distinct systems maintain constant communication so that they can behave as a single physical system.

I remember reading a detailed Cisco technical whitepaper on VSS that explained just how the magic happened. It sounded…okay. There were dedicated links between the switches. There was some special tagging going on. There were processes to assign which switch would be the master. There were discussions about how to prevent and recover from split-brain. There were notes on what would happen during a single supervisor engine failure. And so on. It all seemed well-thought out and carefully considered. And no doubt it was.

Yet in our lab testing, VSS was a disaster. At that point (very early days, please remember), the code was so underdone as to hard crash IOS and create a cascading failure between the two VSS members. One switch would crash hard, and reboot. On reboot, it would cause the other switch to crash, and so on. I remember walking into to the lab racks after we’d stood up the initial VSS pair, and looking at console output. They had been cascade crashing back and forth for hours, and none of us on the team had been doing any work. The VSS pair blew up all on its own, without even a test traffic load going through them.

This problem was so bad, that we couldn’t get our testing done. We thanked Cisco kindly, and shipped the test sups back.

Complexity kills, but sometimes we need it.

Now, years have gone by since that VSS story. I know of many folks with successful VSS implementations. 1.0 code is always risky. I’m not suggesting that you shouldn’t use VSS. If it’s working for you, have at it.

However, I am suggesting that the complexity introduced by VSS created fragility in the switching system. From that, I extrapolate that any sort of complexity can introduce fragility. This is not at all a new idea. I’ve heard it discussed most eloquently by David Meyer, who’s studied the issue deeply.

For the network engineer, there is irony here. Networkers have hard problems to solve for businesses. Sometimes, those hard problems call for complex solutions. If we assume that a consistently performant, always available network tends to match well with business goals, then complexity is an enemy. Simplicity is better. Less to break. A smaller dependency tree. Easier troubleshooting when something does go wrong.

Yet often (and here’s the irony), complexity is a friend simply due to the nature of the problem we’re trying to solve. Thus, we find ourselves experimenting with immature VSS code as a potential solution to engineer away uplink bottlenecks.

Or adding VXLAN overlays with a centralized controller to meet a segmentation requirement.

Or distributing policy using BGP in the form of flowspec to improve DDoS mitigation capabilities.

Or stretching L2 between data centers, and then having to implement a DCI protocol plus maybe LISP to help with traffic trombones, so that we can put any IP anywhere without disturbing the application.

Or introducing complex device profiling and authentication techniques replete with guest networks, quarantine networks, and encapsulated traffic, because BYOD. And because security.

Or creating WAN edge configurations with DMVPN, PfR, and QoS, because we have to get the most from those slow, expensive private WAN links we can’t afford to upgrade.

Or…need I go on? You can tell your own story of the lurking network horror found in a carefully crafted configuration stanza created by your own Frankensteinian hand.

Simplicity must make a comeback.

As networkers, the complexity we’ve engineered into our networks is indeed partly due to business requirements. Complexity genuinely has a place in our world.

At the same time, we receive the word from on high that we must accomplish X. And within the familiar comfort of our silos, we think about just how to accomplish X. We read. We research. We talk to our vendors. We do some lab work. And finally, we recommend a solution to X that we think will work.

Also from our silos, we probably make that recommendation. We do it without talking to the app people, the dev team, the storage admins, or even our managers if we can avoid it. We take the problem as stated to be gospel. Using the hammers we are comfortable using, we solve problems.

And now we’re screwed. All of us.

We’ve built these complex monster networks with so many dependencies, change is hard. Cloud is coming, or maybe even here, and we don’t know how to map the network we’ve got to what we’ll need next. We’ve entrenched so many special features so deeply inside of our network infrastructures, that we’ve locked ourselves in. Forget the vendors locking us in.

We did this to ourselves.

And we need to undo it. We need to go back to simple. The simpler, the better. We need to resist the temptation to hit problems with the hammers we’re used to. We need to leave our silos and start solving business problems as members of integrated IT teams. Our data center infrastructures work as cohesive, integrated application delivery systems. Why don’t we, as IT folks, follow that same integration model?

We need to be willing to professionally push back from the brink of complexity, and rally around the simpler solution. That might introduce conflict, yes. But done right, conflict will result in a better overall solution. Raising a cautionary note doesn’t make you a jerk, assuming you don’t act like one.

We need to get away from the network engineer performing complex voodoo to salvage a poorly conceived application architecture. We must be willing to demonstrate why the complex network solution is actually riskier than re-thinking the app. We won’t always prevail in those discussions, but we’ll never prevail if we don’t have the discussions at all.


As data center network designs have gone through the complexity roof, saner minds are pushing back, offering simpler solutions while still meeting business goals. is an example. Cumulus Networks’ recently announced “L3 to the host” I feel is another.

I believe this simplicity movement should continue. We all need to get to the point that we eschew nerd knobs in favor of the simplest possible solution every time. That doesn’t mean we don’t end up with a complex solution at times. Certainly, we will. But let’s do the hard work required up front to avoid complexity if we can.

Ethan Banks writes & podcasts about IT, new media, and personal tech.
about | subscribe | @ecbanks

Webinar – Challenges Delivering Apps The Modern Way

TL;DR. I’m hosting a webinar with Citrix about application deployment in the context of a modern data center — containers, NFV, etc. They are bringing nerds, and I am going to ask them questions. There’s a live demo at the end, so they’ve promised me. You should register and attend. The event is soon – Wednesday, June 22, 2016.

1280px-Citrix.svgFor a while now, I’ve espoused the notion that the data center is an engine: a group of discrete, yet tightly integrated parts that serve a single purpose. That purpose is delivering applications.

In the past, delivering those applications has been via “cylinders of excellence.” In other words, technology silos. Each engineers with his or her speciality would grind away at their little bit of infrastructure provisioning, making it do what the application needed. Many weeks later, when everyone was done their part and with a bit of luck, the application would work.

Hooray for us. We are infrastructure engineering. Only, that’s a terrible way to go about provisioning apps in an era where businesses want to stand up applications independent of an infrastructure engineer’s efforts.

The GIFEE movement (listen to Datanauts podcast #28 for an intro) is bringing automation, hybrid cloud, and — dare I include another buzzword — devops to bear on any environment willing to make the culture shift. But like any culture shift, we don’t know what we don’t know.

As GIFEE takes off, we’re finding challenges in the new approach to deploying applications. For example…

  • How, exactly, do you manage an explosion of containers?
  • Containers aren’t VMs, and you don’t access them via the networking services we’re used to. How do you handle that?
  • How do traditional load balancers fit into a GIFEE scheme? Or are they dead at this point?
  • Where does the human stop and automation start?
  • Why has modeling (think YAML) become so important in the modern data center?
  • How do you keep control over network performance, when services could be running in the public cloud across a high latency link?

I’m going to quiz Citrix engineers about all of this stuff. We’ve been working offline on the topics to cover. Even if you don’t give a hoot about Citrix, you should learn something, especially if you’re unfamiliar with containers and modern data center application delivery approaches. Register for this webinar here.

Ethan Banks writes & podcasts about IT, new media, and personal tech.
about | subscribe | @ecbanks

Should You Care About Cloud Native?

To hear vendors tell the story, every enterprise in the world will be running cloud native applications on hybrid cloud networks any second now. In fact, if you’re not already firing up those containers, your business is behind. I mean…gosh…you’re probably losing thousands of dollars each minute because you’re not agile enough. You’ll be doing massive layoffs before you’re done reading this article just to stay alive.


To understand the hype around cloud networks and cloud-native applications, you have to understand the point of them. Deploy new code quickly by minimizing infrastructure engineering involvement in the deployment process. That’s a simplification, but I think it fairly characterizes the core value proposition of devops and cloud infrastructure.

If you’re a typical enterprise, note that deploying code in this manner does not mean upgrading your MS Windows Active Directory servers more quickly, adding new functionality to SharePoint in some cloudy way, patching Oracle servers, or any of those other things you do to maintain the legacy applications you bought from “Big Software” vendors.

In fact, if you’re not developing your own applications in-house, cloud’s primary use case for you is arguably SaaS.  Not IaaS. And you don’t need a cloud network to run SaaS. You just need a decent connection to your SaaS provider.

The SaaS experience is primarily about changing the application consumption model. With SaaS, you outsource an application and its infrastructure to a provider. Ordinarily, you’d have bought from Big Software and run the pre-packaged application on your own infrastructure. With SaaS, you no longer care about the application’s installation, maintenance, or infrastructure. You pay someone else a handsome monthly fee to care about that for you.

The IaaS experience is largely about changing the infrastructure consumption model. Obviously, IaaS is very much about infrastructure. Compute, storage, networking, security, and availability requirements are still considered. But all of those concepts have been abstracted from physical servers into resources that are consumed programatically.

Clouds — IaaS — can be built privately, running on your own infrastructure. They can be consumed publicly using Azure, Google, AWS, and several others. Or they can be consumed as a hybrid of private and public clouds.

Here’s the thing. I do not believe that the SMB and mid-market making up the majority of IT shops in the world (probably you) are going to shift to cloud native applications soon. The way I see it, you don’t have the problems that the devops movement coupled with cloud is solving. In addition, you have neither the applications nor operations that map to this model especially well.

As a long-time infrastructure engineer (I was a server, storage, and backup engineer before I was a network engineer), I see a great deal of value in devops and the cloud model. It makes sense to me and pushes my nerd buttons. But I am not at all convinced that this does or even can make sense for traditional IT shops consuming Big Software applications. There is not yet a clear migration path for those who do not have their own development teams with applications to deploy.

For the average IT shop, the infrastructure play that makes more sense to me is hyperconvergence. Not cloud native.

Ethan Banks writes & podcasts about IT, new media, and personal tech.
about | subscribe | @ecbanks

Handling Criticism of Your Product

Over my years as a writer and podcaster, I’ve had a few vendors express their displeasure at something I said or did not say about their pet product. The fact is, sometimes I find babies ugly. That’s because sometimes…they are.

In fact, members of the IT community at large sometimes find babies ugly, and express those opinions in public. That’s how community works. We share knowledge, experience, and opinions. We agree. We disagree. We discuss. We speak through our microphones and keyboards, and it’s all intended to be for the greater good.

What To Do

Vendors, you are a part of that community. You’re not above it. You don’t control it. You’re simply a part of it, just like the rest of us. With that in mind, what do you do when someone in the IT community calls your baby ugly?

  1. Recognize that one member of the community doesn’t control the rest of the community. We have opinions. We share. We consider. And yes, we also influence each other as well as any audience we might have. But a single opinion shared doesn’t kill your product.
  2. A negative opinion shared publicly is a chance for you to take the information and react positively. Is the negative opinion valid? Is there an opportunity to improve the product? Is the criticizer willing to engage with you offline so that you can find out more details about their negative opinion? This is a chance for you to grow your product based on the input of someone who cared enough to talk about it in a public space! That’s gold you can’t mine any other way.
  3. Take the opportunity to patiently educate. Sometimes, media creators get it wrong. For example, I recently wrote a piece where I described a product, but made an irrelevant point along the way because of how the vendor was positioning their product. The vendor did not castigate me. Instead, they took the time to argue the relevance of my point, and convinced me that I’d gotten it wrong. Score a point for the vendor, as I’ll never look at that product in the same way and can now accurately describe it in future discussions with the community.

What Not To Do

Some vendor responses to public criticism are beyond what could be considered reasonable. I’ve heard several stories from Packet Pushers listeners and others in the IT community about how their public criticism, no matter how well-balanced or substantiated, ruined their relationship with a vendor. This should never be.

As a vendor, when you persecute a critic, it puts the rest of the community on notice that it’s safest to never talk about your products. Ever. And maybe to not use or recommend your products at all. Most humans will avoid confrontation. On the whole, aggressively going after a critic is a negative for your organization.

A defensive response is fine, and even expected. Rational, balanced dialogue and discussion are reasonable and even desirable. Going after someone’s reputation, threatening their livelihood, or making it impossible to do future business all because they made an observation about your ugly baby is unreasonable behavior.

Don’t be unreasonable.


Ethan Banks writes & podcasts about IT, new media, and personal tech.
about | subscribe | @ecbanks

Book Review: Deep Work by Cal Newport


Deep Work by Cal Newport is highly recommended if you are an information worker who is less productive than you wish you were. I recommended Deep Work even more highly if you feel you are productive, but are not producing the sort of work you desperately want to be.


More about Deep Work

I live in a state of distraction. Even working from home as a small business owner where I have no coworkers nearby, I am deluged with e-mail, Slack messages, iMessages, and other incoming data competing for my attention. This means that it’s easy to allow myself to flit from one thing to another. I’m constantly busy for many hours of the day, yet on some days struggle to accomplish anything I feel good about.

Deep Work uncovers how the information age impacts productivity. The book’s biggest idea is that truly deep work — the sort of work where you make mental breakthroughs and cognitive advances — only come with prolonged periods of focus. Maintaining focus means getting rid of distractions.

Here’s the catch. Our smart phones, inbox notifiers, and related alarms have trained our brains to seek out the quick burst of chemical energy we receive when reading whatever the alert directed us to. Therefore, breaking away from a constantly distracted life is not as simple as deciding to resist temptation.


Deep Work takes on the unlearning process. The book cites many examples from research studies and notable individuals about becoming capable of extended focus, and consequently, deep work.

Deep Work’s Specific Impact on Me

Deep Work is a book that demands action of the reader, or else it’s a mere curiosity you’ll forget about as soon as you put it down. Here’s what I’ve done so far.

  1. Shut off almost all notifications of any kind. Only for specific notifications from my family or direct messages have I kept alerts on. My family is not chatty, so I’m not deluged. That said, Slack remains a disruption (despite shutting down almost all notifications) I don’t quite know how to handle, as it is our company’s primary communications tool.
  2. Invested in anti-distraction software. I have found the urge to check Tweetdeck or LinkedIn almost overwhelming, particularly when I’m tired or finding the work I need to get done unappealing. To help break the addiction, I purchased Anti-Social. This allows me to build a list of sites I don’t want to be tempted by during times of focus. Anti-Social appears to have re-branded as since I purchased it, and is cross-platform.
  3. Invested even more energy in Wunderlist. I’ve been using Wunderlist for a while now, even before reading Deep Work. Now, I’m even more invested in it. Wunderlist defines what I’m supposed to be working on at any given time. When I feel uncertain about what to do next, Wunderlist brings me back into focus.
  4. Reading more and streaming less. I had slipped into a habit of watching 2+ hours of streaming on several nights of the week. I feel that habit was making it harder for me to concentrate during the day where I might want to read or research. I tend to watch nothing or perhaps an hour now, trading in streaming for reading. When I do stream, I mix in documentaries and other non-fiction with pure entertainment. My evidence is only anecdotal here, but I feel that my work day focus when I research or write is improving as a result.
  5. Keeping my phone in my pocket. When tempted to look at my phone, I don’t, at least not without a specific reason. I resist. This is part of the unlearning process mentioned in the book. Not picking up the phone means I’m not disrupting whatever it was that my brain was doing before it derped and said, “Hey! Check your phone for no good reason.”
  6. Deleted apps from my phone. For instance, Twitter is gone from my phone. These days, I only install it for conferences, and find it to be immediately addicting. Thus, when I’m in the airport and have said my last social media goodbyes, I delete Twitter again. And just generally, I try to keep distracting apps off my phone.

What now?

Going forward, I have more changes to make. To reinforce the big ideas, I would like to read Deep Work again, not a huge challenge as it’s an easy-to-read 263 pages. I want to read the book this second time with a more critical eye to how I’ve applied the principles thus far, and see what I can do better.

I have goals. I need to be incredibly productive for a concentrated number of hours per week. Most days, I can do my job effectively in an 8+ hour day, presuming I’m focused during that time. That allows me to write, respond to my business e-mails, take briefings from vendors, plan and record podcasts, organize conference and community events, do lab work and other research, and build presentations. Add to that whatever else I’m called upon to accomplish as a small business owner.

Allowing myself to be distracted means that I don’t accomplish as much as I need to in that 8+ hour day, and thus my day and week may drag on. As much as I enjoy technology, I’d rather be trail running or walking along a beautiful ridgeline on a long distance hike. Only if my work is done do I have that luxury of time in the great outdoors.

However, Deep Work is not merely a reboot of the classic Getting Things Done, which I also own. I want to think more deeply through the issues facing enterprise IT. Technology has no lack of complex implementation issues that present themselves once you get past a vendor’s Pinocchio architecture and turn it into a real boy. But to see the issues, deep thought is required, at least for me. I want to get that sort of thinking done as a regular habit. I want those breakthroughs. I want that insight. I want that depth.

I am reading The Phoenix Project right now, and the latest CCDE Study Guide book is up right after that. Then I’ll tackle Deep Work once again.

Ethan Banks writes & podcasts about IT, new media, and personal tech.
about | subscribe | @ecbanks

Brief Me At Interop?

I’ll be at Interop Las Vegas 2016 along with the rest of the Packet Pushers team. I’ll be busy with our Future of Networking Summit on Monday and Tuesday, but would like to schedule vendor briefings on Wednesday and Thursday. My dance card is not yet full.

Want to brief me about your product or otherwise have a chat? Send an e-mail to while there’s still room on my calendar. I look forward to seeing you at Interop!

Ethan Banks writes & podcasts about IT, new media, and personal tech.
about | subscribe | @ecbanks