ESHARP.NET

Technology and life with Eyvonne Sharp

Can Cisco Restore Confidence with SD-Access?

By Leave a Comment

At Cisco Live 2017, the world’s leading networking vendor shone a spotlight on their new line of campus switches and their emerging software platform coined SD-Access. Some of the buzz was familiar like a new programmable ASIC with more power to process packets. We heard the expected refrain of speeds and feeds, port density, redundancy, and PoE. But we heard new things as well.

After years of industry buzz surrounding Software Defined Networking, Cisco announced their first serious foray into the software-defined space. Software-defined Access combines a suite of Cisco software products to improve usability, build automation, and aid in troubleshooting. Combining ISE and two new software tools, DNA Center and Network Data Platform, Cisco promises a fully automated, secure campus fabric.  On it’s face, it’s difficult to not get excited about SD-Access. Many of us have been begging for more robust, software-driven solutions from Cisco. In many ways, SD-Access is the first coherent unified strategy in that direction.

But…

Those of us who’ve been around networking for any length of time have history. We remember the Cisco Live where OnePK was all the rage. Sessions were packed to the gills with eager networkers learning a new API that was going to be integrated into every Cisco platform. OnePK didn’t survive a year. We remember hyped, but incomplete, products that never delivered on their promises. Beyond the failed promises, we’ve given countless sleep-hours to unexpected production outages caused by software bugs. Many of us can’t remember the last TAC case we opened whose root cause wasn’t a software bug.

At the same time, we freely acknowledge that we’ve built our careers around Cisco solutions and products. We want to believe that Cisco is entering a new era, that the leadership of Chuck Robbins is bringing about transformation inside of an organization that’s grown bloated with success.

With all that in mind, what can Cisco do to restore our confidence in the next era of software-defined solutions?

  1. Ship working products. More than anything, we must be able to trust that the products we buy will work as promised.
  2. Stay focused on delivering real solutions to real problems. Stop creating solutions that look for a problem. We have plenty of problems to solve.
  3. Integrate. Cisco’s integration of newly acquired Viptela will speak volumes.
  4. Unify the organization. Customers have grown weary of inter-BU competition and inconsistent product messaging. We expect all of Cisco to be on one team.

Even with my cautious optimism following Cisco Live, it will take a few years of successful product deployments to renew my confidence. As a follower of SD-WAN in general, and a fan of Viptela in particular, I cannot overstate the importance of the successful integration of Viptela’s full SD-WAN platform.

By next Cisco Live we should know if SD-Access is just another marketing campaign or if it’s becoming a new way of life for Cisco. We will know if SD-Access works. We will see how Cisco rolls Viptela into the fold and if they make the difficult decisions required to do so.

Until then, many of us will continue to watch and wait.

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?

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.

Cisco Meraki Adds Beta BGP Support to MX Appliances

By Leave a Comment

Cisco Meraki LogoCisco Meraki has introduced beta BGP support in their Meraki MX appliances. According to product documentation, the latest version of Meraki code now supports BGP (IBGP and EBGP) — the caveat, you’ll need to contact your Meraki Sales Rep or Support to enable the features.

If you’re interested in implementing BGP in your existing Meraki environment, you’ll want to read the documentation carefully. It appears that you must run IBGP in the Meraki Site-to-Site VPN in order to redistribute routes via EBGP.

It’s unclear if you can limit redistribution with route filters or influence upstream routes with BGP communities.

BGP support will allow you to eliminate the need for static routes  into a Meraki environment. BGP will also help improve data center redundancy and failover. However, many of the features we’ve come to love (or hate) with BGP appear to be absent.

Check out the product documentation for yourself:
https://documentation.meraki.com/MX-Z/Networks_and_Routing/BGP