More than a decade ago (before SD-WAN was even a thing) I wrote an article describing how easy it is to route different applications onto different links (MPLS/VPN versus IPsec tunnels) using a distance vector routing protocol (preferably BGP, although even RIP would work).

You might find it interesting that it’s possible to solve tough problems with good network design instead of proprietary unicorn dust, so I salvaged the article from some dusty archive, cleaned it up, polished it, and published it on ipSpace.net.

Christoph Jaggi sent me a link to an interesting article describing security vulnerabilities pentesters found in Cisco SD-WAN admin/management code.

I’m positive the bugs have been fixed in the meantime, but what riled me most was the root cause: Little Bobby Tables (aka SQL injection) dropped by. Come on, it’s 2021, SD-WAN is supposed to be about building secure replacements for MPLS/VPN networks, and they couldn’t get someone who could write SQL-injection-safe code (the top web application security risk)?

In the final video in his Cisco SD-WAN webinar, David Penaloza discusses site ID assignments and policy processing order.

A carefully planned site scheme and ordered list of policy entries will save you complications and headaches when deploying the SD-WAN solution.

In the Site Design part of Cisco SD-WAN webinar, David Penaloza described capabilities you can use when designing complex sites, like extending SD-WAN transport between SD-WAN edge nodes, or implementing high availability between them. He also explained how to track an Internet-facing interface and a service beyond its next hop.

Last week I described the challenges Azure Route Server is supposed to solve. Now let’s dive deeper into how it’s implemented and what those implementation details mean for your design.

The whole thing looks relatively simple:

After reviewing Cisco SD-WAN policies, it’s time to dig into the routing design. In this section, David Penaloza enumerated several possible topologies, types of transport, their advantages and drawbacks, considerations for tunnel count and regional presence, and what you should consider beforehand when designing the solution from the control plane’s perspective.

Imagine you decided to deploy an SD-WAN (or DMVPN) network and make an Azure region one of the sites in the new network because you already deployed some workloads in that region and would like to replace the VPN connectivity you’re using today with the new shiny expensive gadget.

Everyone told you to deploy two SD-WAN instances in the public cloud virtual network to be redundant, so this is what you deploy:

The second part of the Cisco SD-WAN webinar focused on design considerations and trade-offs in several scenarios. David Penaloza briefly reviewed the types of policies and their capabilities before discussing what to keep in mind when designing the solution.

Right after Cisco SD-WAN devices are onboarded, how are the control and data plane tasks started? In this section, David Penaloza covers how Cisco SD-WAN solution makes the most of its SDN nature: single point of policy application and centralized management platform. The types of policies, the plane on which they act, their application and the actions that can performed are the main focus in this part of the series.

After describing Cisco SD-WAN architecture and routing capabilities, David Penaloza focused on the onboarding process and tasks performed by the Cisco SD-WAN solution (encryption, tunnel establishment, and device onboarding) in it’s so-called Orchestration Plane.

After covering the Cisco SD-WAN components and its architecture in the Cisco SD-WAN Foundations and Design Aspects webinar, David Penaloza focused on the routing capabilities it offers and its control plane characteristics, including types of routes and some scalability recommendations.

On May 14th 2020, Marcel Gamma, tech industry journalist, and editor-in-chief at inside-it.ch and inside-channels.ch, published an article discussing several glaring security vulnerabilities in Silver Peak’s SD-WAN products on inside-it.ch. The original article was written in German; Marcel was kind enough to translate it into English and get permission from his publisher to have the English version published on ipSpace.net.

Security researchers make serious accusations against SD-Wan manufacturer Silver Peak. The latter disagrees. Swiss experts are analyzing the case.

By Marcel Gamma,

Silver Peak is accused of laxity in dealing with security issues and in dealing with security researchers who act within the framework of Responsible Disclosure.

After describing Cisco SD-WAN fundamentals and its network abstraction mechanisms, David Penaloza explained the components of Cisco SD-WAN solution and its architecture, including in which plane each element operates and its assigned role in the overlay network.

I don’t know what’s wrong with me, but I rarely get emails along the lines of “I deployed SD-WAN and it was the best thing we did in the last decade” (trust me, I would publish those if they’d come from a semi-trusted source).

What I usually get are sad experiences from people being exposed to vendor brainwashing or deployments that failed to meet expectations (but according to Systems Engineering Director working for an aggressive SD-WAN vendor that’s just because they didn’t do their research, and thus did everything wrong).

Here’s another story coming from Adrian Giacometti.

After setting the stage clarifying the current Cisco SD-WAN deployment scenarios, David Penaloza focused on definitions and fundamentals that must be considered before dealing with solutions that hide and abstract complexity like overlays, routing, and network virtualization from the network administrator.