Category: SDN

Russ White made an excellent remark while discussing the news that the CloudRouter pushed 650 Gbps through commodity hardware: “If this is software defined networking, then we’ve been doing this since sometime in the 1990’s, perhaps even earlier…”

He’s absolutely right – the first routers (like AGS or IGS from Cisco) did all packet forwarding in software, so as I explained during the Introduction to SDN webinar while reaching dozens of gigabits with software-based packet forwarding is exciting, calling it SDN doesn’t make much sense.

The organizers of Troopers 16 conference published the video of my Real-Life Software Defined Security talk. The slides are available on my web site.

Hope you’ll enjoy the talk; for more SDN use cases watch the SDN Use Cases webinar.

A while ago Christer Swartz explained how a Palo Alto firewall integrates with VMware NSX. In the meantime, Palo Alto announced integration with Cisco ACI and OpenStack, and it was time for another podcast with Christer deep-diving into the technical details of these integrations.

Spoiler: It’s not OpFlex. For more details, listen to Episode 53 of Software Gone Wild

Some people conflate SDN with whitebox switches preferably running Linux. So what exactly is software-hardware disaggregation, and how do whitebox switches and third-party network operating systems fit into the bigger picture?

I tried to answer these questions in the SDN is not whitebox switching part of (free) Introduction to SDN webinar.

One of my readers sent me this question:

Considering I know nothing about anything SDN-related (and considering it seems "SDN" means something different depending to whom you are asking), where should someone with no knowledge of SDN start?

The obvious answer: sdn.ipSpace.net. On a more serious note:

Imagine you want to have an IPv6-only access network and transport residual IPv4 traffic tunneled across it. Sounds great, but you need to terminate those tunnels and encapsulate/decapsulate IPv4 traffic at multi-gigabit rate.

There are plenty of reassuringly-expensive hardware solutions that can do that, or you could work with really smart people and get software-based solution that can do 20 Gbps per CPU core.

When someone starts complaining about networking device CLI, remind him that other parts of IT aren’t doing much better. For example, it’s oh-so-easy to install a package on Linux or OSX.

I spent the first half of the Introduction to SDN webinar explaining various attempts at defining SDN, and the obvious place to start was the centralized control plane mantra.

This part of the webinar is now public; to access the rest of the webinar, register on my web site.

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.