Category: SDN

In one of my ExpertExpress engagements the customer expressed the desire to manage their firewall with OpenFlow (using OpenDaylight) and I said, “That doesn’t make much sense”. Here’s why:

Obviously if you can't imagine your life without OpenDaylight, or if your yearly objectives include "deploying OpenDaylight-based SDN solution", you can use it as a REST-to-NETCONF translator assuming your firewall supports NETCONF.

This blog post was written in 2014 (and sat half-forgotten in a Word file somewhere in my Dropbox), but as it seems not much has changed in the meantime, it’s time to publish it anyway.

I was listening to the fantastic (now gone) SDN Trinity podcast while biking around Slovenian hills and almost fell off the bike while furiously nodding to a statement along the lines of “I hate how every SDN vendor loves to bash networking engineers.”

Now that we know which definitions of SDN make no sense (and which one might) let’s see what a typical architecture of an SDN solution might look like.

I described some of them in the SDN 101 webinar, for more details watch the SDN Architectures and Deployment Guidelines webinar.

One of my readers was listening to the Snabb Switch podcast and started wondering “whether it’s possible to leverage and adopt these bleeding-edge technologies without a substantial staff of savvy programmers?”

Short answer: No. Someone has to do the heavy lifting, regardless of whether you have programmers on-site, outsource the work to contractors, or pay vendors to do it.

A few days after I published a blog post arguing that most service providers cannot possibly copy Google’s ideas Giacomo Bernardi wrote a comment saying “well, we managed to build our own gear.”

Initially I thought they built their own Linux distribution on top of x86 server, but what Giacomo Bernardi described in Episode 59 of Software Gone Wild goes way beyond that:

A while ago Big Switch Networks engineers realized there’s a cool use case for their tap aggregation application (Big Tap Monitoring Fabric) – an intelligent patch panel traffic steering solution used as security tool chaining infrastructure in DMZ… and thus the Big Chain was born.

Curious how their solution works? Listen to Episode 58 of Software Gone Wild with Andy Shaw and Sandip Shah.

A blog post on Packet Pushers contained a quote by E. W. Dijkstra (of the SPF fame) and while trying to figure out whether that quote was real I stumbled upon his keynote address from a 1984 ACM conference (original). Not surprisingly, nothing has changed in the last 30+ years…

A while ago I discussed whether XMPP is a control- or management-plane protocol (spoiler: it depends). How about OVSDB? Here’s another question from one of my readers:

Why is Openflow considered as control plane protocol and OVSDB management plane protocol if both are relying on SDN controller? Is it because Openflow can directly modify the dataplane?

SDN controllers can use control- or management-plane protocols to get the job done.

During the Introduction to SDN webinar I covered numerous potential definitions:

• It’s the separation of control and data plane;
• It’s software-based packet forwarding;
• It’s open networking and whitebox switching;
• It’s network programmability and device APIs.

I find all of these definitions too narrow or even misleading. However, the “SDN is a layer of abstraction” one is not too bad (see also RFC 1925 section 2.6a).

Anyone following the popular networking blogs and podcasts is probably familiar with the claim that BGP is way too complex to be used in whatever environment. On the other hand, more and more smart people use it when building their data center or WAN infrastructure. There’s something wrong with this picture.