@ioshints sure but can't OpenFlow be used to implement an LB? It feels like a mix of terms here— Kristian Larsson (@plajjan) December 3, 2015
When writing the Packet- and Flow-Based Forwarding blog post, I tried to find a good definition of flow-based forwarding (and I was not the only one being confused), and the one from Junos SRX documentation is as good as anything else I found, so let’s use it.
TL&DR: Flow-based forwarding is a valid technical concept. However, when mentioned together with OpenFlow, it’s mostly marketing fluff.
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.
Security groups (or Endpoint Groups if you’re a Cisco ACI fan) are a nice traffic policy abstraction: instead of dealing with subnets and ACLs, define groups of hosts and the rules of traffic control between them… and let the orchestration system deal with IP addresses and TCP/UDP port numbers.
When I finished my SDN workshop @ Interop Las Vegas (including a chapter on OpenFlow limitations), some attendees started wondering whether they should even consider OpenFlow in their SDN deployments. My answer: don’t blame the tool if people use it incorrectly.
Two days later, I discovered HP is one of those companies that knows how to use that tool.
I was listening to one of the HP SDN Packet Pushers podcasts in which Greg made an interesting comment along the lines of “people say that OpenFlow doesn’t scale, but what HP does with its IMC is it verifies the amount of TCAM in the switches, checks whether it can install new flows, and throws an alert if it runs out of TCAM.”