Category: SDN

Five years after the SDN hype exploded, it remains as meaningless as Cloud, and it seems that all we’re left with is a plethora of vendors engaged in SDN-washing their products.

Even when a group of highly intelligent engineers considering these topics on a daily basis gets together they don’t get very far apart from a great question: “what business problem is it supposed to solve?” (or maybe they got distracted by irrelevant hot-air opinions).

Is it still worth trying to find a useful definition of SDN? It seems it’s easier to list what SDN is not like I’ll be doing in the free Introduction to SDN webinar on February 10th. Let’s see:

In theory, you should shut down a network device with a well-defined procedure:

• Drain the traffic from the device;
• Verify the device is no longer forwarding traffic;
• Turn off the device.

In practice, network devices don’t have a shutdown command, and reload typically just restarts the network OS.

A while ago I watched a Networking Field Day Extra video in which Chris Young and Michael Zayats talked about HP’s open source initiative – they decided to build yet another open networking operating system.

Obviously I wanted to know more, reached out to Chris, and we quickly managed to set up an online chat resulting in Episode 48 of Software Gone Wild podcast.

John wrote an optimistic comment to my fashionable designs rant:

Nobody in their right mind does "fashionable" things when dealing with infrastructures that are required to be solid, dependable and robust.

Unfortunately many enterprises aren’t that prudent – the last Expert Express engagement I had in 2015 was yet another customer who lost two major data centers due to a bridging loop spilling over a stretched VLAN infrastructure.

Nick Buraglio used OpenDaylight and OpenFlow-enabled switches to build a part of the exhibition network of a large international supercomputing conference and was kind enough to talk about his real-life experience in Episode 47 of Software Gone Wild.

We covered:

Yesterday I described the theoretical limitations of using OpenFlow for load balancing purposes. Today let’s focus on the practical part and answer another question:

@colin_dixon @ioshints and for a fair comparison: Would a $100k OF switch be able to act as proper LB?

— Kristian Larsson (@plajjan) December 3, 2015

I wrote about the same topic years ago here and here. I know it’s hard to dig through old blog posts, so I collected them in a book.

It all started with a tweet Kristian Larsson sent me after I published my flow-based forwarding blog post:

@ioshints sure but can't OpenFlow be used to implement an LB? It feels like a mix of terms here

— Kristian Larsson (@plajjan) December 3, 2015

You might be familiar with the idea of using BGP as an SDN tool that pushes forwarding entries into routing and forwarding tables of individual devices, allowing you to build hop-by-hop path across the network (more details in Packet Pushers podcast with Petr Lapukhov).

Researchers from University of Louvain, ETH Zürich and Princeton figured out how to use OSPF to get the same job done and called their approach Fibbing. For more details, listen to Episode 45 of Software Gone Wild podcast with Laurent Vanbever (one of the authors), visit the project web site, or download the source code.

I love listening to the Datanauts podcast (Ethan and Chris are fantastic hosts), starting from the very first episode (hyper-converged infrastructure) in which Chris made a very valid comment along the lines of “with the hyper-converged infrastructure it’s possible to get so many things done without knowing too much about any individual thing…” and I immediately thought “… and what happens when it fails?”

Imagine you’d design your network by documenting the desired traffic flow across the network under all failure conditions, and only then do a low-level design, create configurations, and deploy the network… while being able to use the desired traffic flows as a testing tool to verify that the network still behaves as expected, both in a test lab as well as in the live network.

You might remember all the fuss about various encapsulations used in overlay virtual networking… just because one wouldn’t be good enough (according to Andrew Lerner “we provide users with choice” actually means “we can’t decide which product to offer you”).

A newbie exploring the mythical lands of SDN might decide to start at the ONF definition of SDN, which currently (November 2015) starts with a battle cry:

The physical separation of the network control plane from the forwarding plane, and where a control plane controls several devices.

The rest of that same page is what I’d call the marketing definition of SDN: directly programmable, agile, centrally managed, programmatically configured, open standards based and vendor-neutral.

Time for another fill-in-the-blanks survey: how many vendors support NETCONF and/or REST API in their data center switches, routers, firewalls and load balancers?

Please help me complete the tables by writing a comment – and do keep in mind that it only counts if it’s documented in a public configuration guide on vendor’s web site.

Also, I’m not aware of any vendor using standard NETMOD YANG models. If someone does, please let me know.

One of my regular subscribers wondered whether it makes sense to attend a live workshop instead of listening to my webinars:

I am following your blog posts quite regularly, I’ve been a yearly subscriber for more than 3 years now and I’m even trying to attend as many webinars as I can in real time. Is there a real benefit to participate in this classroom event if we are almost aware of all your slide decks and videos?

Absolutely. Here’s what one of the attendees of a recent SDN workshop wrote when asking me whether I would be willing to do an on-site event for his company:

Whenever a vendor approaches me touting the benefits of their new gizmo, they want to give me a product demo, or offer me access to online labs… and I always tell them I’m not interested until I see their design and configuration guides.

Here’s why I think you should take the same approach: