Category: SDN

I was speaking with a participant of an SDN event in Zurich after the presentations, and he made an interesting comment: whenever he experienced serious troubleshooting problems in his career, it was due to lack of understanding of networking fundamentals.

Let me give you a few examples: Do you know how ARP works? What is proxy ARP? How does TCP offload work and why is it useful? What is an Ethernet collision and when would you see one? Why do we need MLD in IPv6 neighbor discovery?

Dmytro Shypovalov published another article well worth reading: why should you use an SDN controller for RSVP-TE. It covers:

• The reasons people might still prefer RSVP-TE over SR-MPLS and the current state of RSVP-TE
• What an SDN controller might bring to the RSVP-TE world
• SR/RSVP coexistence and interworking

Have fun!

A few years ago, I was asked to deliver a What Is SDDC presentation that later became a webinar. I forgot about that webinar until I received feedback from one of the viewers a week ago:

If you like to learn from the teachers with the “straight to the point” approach and complement the theory with many “real-life” scenarios, then ipSpace.net is the right place for you.

I haven’t realized people still find that webinar useful, so let’s make it viewable without registration, starting with What Problem Are We Trying to Solve and What Is SDDC.

I stumbled upon an interesting article in one of my RSS feeds: should we build smart highways or smart cars?

The article eloquently explains how ridiculous and expensive it would be to put the smarts in the infrastructure, and why most everyone is focused on building smart cars. The same concepts should be applied to networking, but of course the networking vendors furiously disagree – the network should be as complex, irreplaceable, and expensive as possible. I collected a few examples seven years ago, and nothing changed in the meantime.

Even though Gartner declared SDN obsolete before plateau in their 2021 Networking Hype Cycle, most vendor marketers never got the memo. Anything that interacts with network devices in any way¹ is called an SDN controller. Let’s try to throw some minimal amount of taxonomy into that mess based on how these controllers interact with network elements (physical or virtual).

I started preparing the materials for the SDN – 10 years later webinar, and plan to publish a series of blog posts documenting what I found on various aspects of what could be considered SDN¹. I’m pretty sure I missed quite a few things; your comments are most welcome.

Let’s start with an easy one: software/hardware disaggregation in network devices.

Open-Source Network Operating Systems

I found several widely-used open-source² network operating systems:

In his latest blog post, Tom Hollingsworth compares network device disaggregations with cord cutting (replacing cable TV subscription with Netflix and friends), and comes to the inevitable conclusion:

The idea is that you gain freedom and cheaper software. The hope is that you can build an enterprise network for half of what it would normally cost. The reality is that you’re going to gain less functionality and spend more time integrating things together on your own instead of just putting in a turnkey solution.

To rephrase it, you’ll design a snowflake network with snowflake devices. Good job – just because it makes sense for the FAANG club (or LinkedIn), it doesn’t mean you should be doing it.

Patrik Schindler sent me an interesting comment to my Open-Source DMVPN Alternatives blog post:

Welcome to the build-or-buy dilemma, router edition.

One of my readers sent me this interesting question:

I understand that an SDN controller needs network topology information to build traffic engineering paths with PCE/PCEP… but why would we use BGP-LS to extract the network topology information? Why can’t we run OSPF with controller by simulating a software based OSPF instance in every area to get topology view?

There are several reasons to use BGP-LS:

A while ago Antti Leimio wrote a long twitter thread describing his frustrations with Cisco ACI object model. I asked him for permission to repost the whole thread as those things tend to get lost, and he graciously allowed me to do it, so here we go.

I took a 5 days Cisco DCACI course. This is all new to me. I’m confused. Who is ACI for? Capabilities and completeness of features is fantastic but how to manage this complex system?

Every now and then I get a question along the lines of “why can’t we have a distributed SDN controller (because resiliency) that would survive network partitioning?” This time, it’s not the incompetency of solution architects or programmers, but the fundamental limitations of what can be done when you want to have consistent state across a distributed system.

TL&DR: If your first thought was CAP Theorem you’re absolutely right. You can probably stop reading right now. If you have no idea what I’m talking about, maybe it’s time you get fluent in distributed systems concepts after you’re finished with this blog post and all the reference material linked in it. Don’t know where to start? I put together a list of resources I found useful.

When I’d first seen BGP-LS I immediately thought: “it would be cool to use this to fetch link state topology data from the network and build a graph out of it”. In those days the only open-source way I could find to do it involved Open DayLight controller’s BGP-LS-to-REST-API converter, and that felt like deploying an aircraft carrier to fly a kite.

Things have improved dramatically since then. In Visualizing BGP-LS Tables, HB described how he solved the challenge with GoBGP, gRPC interface to GoBGP, and some Python code to parse the data and draw the topology graph with NetworkX. Enjoy!

A long-time reader sent me a series of questions about the impact of WAN partitioning in case of an SDN-based network spanning multiple locations after watching the Architectures part of Data Center Fabrics webinar. He therefore focused on the specific case of centralized control plane (read: an equivalent of a stackable switch) with distributed controller cluster (read: switch stack spread across multiple locations).

This podcast introduction was written by Nick Buraglio, the host of today’s podcast.

In the original days of this podcast, there were heavy, deep discussions about this new protocol called “OpenFlow”. Like many of our most creative innovations in the IT field, OpenFlow came from an academic research project that aimed to change the way that we as operators managed, configured, and even thought about networking fundamentals.

For the most part, this project did what it intended, but once the marketing machine realized the flexibility of the technology and its potential to completely change the way we think about vendors, networks, provisioning, and management of networking, they were off to the races.

We all know what happened next.

Michael Mullany analyzed 20 years of Gartner hype cycles and got some (expected but still interesting) conclusions including:

• Nobody noticed major technologies even when they were becoming mainstream
• Lots of technologies just die, others make progress when nobody is looking
• We might get the idea right and fail badly at implementation
• It takes a lot longer to solve some problems than anyone expected

Enjoy the reading, and keep these lessons in mind the next time you’ll be sitting in a software-defined, intent-based or machine-learning $vendor presentation.