Category: OpenFlow

I don’t like to correct my friends in public, but if someone says “I still believe that flow-based technologies will exceed the capabilities of packet-based technologies” (see Network Break 53), it’s time to revisit the networking fundamentals.

What is a flow?

According to Wikipedia (but what do they know…):

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”).

One of the typical questions I get in my SDN workshops is “how do you run control-plane protocols like LACP or OSPF in OpenFlow networks?”.

I wrote a blog post describing the process two years ago and we discussed the details of this challenge in the OpenFlow Deep Dive webinar. That part of the webinar is now available with Free ipSpace.net Subscription.

Writing OpenFlow controllers that interact with physical hardware is harder than most people think. Apart from developing a distributed system (which is hard in itself), you have to deal with limitations of hardware forwarding pipelines, differences in forwarding hardware, imprecise abstractions (most vendors still support single OpenFlow table per switch), and resulting bloated flow tables.

After I wrote a comment on a LinkedIn discussion in the Carrier Ethernet group (more details here), Vishal Sharma wrote an interesting response, going into more details of distinction between centralized control and centralized control plane.

Every other week I stumble upon a high-level SDN article that repeats the misleading SDN is centralized control plane mantra (often copied verbatim from the Wikipedia article on SDN, sometimes forgetting to quote the source).

Yesterday, I had enough and decided to respond.

Packet Pushers podcast is a constant source of inspiration for my blog posts. Recently I stumbled upon Rob Sherwood’s explanation of how they package Big Cloud Fabric:

It’s a vertically integrated solution, from Switch Light OS to our SDN controller and Big Cloud Fabric application.

Really? What happened to openness and disaggregation?

Reinventing the wheels makes little sense. Implementing old solutions with new tools might be in the same category, but at least it shows you the power and shortcomings of the new tools.

Building a VLAN-aware bridge in OpenFlow is thus a mandatory case study, and as you’ll see in the video from the OpenFlow Deep Dive webinar, it’s not as easy as it looks. For more details, watch the whole OpenFlow webinar (6 hours of in-depth videos), which you also get by buying Advanced SDN Training or ipSpace.net subscription.

One of my readers couldn’t figure out how to combine Link Aggregation Groups (LAG, aka Port Channel) with OpenFlow:

I believe that in LAG, every traditional switch would know how to forward the packet from its FIB. Now with OpenFlow, does the controller communicate with every single switch and populate their tables with one group ID for each switch? Or how does the controller figure out the information for multiple switches in the LAG?

As always, the answer is “it depends”, and this time we’re dealing with a pretty complex issue.

Another question I got in my Inbox:

What is your opinion on NAC and 802.1x for wired networks? Is there a better way to solve user access control at layer 2? Or is this a poor man's way to avoid network segmentation and internal network firewalls.

Unless you can trust all users (fat chance) or run a network with no access control (unlikely, unless you’re a coffee shop), you need to authenticate the users anyway.