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

Get Out While You Still Can

For years, this blog has mostly been about enterprise IT with a focus on networking. I’ll spare you the entire history because no one cares. But in short, if you dig through the archives, you’ll find content going all the way back to the beginning of 2007 when I was writing for my CCIE study blog.

Ten years, hundreds of articles, and millions of words later, I am a full-time writer and podcaster covering enterprise technology for engineers from behind a microphone and keyboard. But I don’t do that here anymore. I do that at

Before Packet Pushers became the thing that put food in my mouth, I’d split my enterprise tech writing between this blog and that, but splitting the content just doesn’t make sense now. Thus, I’ve been putting all my enterprise tech writing under the Packet Pushers flag. Packet Pushers Interactive is my company that I co-founded, and I’m proud of it. There is no reason to straddle the fence.

So, what of this blog? will be where I write about…

  • General technology. For example, I’m into the Garmin & Apple ecosystems. I read a lot about alt-energy. I cover many other nerdy topics with my friend Eric Sutphen on the weekly Citizens of Tech podcast (not a Packet Pushers show, just a side project). I like cars, particularly Subarus. I’m into science. Body hacking through fitness and nutrition is interesting to me, too. Data, data, data. If there’s actual data behind it, I might write about it.
  • Fiction. I have a lot of nerd-oriented fiction ideas, and this blog is a good place to try them out. You know, fake stories. Like what you get on most cable news channels, only I won’t pretend the fictional stories are real.
  • The business of new media. I have opinions based on experience on how to make new media work. I believe I can address both content creators and marketers delivering messages to wise consumers who reject spammy content. (You won’t believe what happened next!)
  • Other stuff. I’m not limiting myself.

This blog change has been coming for a while. Depending on how you consume, you might have noticed a new theme a few months ago. I’ve stripped it right down to the bare essentials.

  • No ads.
  • No comments.
  • No multi-column format with circular Web 2.0 icons and waterfalls of articles & graphics that dim the power when the page finally loads.
  • No menu bars showing you a bunch of options you don’t care about.

Just the text, plus a single icon in the upper left containing the one menu on the whole site. If you want to search or navigate to older content, click the icon.

The whole idea of the new theme is to get in, load the article quickly, read, and get out. Or read the entire article via e-mail. Or RSS. Your choice. No more feeds with only excerpts to drive page view statistics or banner ad impressions.

Get out while you still can.

You’re on notice. Now is your chance to get out while you still can. You can unsubscribe from the e-mail delivery service. You can disconnect the RSS feed. It’s okay. I won’t be upset. We can still be friends. I’ll see you over at

But if you choose to stay, I’ll do my best to keep it interesting.

Auto-Adding Routes When Mac PPTP Connection Comes Up

Before you read this post, understand that PPTP is insecure. Don’t use PPTP to create a VPN to anything you care about. Really. Apple has even pulled PPTP support from macOS Sierra. Read all about PPTP’s Apple death here, and thanks to @scottm32768 for letting me know about it.


Skip to Solution #3.


When successfully making a PPTP connection to a remote VPN server with the built-in Mac OS X client, you find that you can’t connect to hosts on the other side of the VPN tunnel. You can still connect to the Internet and LAN hosts.

The root issue is that, by default, OS X has no reason to send traffic across the VPN tunnel. A reason must be provided.

Solution #1 – Setting Service Order

In System Preferences > Network, perform “Set Service Order” (the drop down gear icon), and move the PPTP connection to the top of the list.

This means that when the PPTP tunnel is up, traffic will flow through it before other network connections. This will gain you access to hosts on the other side of the VPN tunnel. It will also break everything else, unless the network on the other side of the PPTP tunnel can also service your Internet traffic. This is going to be a function of the VPN termination device as well as the firewall configuration at the remote site.

The issue here is that ALL traffic, even your Internet traffic, will be routed through the tunnel. Thus, Internet traffic on your system is tossed into the tunnel, pops out at the remote site, gets hairpinned back around right back out through the remote network’s firewall, hits the Internet server you were trying to get to, comes all the way back to the remote network, where it finally gets popped back into the tunnel to you. Not all firewalls or VPN termination devices will be configured to support this hairpin routing.

If you choose this method, remember to set a DNS server in your PPTP connection profile that can be reached via the VPN tunnel. Something public like Google’s and might work. This is important because there’s a good chance your local DNS server will become unreachable as soon as the tunnel comes up, leaving you without name resolution. You might have connectivity, but without name resolution, it will feel like you don’t.

Solution #2 – Disabling Split Tunneling

By default, OS X will “split tunnel” when using the built-in PPTP client. That is, traffic will follow OS X’s routing table. Networks on the other side of the tunnel flow via the tunnel, assuming there are routes that send appropriate traffic that way. Other traffic, such as local LAN or Internet, flows via the wifi or Ethernet connection directly – no tunnel. Therefore, traffic is “split” between the tunnel and physical network interfaces. You can check OS X’s routing table via netstat -rn.

The catch here is that bringing up a PPTP tunnel doesn’t automatically add routes to OS X’s routing table, which is why your PPTP tunnel doesn’t seem to be working and you’re reading this article. There’s a tunnel, but nothing instructing OS X to forward any traffic across that tunnel. Therefore, you’re going to check a box that defeats split tunneling, forcing all traffic into the tunnel.

In System Preference  > Network, select the PPTP connection profile. Click the “Advanced…” button. Check “Send all traffic over VPN connection”. In this case, the service order doesn’t matter.

All the same caveats about hairpin routing and DNS as mentioned in solution #1 hold true.

Solution #3 (and my favorite) – /etc/ppp/ip-up

The script /etc/ppp/ip-up will automatically fire after a PPTP tunnel is brought up. This appears to be default behavior in *NIX kernels, based on this.

Once the PPP link is established, pppd looks for /etc/ppp/ip-up. If this script exists and is executable, the PPP daemon executes the script. This allows you to automate any special routing commands that may be necessary and any other actions that you want to occur every time the PPP link is activated.

This is definitely the behavior of OS X. When the PPTP tunnel comes up, the /etc/ppp/ip-up script fires. Therefore, you can use this script to add routes to the OS X routing table.

1. Create /etc/ppp/ip-up as sudo. If you aren’t a sudo-er on your Mac (i.e. not an admin equivalent), this is going to be an issue for you. You have to have root equivalent to edit this script. I use vi as my editor. Thus, sudo vi /etc/ppp/ip-up.

2. Let’s say there are two networks I care about on the other side of my PPTP tunnel: and An /etc/ppp/ip-up script to add them to the routing table could look as follows.

/sbin/route add -net -interface $1
/sbin/route add -net -interface $1

3. We’re using the explicit path “/sbin/” to be certain that the script can find the route command.

4. The $1 is a variable representing the name of the interface used by PPPd.

5. Make sure root is the owner of /etc/ppp/ip-up. It should be by default. sudo chown root /etc/ppp/ip-up

6. Make sure the script is executable. It will not be by default. sudo chmod 755 /etc/ppp/ip-up

The next time you bring up a PPTP tunnel, /etc/ppp/ip-up will run, adding those two routes to the OS X routing table. Don’t forget that you can validate that the script ran by looking at netstat -rn.

With the routes added to the routing table, OS X knows to send traffic for those networks across the tunnel.

This isn’t a perfect solution, as the script is a blunt hammer that doesn’t distinguish between tunnels. This particular script will add those routes to the OS X routing table, no matter what PPTP server you access. You’d need a smarter script to support multiple PPTP sites, which is beyond my scope here. Maybe in a future post.

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.

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.

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.

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.

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.

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.

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.


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.

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

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.”

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.

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.

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.

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.