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.

David Penaloza decided to demystify Cisco’s SD-WAN, provide real world experience beyond marketing hype, and clear confusing and foggy messages around what can or cannot be done with Cisco SD-WAN.

He started the first part of his Cisco SD-WAN Foundations and Design Aspects webinar with a quick look beneath the surface of shiny marketing and corporate slidess.

A reader of my blog was “blessed” with hands-on experience with SD-WAN offered by large service providers. Based on that experience he sent me his views on whether that makes sense. Enjoy ;)

We all have less-than-stellar opinions on service providers and their offerings. It is well known that those services are expensive and usually lacking quality, experience, or simply, knowledge. This applies to regular MPLS/BGP techniques as to - currently, the new challenge - SD-WAN.

In January 2020 Doug Heckaman documented his experience with VeloCloud SD-WAN. He tried to be positive, but for whatever reason this particular bit caught my interest:

Edge Gateways have a limited number of tunnels they can support […]

WTF? Wasn’t x86-based software packet forwarding supposed to bring infinite resources and nirvana? How badly written must your solution be to have a limited number of IPsec tunnels on a decent x86 CPU?

It’s amazing how quickly you get “must have feature Y or it should not be called X” comments coming from vendor engineers the moment you mention something vaguely-defined like SD-WAN.

Here are just two of the claims I got as a response to “BGP with IP-SLA is SD-WAN” trolling I started on LinkedIn based on this blog post:

Key missing features [of your solution]:

• real time circuit failover (100ms is not real-time)
• traffic steering (again, 100ms is not real-time)

Let’s get the facts straight: it seems Cisco IOS evaluates route-map statements using track objects in periodic BGP table scan process, so the failover time is on order of 30 seconds plus however long it takes IP SLA to detect the decreased link quality.

In the Three Paths of Enterprise IT part of Business Aspects of Networking webinar I covered the traditional networking vendor landscape. Let’s try to do the same for SD-WAN.

It’s clear that we have two types of SD-WAN vendors:

This is a guest blog post by Philippe Jounin, Senior Network Architect at Orange Business Services.

You could use track objects in Cisco IOS to track route reachability or metric, the status of an interface, or IP SLA compliance for a long time. Initially you could use them to implement reliable static routing (or even shut down a BGP session) or trigger EEM scripts. With a bit more work (and a few more EEM scripts) you could use object tracking to create time-dependent static routes.

Cisco IOS 15 has introduced Enhanced Object Tracking that allows first-hop router protocols like VRRP or HSRP to use tracking state to modify their behavior.

Christoph Jaggi sent me this observation during one of our SD-WAN discussions:

The centralized controller is another shortcoming of SD-WAN that hasn’t been really addressed yet. In a global WAN it can and does happen that a region might be cut off due to a cut cable or an attack. Without connection to the central SD-WAN controller the part that is cut off cannot even communicate within itself as there is no control plane…

A controller (or management/provisioning) system is obviously the central point of failure in any network, but we have to go beyond that and ask a simple question: “What happens when the controller cluster fails and/or when nodes lose connectivity to the controller?”