Category: SDN

A few days ago Inside-IT published an interview Christoph Jaggi did with me. In case you don’t understand German, here’s the English version of it.

There is a lot of talk about data center fabrics. What problem do they try to solve?

The data center fabrics are supposed to solve a simple-to-define problem: building a unified data center infrastructure that seamlessly supports data and storage communications. As always, the devil hides in the details.

This article was initially sent to my SDN mailing list. To register for SDN tips, updates, and special offers, click here.

During one of my SDN workshops one of the attendees working for a mid-sized European ISP asked me this question:

Our management tells us we should build our network like Google does, including building our own switches. Where should we start?

The only answer I could give him was “You don’t have a chance.”

Imagine you get a routing outage in your network resulting in three minutes of traffic blackholing. After a few tense minutes it goes away and life is good, but you desperately want to know what went wrong. Can you figure it out? Well, you could if you were using PacketDesign tools, as Cengiz Alaettinoglu explained on Episode 51 of Software Gone Wild.

A while ago someone posted a link to an article that links to LinkedIn’s blog post describing their switch-building efforts to the LinkedIn SDN group (how’s that for a circular reference?), and a consultant from Brocade felt compelled to share his wisdom with the world. Unfortunately he got most of the facts wrong.

Julian Lucek did a fantastic job describing how NorthStar controller uses BGP-LS and PCEP, so I asked him whether he’d be willing to do a deep dive on these two topics. He gracefully agreed, and the results are already online.

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: