The conversation around these questions help me to figure out which SD-WAN solution is best, which hardware to go with, what sort of licensing to use, what the topology should look like, and even what the actual policies should be.

This is by no means an exhaustive list but more a conversation starter. If you have any initial planning questions or considerations you think should be on this list, please let me know in the comments, on Twitter, or on LinkedIn.

In my very earliest planning discussions with my customers, I like to ask these 10 questions:

1) What real-time applications are in use?
2) What are the latency thresholds for mission critical apps?
3) Is there a need for multicast?
4) Are there analog connections like PRIs, voice gateways
using analog circuits for failover, etc
5) How will SIP trunk terminations work in the the SD-WAN?
6) What is the org’s cloud footprint and future initiative?
7) What SaaS applications are in use?
8) What are the organization’s security requirements both as
as a whole and specifically for branch security?
9) What are the current providers in place and what is
available at each of the branches?
10) How will the new SD-WAN work with the
organization’s Disaster Recovery and Business Continuity
plans?

Thanks,

Phil

But to be honest, I haven’t seen that happen very much. Even the very largest networks I’ve worked on and customers I’ve worked with haven’t adopted a very multi-vendor infrastructure.

There are always exceptions, of course, but by and large I’ve seen organizations stay pretty consistent with deploying and operating devices from a single or at least only a very small number of network vendors.

Very recently, though, as in only the last year or two, I’ve seen things start to change. I’ve seen a willingness and sometimes eagerness to look at new vendors, but it’s been within a specific context.

It seems SD-WAN has given organizations small and large an opportunity to expand their horizons and implement solutions from more than one vendor. Instead of insisting on only one brand for the entire network – the campus, data center, WAN, and even security – IT managers seem very willing to entertain peeling off the WAN and going with a completely new vendor.

For example, a WAN router refresh might include most if not all of a company’s routers especially if they’re co-termed for support or if they all go end-of-life around the same time. It’s a chance for IT managers to rethink how to manage a WAN and see what’s out there.

Instead of simply upgrading the old box with a new box – a like-for-like rip and replace – I’m seeing organizations take the opportunity to explore new options. A wide area network refresh is the perfect opportunity for a new networking vendor to slide right in.

A campus refresh might seem easier since for the most part a campus is mostly access switches. However, think about it in terms of budget. A network of several thousand access switches to go from vendor A to vendor B in one big refresh would be obscenely expensive and take years to implement. And I just don’t work with many IT directors and network admins that are OK with a mixed vendor access layer.

A WAN edge is far fewer devices overall, and since it’s a different logical part of the network, I’ve seen network admins much more amenable to a different vendor for the WAN than they use for their campus and data center.

Today, I have Cisco-only customers considering Velocloud for their WAN while keeping Cisco as the primary vendor everywhere else. I also have anything-but-Cisco customers interested in deploying Cisco ISRs with SD-WAN code because of the built-in branch security and granular control available in vManage.

And this openness to a new vendor is compounded by the fact that many organizations now service chain their new SD-WAN solution with yet another vendor’s cloud-delivered network security solution.

No, this isn’t the same as pure multi-vendor in which the brand is completely irrelevant anywhere in the network, but it’s certainly a step away from full-stack single-vendor networking enterprise IT has been enamored with for years.

It’s been interesting to see the adoption of SD-WAN open the door for new networking vendors to get a foothold in what were always single-vendor environments. It’s not necessarily that whitebox and disaggregation panacea that the industry has been touting for a while, but in my experience it’s certainly a very real shift to a <somewhat> more multi-vendor environment.

Thanks,

Phil

How will a business recover from a data center outage?

How can mission critical applications move seamlessly between data centers?

How will our end-users reach an application in the event of a failover?

These are just a few high level questions that, along with very technical and legal requirements, will guide the actual design of a data center failover plan. The answers will determine bandwidth, routing protocols, storage, virtual environments, security, hardware platforms, and every minutia of design right down to how DNS will be propagated and what OSPF metrics are set to.

This is an expensive process both in time and resources. Depending on the business requirements, complexity can become unwieldy, and IT often incurs great technical debt.

The data center interconnection, or DCI, is the backbone for data center failover activity. Great pains are taken to research this one piece of the disaster recovery workflow. The problems are that high bandwidth links are expensive, and the actual design of how to use this connection (or multiple connections) to maintain a standby backup data center is very complex. Even more complex is maintaining a load-balanced active/active data center environment.

Typically, a DCI utilizes dark fiber or expensive leased lines from an ISP to extend the private network of one data center to the other. From a technical perspective, DC failover usually requires additional firewalls, heavy duty routers, load balancers, switches, and all sorts of complex configuration.

Now imagine the wasted resources in an active/standby data center design. In spite of the inefficiency of this design, sometimes it’s just too cost prohibitive or operationally complex to build and run active/active data canters.

There must be an easier way…

An SD-WAN is typically looked at only as a WAN technology, sometimes considered a replacement for a company’s core and branch routers, but SD-WAN technology can be used anywhere devices need to communicate with one another. Another use case to consider is SD-WAN between data centers.

128 Technology solves the DCI problem not by selling a warehouse full of routers, switches, and firewalls in a complex web of configuration, but by leveraging secure vector routing and a management overlay called the 128T Conductor.

Secure vector routing, or SVR, is 128T’s method to associate individual packets with a traffic session using NAT rather than tunnels for traffic forwarding. This may seem more reminiscent of a stateful firewall, but 128T uses sessions for routing in particular, something very different from other SD-WAN vendors. Session-based routing itself isn’t brand new, but what what 128T does with it can be very compelling to a network architect trying to solve the DCI problem.

For example, when a 128T router at one data center forwards server traffic to another 128T router (called a peer) in the secondary data center, the first router immediately recognizes the traffic based on traditional 5-tuple information such as source and destination IP, port, and so on. The first packet of the transmission is then assigned a session ID which is mapped to some pre-defined policy determining SLAs, payload encryption, a NAT policy, and the appropriate path vector, or physical path, for the traffic.

The use of secure vector routing and NAT within the 128T router mesh means a significant amount of resources are saved by not using a tunneling mechanism to forward traffic. This, along with session-based path vectoring means a tremendous amount of bandwidth can be spared on DCI links and far fewer devices need to be deployed for high performing, secure connectivity.

Also, because 128T’s routers by default deny traffic not associated with a session, a 128T router also acts as a basic firewall. Since SVR utilizes NAT instead of tunnels, there is no need for an additional NAT device whether that be another router or a dedicated firewall. In other words, a 128T network eliminates many common middleboxes we’ve come to expect in complex network designs.

Though SD-WAN solutions work well for aggregating multiple links to connect branches to each other and a to central hub, it’s often at the cost of reducing bandwidth on the links due to tunneling overhead. Also, many SD-WAN platforms don’t provide much in the way of security which means separate firewalls must still be deployed.

This is what makes 128 Technology unique in the SD-WAN space and a good option to consider specifically for DCI connectivity. The 128T ecosystem of routers and centralized management can provide much less complex, high quality connectivity between data centers in a secure fashion without sacrificing a lot of bandwidth on the links themselves.

Typically, a DCI is made from a couple or a few redundant links to exchange state information, exchange routing tables, replicate virtual servers, and move actual data traffic. Using a solution like 128 Technology means specific workloads don’t have to be pinned to specific links. Using intelligent session-based routing with devices that share state tables in a full mesh means links can be aggregated and intelligent forwarding decisions can be made as we’ve come to expect from an SD-WAN – but without the overhead.

Ultimately, this makes data center failover designs less complex and potentially less expensive as it eliminates an array of middleboxes, complex configuration and overlays, and all the associated costs with planning, procuring, building, and operating a complex data center failover design. Especially in active/active designs that load-balance production applications, the 128T routing paradigm is a compelling design option.

128T certainly can’t eliminate all the complexity in designing around DCI, but it can make it much simpler.

Thanks,

Phil

128 Technology presented at a recent Tech Field Day Exclusive in Burlington, Massachusetts, where they went right into the weeds on how their technology works, what differentiates them from other SD-WAN vendors, and how some of their partners are leveraging their intelligent routing platform to solve very real business problems. 

Watch the videos here, and always feel free to contact me with questions, comments, or corrections.

• 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