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

TELoIP is a little different from most other SD-WAN vendors in that it offers a managed WAN solution and has its own cloud infrastructure into which customers connect. This isn’t a common approach among SD-WAN vendors, but it also isn’t exclusive to TELoIP. That’s why I’m really interested in knowing how they differ specifically from vendors using a similar approach but also how they’re better than the broader scope of SD-WAN providers.

I’m not going to explain what SD-WAN is other that to say that it’s basically an overlay on top of your WAN to allow for intelligent path selection based on link quality and other traffic engineering such as per packet flow aggregation. This is powerful technology that’s been running in production environments for several years at least at this point.

That means that my questions aren’t really about how SD-WAN works or what their secret sauce does to make the magic happen. Instead, I want to know how TELoIP treats SD-WAN as a separate function from WAN optimization and how that plays into security concerns.

It also means that I want to learn about their service delivery and how TELoIP works with providers of their solution to deliver the last mile between the TELoIP PoPs and the customer edge.

The SD-WAN component isn’t groundbreaking anymore. To me, the technology lost it’s sheen already. That doesn’t mean I’m not interested in SD-WAN or don’t recognize the benefits of the technology, it just means that I’m more interested now in service delivery and operational aspects.

I still have some technical questions in mind, but I’m looking forward to learning how TELoIP is positioning itself and why. Check out their website and their presentation at Networking Field Day 15 by tuning into Tech Field Day’s YouTube channel. Also make sure to follow the discussion on Twitter using #NFD15.

Managing the WAN through software means that serious intelligence can be added to path selection and link aggregation more than “legacy” routers have been able to do thus far. This also allows various devices such as routers, optimization appliances, and firewalls to be rolled into one device. A huge benefit is also the incredible cost savings a company can realize when eliminating expensive private MPLS circuits by aggregating inexpensive public internet circuits.

VeloCloud, a well-known name in the SD-WAN space, will be one of the presenting companies at Networking Field Day 13.  I’ve heard of VeloCloud before, but I’ve never really dug into what they do much until recently. I’ve been looking at SD-WAN solutions for my day job and am very interested in how they do per packet and per flow load balancing across several aggregated WAN links. How do they provide a similar performance and end-user experience load balancing an application over both broadband and LTE links, for example?

The real goal here is to provide private circuit reliability, security, and performance for applications running over the public internet. VeloCloud does that using what they call “dynamic multi-path optimization” along with a proprietary form of link and path monitoring to check for bandwidth, quality, and reliability issues.

I have recent production experience with a different SD-WAN company that provides a similar solution, so I have a particular interest in what differentiates VeloCloud. I’d like to hear more specifically about their pay-as-you-go model because I know from experience that enterprises don’t normally migrate a global network in one big cutover. Starting small, maybe just a few branch offices, is how multi-site organizations are moving from a traditional WAN to an SD-WAN solution.

Reading through their website, I learned a little bit about their appliance, the VeloCloud Edge, that can be deployed very quickly at a branch office by pretty much anyone who knows how to plug in a cable. This is expected, so I’d like to hear more about their cloud network of distributed gateways. I think I understand what they’re doing, but I’m really not 100% sure based on what I’ve read online. Maybe that doesn’t really matter, but I think when looking at what’s going on in the backhaul of various SD-WAN solutions we can identify those indicators that differentiate one SD-WAN company from another.

This is really cool stuff to me, but what I really like is how SD-WAN is relevant today. I’m looking forward to meeting the folks at VeloCloud next week and hearing more about how they make the magic happen.

Amidst discussion of SDN ambiguity at Networking Field Day 11, SD-WAN stood apart as something we understood, and I think that’s because we understood its use case very well.

Most of us in the room during Silver Peak’s presentation were network engineers building high quality, fault tolerant networks, and we were familiar with the pain SD-WAN seeks to address.

As a brief overview, Software Defined WAN reduces the complexity and improves the performance of the WAN edge by adding optimization, automation and measurement-based exterior routing.  This approach offers fault tolerance for all types of failures from the link itself through the public cloud. This means that the complexity associated with current technologies such as DMVPN, IP SLA, and PfR is largely eliminated.  This also means that a type of QoS can be delivered even on public WAN links.  And this means significant cost savings by eliminating expensive private MPLS links. Several vendors are already doing this, so the technology isn’t brand new. I wasn’t necessarily skeptical walking into Silver Peak’s offices, but I wasn’t expecting anything groundbreaking.

Their presentation was very compelling, though, and I was impressed with David Hughes’ ability to jump in, as Founder and CEO, and dig into the technology. He explained that the impetus to move to SD-WAN is the shift to cloud applications, and that their product delivers applications with high quality over whatever connectivity the user chooses. He also explained that their solution meets a specific use case: “to connect users to applications much more easily, efficiently and cost-effectively.” In David’s words, Silver Peak’s technology is more about “providing an overlay over whatever underlying technology you want to use for your connectivity…and making that overlay really easy to manage and deploy.” Flexibility and ease of use seem to be key to Silver Peak, which is, of course, a good thing.

Damon Enniss, Senior VP of Products, presented their Unity EdgeConnect  solution to easily harden the WAN edge and deliver path conditioning, latency mitigation and increased reliability. I’ve struggled with providing this level of cost-effective optimization and fault tolerance to the WAN edge. Especially in the small to medium sized business space, organizations can’t always afford the hardware or skillset to implement the design they need. Though their requirement for uptime and a quality connection is no less important, the cost can be prohibitive.

Silver Peak did a great job, but then again I’m already excited about this technology.  Zero-touch provisioning for highly resilient WAN edge devices? Sign me up! It makes sense, especially in the SMB space, because there’s an actual business use case for this.

The most compelling value proposition to me is that using this technology means I can get rid of all my private connections. I want to ditch my expensive private MPLS link and have a pair (or three) of public internet connections. My MPLS links can cost thousands of dollars per month each. Silver Peak says they can deliver performance, quality and resiliency and cut costs up to 90%, so the real value proposition is going with all public connections. Damon mentioned that only in passing, but I think it’s the most compelling reason to go SD-WAN with Silver Peak.

Over the last few years I’ve noticed ISPs improving their service delivery, and even though I still tease about Time Warner Cable going out when it rains, business internet connectivity has increased in quality and bandwidth and decreased in cost. There are parts of the country and world where internet connectivity is still very poor, but in the northeast where I live, I can run voice over the internet today when I wouldn’t dare 5 years ago.

I want to drop the hybrid solution and go SD-WAN with all public internet links. Cheaper, easier to deploy, and easier to switch ISPs if I want. To me that’s the real value of SD-WAN. Silver Peak didn’t make that specific case very strongly, and I think they should have. An organization may require a hybrid model for some particular reason, and I understand that. But by and large, Silver Peak’s technology can provide to even the smallest customer private line performance and reliability cheaper with public internet connections only. Win.

[Follow up edit: I believe my opinion that Silver Peak didn’t focus enough on an enterprise going all public internet links was based on a misguided  first impression. Over the last five weeks I’ve looked into Silver Peak’s public literature and kept an eye on their tweets. They are absolutely positioning Unity EdgeConnect to replace private MPLS links much more than I thought.]   

Disclaimer

I attended a Silver Peak presentation as an invited delegate to Network Field Day 11. The sponsors pay to present to the NFD delegates, and in turn that money funds my transport and accommodation while I am there. That said, I don’t get paid anything to be there, and I’m under no obligation to write anything, positive or negative, about any of the presenters.