ESHARP.NET

Technology and life with Eyvonne Sharp

Are we really headed for a post SD-WAN World?

By Leave a Comment

Last week, in our Network Collective show about the Cisco’s purchase of Viptela, I suggested that many vendors will soon be headed toward a post-SD-WAN view of the world. Jordan laughed and several people have mentioned it to me since. Let me explain what I meant.

In the past two years, the SD-WAN space has exploded in both the number of vendors and in industry hype. Anyone who has had a product that could be related to the WAN has begun to market an SD-WAN solution. And because Cisco, the leading networking vendor, did not have an offering that could compete on its merits, vendors clambered to fill the space championed by Viptela, VeloCloud, and other leading SD-WAN companies.

Cisco’s acquisition changes this entire dynamic. The 800 pound gorilla has entered the marketplace and the shift will be seismic. Now, SD-WAN vendors are not merely competing on merits (or more accurately marketing buzzwords), they’re also competing with the considerable name recognition and industry inertia of Cisco.

Companies who saw opportunity to scoop up customers in the absence of a strong Cisco presence will begin to reconsider their marketing strategy. Sales and marketing teams will gather to determine the next set of industry buzzwords and SD-WAN will become a phase.

What about the technology of SD-WAN? Over time, we will simply call it the WAN. The features of built-in encryption, intelligent traffic steering, and carrier agnosticism will become part and parcel to every serious branch connectivity solution. Eventually, we will talk about the old days of the WAN with nostalgia, just like 9600 baud modems.

Are we there yet? Not hardly. But mark my words, the post-SD-WAN days will be here before we know it.

Cisco Buys Viptela: What’s next for SD-WAN?

By Leave a Comment

Join me tonight (5/2) over at #NetworkCollective as we discuss Cisco’s purchase of Viptela live at 7PM. We’ll opine on this industry development and what it means for Cisco, Viptela, SD-WAN, and you!

 

It’s no secret that I’m a big fan of Viptela’s SD-WAN technology.  I presented at their FutureWan SD-WAN Virtual Summit. I talked about my experience with their solution in my video series on SD-WAN. I’ve been an SD-WAN evangelist for some time.

At the same time, I’ve not been a big fan of Cisco’s competing iWan offering — a cobbled-together collection of technologies which have been marketed as SD-WAN.  Two months ago, I wrote about Cisco’s growing identity crisis as it relates to SD-WAN with Viptela’s solution in mind.

Now that Cisco has announced the purchase of Viptela for $610M in cash, what does this mean for the future of Cisco, Viptela, and SD-WAN?

First, the SD-WAN space is crowded.  With more than two dozen vendors, every one that touches the WAN markets an “SD-WAN” solution.  Now that Cisco has a viable SD-WAN offering, I expect the market to thin and for definitions to become more clear.

There are a few things Cisco must do.  First, they must tightly integrate Viptela’s software into their WAN offerings.  They cannot treat Viptela as a different business unit that runs independently like they did with Meraki.  Cisco’s entire WAN portfolio must run Viptela’s SD-WAN software and it must happen fast.

Second, they must embrace the culture of customer focus that has been so attractive at Viptela.  In recent years, Cisco has adopted a posture among their technical teams in which they tell their customers what they need instead of listening to customers. For example, in a meeting with high-level Cisco engineers, we had to justify running BGP on a WAN router.  We needed to dynamically distribute routing information from our sites — not an unlikely use case.

Most importantly, Cisco must continue the innovation that Viptela began.  Although the technology a huge step forward, there is much work yet to do.  The user interface of Viptela’s management console could use some improvement.  Better visibility into traffic flows and path selection would be helpful.  Viptela needs to refine their cloud deployment models and make it easier for customers to extend their infrastructure into the cloud.

I’ve been critical of Cisco in recent months, yet I choose to remain hopeful.  I’m hopeful that the meteoric rise of SD-WAN has shaken Cisco out of their complacency.  I’m hopeful that they will fully integrate Viptela technology into their WAN routing platforms.  And I’m hopeful that customers will see not only technology benefits, increased operational efficiency, and security, but also overall cost savings, from implementing Viptela’s (now Cisco’s) SD-WAN technologies for years into the future.

A girl can dream, can’t she?

6 Troubleshooting Lessons I Learned from Economic Psychology

By 1 Comment

My latest read,  The Undoing Project: A Friendship that Changed our Minds, explores the friendship of Daniel Kahneman and Amos Tversky — two psychologists whose study of irrational human economic choices led to a Nobel Prize in Economics. While the book discusses their friendship in detail, it also highlights their work which has influenced a wide array of disciplines including medicine, professional athletics, and and military recruitment.

I was particularly struck by their work on decision making. Through several studies, Kahneman and Tversky realized that human judgement is skewed by how questions are asked, how information is presented, and by how closely a scenario aligns with their existing biases. For example, they discovered when given 5 seconds to determine the product of 1 x 2 x 3 x 4 x 5 x 6 x 7 x 8, subjects consistently made a much smaller guess than when asked to determine the product of 8 x 7 x 6 x 5 x 4 x 3 x 2 x 1, although the actual product is exactly the same.

The implications of their work stuck a chord.

For those of us who work in technology, we pride ourselves in our rationalism. We deal in the territory of binary math, algorithms, and logic. Yet we often fail to step back and see ourselves as mere mortals. We acknowledge some disciplines suffer from irrationalism, but not ours. We are thinkers! Kahneman and Tversky, who studied doctors, graduate students, and economists, document the irrationality of human decision making. Even as technologists, we’re not immune from the human condition.

***

It doesn’t take long for an IT professional to find themselves on a bridge-line with several dozen people working to recover from a production outage. People ask questions, present theories, and there are usually more questioners than problem-solvers on the call. What can we learn from the discoveries of Tversky and Kahneman in this situations? What are strategies we can follow to solve the problem and get off that bridge line faster? Here are a few of my take-aways after reading about their work.

  1. Understand the problem. Skip this step at your peril. Ask: What is the problem? When did it start? What systems are affected? Has a trustworthy IT professional verified the problem? Ask questions to help determine scope: Is the problem local, regional, national, global? What systems are affected? Can the problem be replicated? Ask questions that have measurable answers.
  2. Gather real data. Don’t delve hours into an outage without doing your research. We don’t always have perfect metrics but there are several places we can look to help us determine what’s wrong:
    • Log data: Gather log data, but unless the error messages explicitly point to the issue at hand consider these a data point.
    • Testing tools: For network engineers these tools may be as simple as ping and trace route. Record your results.
    • Monitoring systems: Netflow data, snmp data, and alerting systems can be extremely helpful in deconstructing the issue.
    • Metrics and CLI output: Take a look at interface counters, show commands, and other device level data.
  3. Know your normal. Often, troubleshooting can be derailed for hours chasing log messages or incidents that are completely normal. For example, know how many sites typically experience an outage in a normal day. Review historical data to see if network utilization is particularly high, low, or normal.  Understand your environment well enough to know when something is normal and when it’s out of place.  In Kahneman and Tversky’s vernacular, this relates to the base-rate.
  4. Trust but verify. (The Dr. House corollary would be “Everybody lies.”) If someone on the bridge line suggests a course of action, ask questions — especially if they’re very confident. Why do you think that? What led you to that conclusion? Does the data we’re gathering support your theory? How can we test your theory? Don’t tweak configurations based on guesses that aren’t supported by data. You may introduce more problems that will muddy the data you’re collecting.
  5. Use existing models to conceptualize the problem. OSI is particularly helpful here. For example, if traceroute consistently works from end-to-end, you can be fairly confident layer 3 connectivity is solid and the problem is higher up in the stack. You can direct application support to investigate the application and you can check appliances like WAN-OP, Proxy, or SSL-Decryption that primarily work at the application layer.
  6. Avoid blame and emotionalism. I was on a call recently where the first words I heard a contributor say were, “We haven’t changed anything in months so it can’t possibly be <our problem>!” It’s fair and reasonable to mention that you have not made any changes as a data point for discovery. But it’s not helpful to deflect questions to avoid blame. The problem is what the problem is. Deflecting blame only slows troubleshooting. Eventually, the team will determine the problem and restore service (unless the issue spontaneously resolves leaving everyone scratching their heads). If the problem is not in your area of responsibility, the facts will prove it. If the problem is within your area of responsibility, you will only delay efforts to restore service by deflecting and covering your tracks. You cannot will the problem to be outside of your area of responsibility. Don’t hide information. Don’t try to shape the narrative. You’ll increase resolution time, make the call drag on, and gather a few enemies in the process.

A few additional thoughts:

  • Ask what changed, but don’t stay there too long. Outages are often caused by a change in state. But typically, if a change in state is known, the change will be reversed and operations will return to normal quickly. I’ve seen troubleshooting devolve into a drawn-out who-done-it before the problem is solved. If you use rational and systematic troubleshooting techniques you will find the problem. Don’t get marred in trying to solve the wrong problem.
  • Be wary of your initial judgement. Just because you had an outage last month that looked similar doesn’t mean this outage is the same scenario. Often, we will form an initial judgement of the situation and cling to it too long — even when data contradicts that judgement.

Tomes can be written on the troubleshooting process. For me, The Undoing Project was a reminder that human reasoning has its limits and that we need tools and processes to keep our brains on track.

9 Easy Ways to Break a Cisco Network

By 4 Comments

We’ve all been there. You make a simple configuration change that should have no impact on production traffic. Suddenly your phone begins to ring, or worse, you lose access to the equipment you were working on.

Here are some common mistakes network engineers make on Cisco gear that cause unexpected outages.

  1. Forget the add command when adding a vlan to a trunk port.
  2. Run no ip access list on a Cisco Router like you would on an ASA firewall.
  3. Issue a global spanning tree command instead of an interface specific command.
  4. Apply an untested ACL on the interface you use to manage the router.
  5. Click OK on an ASDM dialogue box without reading and understanding the impact.
  6. Delete the current flash image from disk without changing the boot command.
  7. Issue the debug all command.
  8. Typo the subnet on a static route when you’re redistributing static.
  9. Forget to cancel the reload in command.

If you’ve worked on Cisco networks for any length of time, you’ve probably made one of these mistakes or been in the proximity of another engineer who has made one of them.

If you can relate to these simple outage-inducing errors, join Jordan Martin, Phil Gervasi, and me as we launch a new live-stream video roundtable called the Network Collective. In our first episode, we’ll hear about some stomach-churning outages caused by each of our guests and lessons learned from those experiences. The live stream begins on April 11th at 7 pm ET. Watch live and comment on Twitter with the hashtag #NetworkCollective. If you can’t watch live, shows will be available in video and audio format.

For more information about the Network Collective visit the web site and follow NetCollectivePC on Twitter.

5 Key Strategies to Thrive when Working from Home

By 2 Comments

A couple years ago, my employer piloted a “Work from Anywhere” program. With a new baby and a 75 minute commute, I was a perfect candidate. Now, two years in, I can’t imagine making the daily trek to the office. My productivity has soared and I have a much better work/life balance.

But, working from home is a serious adjustment. It took me six months to develop a solid rhythm. During that time, I learned these key strategies to make working from home more productive than working in the office.

  1. Eyvonne's Home Office

    Eyvonne’s Home Office

    Create a dedicated work space — When I first started working from home, I portioned off a part of my bedroom as a work area. I had everything I needed and thought it was working well. A few months ago, however, we rearranged some rooms, bought a new desk, and I designed a dedicated work space. I hung some pictures I’d taken and painted the room a warm color. Now, when I “go to work” in the morning, I enter a comfortable space dedicated for work. When I’m done for the day, I leave that space. The physical separation provides a level of mental separation I didn’t have before.

  2. Follow a morning routine — Over time, I’ve learned my work day goes better if I start it right. For me, that means getting ready for work like I do when I go to the office. I wake up in time to shower, put on makeup, and prepare for the day like a normal human being. Although the wardrobe consists of a flannel shirt and yoga pants (let’s not go crazy here), I still start my day as if I were going to the office.

  3. Communicate well with coworkers — I’m fortunate to work on a team in which several members work remotely. This supports a culture where team meetings have a virtual as well as a physical, presence. Make use of all the tools at your disposal: email, instant message, team tools (slack, spark, etc), video conference, and even the telephone. In a large organization, you’ll likely find pockets of people who do not embrace a work from anywhere culture. Check meeting invites in advance for an online meeting room or teleconference bridge. If there isn’t one, offer to set one up. Be proactive, but not pushy, to be sure you’re included in conversations and make a contribution where your input in valuable. Over time, others in your organization will learn to account for contributors who work remotely.

  4. Develop household boundaries — I have 4 children ranging in age from 17 – 2. Just as if I were at the office, my children who require childcare are cared for by someone else during work hours. My school-age children arrive home before my work day is done but we’ve developed some systems so they know when they can come in the room and when they need to be quiet.

  5. Get familiar with your mute button — Household noises like the doorbell or a barking dog can be a distraction in meetings. When you’re not talking, develop the habit of using your mute button. However, be mindful that your mute button can fail you. While you should always be kind to the people with whom you live, understand that discipline or harsh words to your family while you’re on a call could have professional consequences as well as personal.

Working remotely, while not for everyone, has improved my productivity and my home life. I can’t imagine going back to my extended commute and the inflexibility of working at the office every day.

What about you? Have you ever worked remotely? Are there other strategies that have worked for you? Next week I’ll share a specific trick I use with my elementary-aged daughter to reduce conference call interruptions.