• Over the next two years, 90% of enterprises will be making a decision about SD-WAN.
• SD-WAN has become a conversation about on-ramping into the cloud.
• SD-WAN can provide security advantages because of how it can provide WAN segmentation.
• The WAN is the business critical connecting fabric of our networks.

SD-WAN has been around for some time, and I believe its value to networking has been well-established. However, Cisco hasn’t been a big part of the SD-WAN story until recently.

Cisco IWAN was interesting, but some would argue that it isn’t SD-WAN. Cisco’s acquisition of Viptela implies they knew this, and in 2017 they purchased what many consider to be the leading SD-WAN vendor at that time. This means Cisco now has the opportunity to lead the SD-WAN market which is already past early adoption and well underway to mass adoption.

Cisco defines this path to mass adoption in terms of cloud adoption.

Cloud adoption requires easy branch connectivity, demands new security requirements, and requires LAN-like connectivity over the public internet. At Networking Field Day 19, this theme was clear theme to me. Yes, David Klebanov explained the nuts and bolts, and Kureli Sankar focused on SD-WAN security, but the overall theme was how to on-ramp to and manage a multi-cloud topology.

Multicloud refers to the use of multiple cloud service providers, but it’s important to remember that most organizations still maintain local resources in their own data centers, too. Therefore, multicloud also refers to local private clouds working seamlessly with their public cloud counterparts such as AWS, Azure, Office 365, etc.

Several of the problems with a multicloud environment are:

1. Ensuring a high quality user experience
2. Migrating branches to cloud connectivity
3. Dealing with new security risks

User Experience

There are several dozen SD-WAN vendors out there using similar technologies to provide resilient and high quality WAN connectivity. SD-WAN is proven technology, in my opinion.The technology makes use of path probes, cloud gateways, proprietary control-plane protocols, etc in order to provide a high quality experience for end-users even over an aggregate of public internet links.

Migration

But practically speaking, how do organizations migrate an entire infrastructure to a software-defined WAN? Doing a one-for-one replacement of branch routers might be possible in a small organization, but it would take months or years for larger organizations to upgrade their entire WAN that way.

Cisco has two methods for deploying an SD-WAN. The first is to deploy one of the Viptela vEdge appliances in each branch and manage the entire infrastructure with vManage. This might work in some scenarios, but it doesn’t solve the problem large organizations have migrating to an SD-WAN quickly and easily.

The second option is to upgrade the code on existing branch Cisco ISR routers to the latest version of IOS-XE SDWAN software enabling SD-WAN features on an ISR already in the rack. The IOS-XE SDWAN code converts the router to an SD-WAN appliance managed by vManage, and though this still requires significant planning and time to deploy across a large organization, it’s a faster and much more viable option for companies who already run ISRs.

As of November 2018, about 75% of the Viptela code was embedded in the IOS-XE SDWAN image with plans to bring that to 100% feature parity in the coming months. We lose a few features that become irrelevant, such as various IP VPN services, but if you’re running an SD-WAN, technologies like DMVPN are completely unnecessary anyway.

Migrating to the IOS-XE SDWAN code is a matter of uploading the image to the router and booting the device to the new code. This something most network admins are already familiar with, so the workflow to migrate should be easy. The actual code is supported a pretty wide variety of modern ISR models including the CSR virtual router.

After upgrading the code, the new control plane stack comes online which speaks OMP to the various controllers and NETCONF to the vManage system. There is no interoperability problem on the WAN side; the only real interoperability needs to happen southbound with other existing devices behind the upgraded router.

There’s also a configuration migration tool which requires only that you paste a router’s current config into vManage. vManage flags incompatible lines of config for removal, then during upgrade, the tool/vManage reaches out to router via API calls to pull in configuration and create the corresponding vManage templates.

I want to mention that though the migration is simple for experienced network teams, they would still have to learn a new platform, the vManage network management system. That part is unavoidable, but at least some of the migration pain can be mitigated.

Mitigating Security Risks

Moving to an SD-WAN for mutlicloud environments exposes security risks.

Traditionally, branch traffic destined for the public internet would be backhauled to a data center where firewalls, URL filtering and IPS devices would inspect traffic. In an SD-WAN, traffic destined for AWS, Azure, GPC, etc, is sent directly to the cloud service provider from the branch. This means security needs to happen at the branch level.

Cisco solved this problem by integrating components of Firepower Threat Defense, or FTD, to each SD-WAN appliance. Existing inside a container in the IOS-XE SDWAN code are many of the FirePOWER features we use today with FTD appliances and service modules on ASA firewalls.

The device is application aware, recognizing over 1400 applications, and is built on Snort with the ability to filter about 80 URL categories. This means at the branch level we can have WAN segmentation of applications – something difficult to do even at the main office/data center level.

Is Cisco The Future of SD-WAN?

I’m pretty sure SD-WAN is going to be the standard for many enterprise WANs. I don’t mean that all other technologies will be going away, but for the traditional multi-site organization, the reasons to migrate to an SD-WAN are very compelling.

The question is, will Cisco, who has until now been dominant in most areas of networking, be the dominant player in the SD-WAN space?

Certainly the acquisition of Viptela secured Cisco a spot as contender. Though they are still selling the old Viptela appliances, the decision to create a new IOS-XE SDWAN code that can be used on existing Cisco routers completely secures Cisco as a leader in this space. There are at least a million ISRs out there managed by organizations that already know Cisco: they have a supply chain, they know the support methods, they know their local account managers and their children’s names.

The process to lab a few ISRs a company already owns and then deploy en masse to branches is much easier than purchasing dozens or hundreds of new physical appliances. This makes on-boarding to a multicloud environment much easier, faster, and potentially cheaper depending on licensing costs.

The goal for many organizations in 2019, including small organizations, is how to utilize cloud services in a hurry. SD-WAN will inevitably be part of those conversations, and Cisco, through the Viptela acquisition and especially because of the IOS-XE SDWAN software on ISR routers, will likely be at the forefront of many of those conversations.

Thanks,

Phil

However, will this brave attempt prove to have the same fate as the 5760?

According to Cisco,

Converged access represents an architectural change in the way wired and wireless networks are deployed. A converged access network allows policy decisions to be enforced at the network edge, potentially minimizes unnecessary traffic backhaul, and simplifies network management by allowing one policy to be used for both wired and wireless traffic. (source)

What this means is a unification, to some extent, of the wireless and wired networks in terms of deployment, management, and policy enforcement. This is much more than simply layering Cisco Prime over the top as a management tool. Cisco’s idea of converged access is to truly unify the wired and wireless environments in terms of how we control both the appliance and wireless endpoints.

Today, the Catalyst 3850 switch is a very common access or distribution layer switch, but it can also act as a small branch wireless LAN controller supporting 50 access points. This eliminates backhaul of wireless traffic to a centralized controller at some main office or data center, and embeds the WLC functionality into the code of the Catalyst switch.

For larger environments, this means racking a couple hardware WLCs. Models like the 5508, 8510, 5520, and 8540 aren’t exactly integrated into the wired network, but they have IP addresses, VLANs, and push policy – and isn’t that enough?

I build wireless networks with controllers running AireOS all the time, and they work just fine. So after the mess with the 5760, what’s the point of trying converged access again?

I think the answer is twofold: programmability and what Cisco calls “deploy anywhere.”

PROGRAMMABILITY

I don’t believe Prime was successful in unifying the management of the wired and wireless networks, and Prime has nothing to do with features. And since AireOS has to be managed box by box, I don’t believe it’s very integrated with the wired network in terms of management and policy enforcement. I love AireOS, but it’s not highly programmable in the context of overall network operations. It requires manually configuring WLCs, usually at a GUI, one device at a time.

IOS-XE WLCs are run IOS-XE code which is built from the ground up to be highly programmable. The familiar IOS-XE already provides all sorts of modern network programmability tools for network management. This means the tools we already use to manage the wired network can also be used to manage the wireless environment.

Exactly like IOS-XE, IOS-XE WLC contains NETCONF and YANG models allowing it to be managed off-box by Ansible or Puppet. In fact, you can also drop into a guestshell for on-box bash or python.

At Networking Field Day 19, Ankur Bhasin, a software development manager with Cisco, mentioned that every single CLI configuration has a corresponding NETCONF and YANG model. This means, for example, that the IOX-XE WLC can be incorporated right into the inventory file an Ansible playbook might use for wireless network management.

Below notice that built right into the IOS-XE WLC user interface is a python sandbox:

This is the screen you’d see when opening up the sandbox:

Clearly, an IOS-XE based WLC offers tremendously more opportunity for programmability, off-box management, and ultimately a greater integration into an existing wired infrastructure.

DEPLOY ANYWHERE

The 9800-40 and 9800-80 are the hardware appliance platforms that can be deployed in a rack like any other box. The 9800-CL (cloud) is a virtual appliance that you can spin up in ESXi or in AWS.

Having a truly fully functional virtual WLC is a big step forward. I’m sure there are good technical reasons the AireOS vWLC isn’t quite the same as the hardware appliance. I rarely saw a vWLC in production, and I personally never deployed one outside a lab.

The 9800-CL, however, has complete feature parity with the hardware appliance. This is a big deal and makes it an excellent option for so many organizations that need enterprise wireless but are also trying to reduce their hardware footprint.

This is also an avenue for deploying a WLC in the cloud to be used by many branch offices or by any organization making use of a hybrid-cloud topology. Cisco calls it “deploy anywhere”, or in other words, customers have the choice to deploy a hardware appliance, a virtual appliance, or a cloud appliance, all with complete feature parity.

There are several IOS-XE WLC platforms to consider: the Catalyst 9300 switch, the 9800-40, the 9800-80, and the 9800-CL. I bring this up because it’s important to note that the Catalyst 9300, already a familiar switch model, is similar to the 3850 in that it’s a switch that also has a built-in wireless controller to support a small number of access points.

This may be beneficial to branch offices that need local RF management without the backhaul to a data center, but the 9300 requires SDA and DNA Center to run. This may be a hard sell for many customers since it means needing to deploy another overlay of management and infrastructure.

The 9800-40 and 9800-80 are traditional hardware appliances, and the 9800-CL is the completely equivalent virtual appliance able to deployed in ESXi or in the cloud. By IOS-XE version 16.12, there is complete feature parity between AireOS and IOS-XE based WLC.

This is pretty big. A stumbling block with converged access a few years ago was that IOS-XE based WLCs didn’t provide equivalent features, either in RF management or in WLAN management, as AireOS. One example is that I wasn’t able to perform per client throttling on the 5760 – a feature already well-established in AireOS code.

And deploying a 9800-CL virtual appliance doesn’t have to be in FlexConnect mode like deploying an AireOS vWLC has to be today. The fact that I can now run a full-featured vWLC, whether in ESXi or in AWS, is going to be music to many of my customers’ ears.

At NFD19, Ankur explained this move toward converged access is in line with Cisco’s philosophy of a network fabric, including both the wired and wireless networks. What this means for people like me, talking to customers and installing wireless networks, is that with the IOS-XE based wireless controllers, I now have a highly programmable, feature-rich WLC option I can manage as part of my wired infrastructure and deploy any way I want without penalty.

Based on the presentations at NFD19 and my own exploration of the 9800-CL virtual WLC, I don’t think this is at all a repeat of the 5760. I’m not talking about it with customers yet, but especially because AireOS will eventually be going away, this is something to build out in a lab right now.

Thanks,

Phil

Make sure to watch the NFD19 video in its entirety to learn about specific advancements such as the decoupling of access point and wireless controller code, analytics, and security features.

For my very last class, I chose not to cover anything in the textbook or any of the bullets on the syllabus. Instead, I introduced my students to systems and network automation. What may seem old news to you and me was brand-new to my class, and I don’t believe this is the exception.

There is a huge  gap between what’s happening in classrooms and in real-world IT, and colleges aren’t preparing students effectively.

I believe the history of technology is important to learn, and I believe understanding foundational concepts is also critical. However, these elements need to be taught within the context of what’s happening in information technology right now. This way, even obscure computer science principles become relevant to the actual work a student can expect to perform in their career.

I know there are exceptions, of course. Students that plan to build careers in pure research should stay focused more on deep concepts and less on how to create a new VM in ESXi. But the majority of young people graduating colleges with two and four year IT-related degrees are getting jobs as sysadmins, network engineers, developers, help desk analysts, and so on. Knowing the foundational principles is certainly important, but does it also prepare them to configure a core switch or create new storage for the applications team?

Some two and four year schools advertise degree programs in network administration, cybersecurity, etc, in what I assume is an effort to provide a more relevant education. Some advertise they utilize the Cisco Networking Academy and Microsoft Online Labs.  But after working in the trenches in some of these programs, I don’t think they are nearly as relevant as schools think they are. And frankly, I believe this is doing a disservice to tuition-paying students.

During my last class, I gave students an overview of systems automation and introduced things like Chef, Puppet, Ansible, and Powershell. We discussed the difference between on-box and off-box management. We talked about what programming languages they should learn on their own, the importance of getting familiar with navigating a Linux file system, and what changes are going on in the industry today.

None of my students knew what the “cloud” was. None knew any programming languages other than the little bit of C++ and Java they learned earlier that semester. None had any idea about virtualization, a 20 year-old technology.

There’s a big gap between what’s being taught and what employers are looking for, and I believe teachers and those who write curricula are the ones to address the issue head on. Administrators have no clue about what’s going on in our industry, and college advisers at best have only a cursory knowledge of what a hiring manager wants to see on a resume.

Colleges need to hire teachers with solid industry experience. They need to prefer adjuncts that are working in the field right now, and then pay them enough to keep them around. Curricula needs to be modified, or in many cases just thrown out. As much as possible, a course’s curriculum should reflect what’s going on in the industry. As budget allows, labs need to be built, and industry news publications need to be part of the course reading list.

This may not be applicable to many departments at a typical college, but it’s vital in IT. Our field lives and breathes change, and it doesn’t need a new generation of job candidates that have months of experience configuring VTP but little else.

For me, it’s not about explaining DNS, OSPF, or what a hypervisor is. It’s much more about helping bridge the gap between someone learning these things for the first time and making the leap to a productive member of an IT department. Sure, that means memorizing well-known ports and learning about data structures, but it also means discussing DevOps, cloud computing, containers, or whatever technology is immediately relevant.

I left my teaching position for several personal reasons, but I hope to get back there one day. I love being in the classroom, and I love working with young people starting their own career journeys.

A real joy for me was making every three hour evening class as relevant and meaningful as possible, and sometimes that meant abandoning the five-year-old textbook and reviewing a recent blog article instead.

Thanks,

Phil

It was Sunday night, so I didn’t get an overwhelming number of responses, but I did get more than a few.

Then a few more:

And then a few more:

I feel like there’s a theme here. A good network has something to do with technology, but much more to do with its proper design, operations, and documentation.

Good design meets the business’ needs without unnecessary complexity and provides resiliency.

Good operations means engineers have full visibility into the network and don’t have to spend all day firefighting because the network is stable.

And, of course, good documentation.

Are these the marks of a good network? Is there anything glaring that we missed?