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:

When I wrote a blog post explaining the difference between centralized control and centralized control plane, John Casey, CEO of CPLANE Networks wrote a comment saying “yeah, that’s exactly what we’re doing.”

It took us a while to get the stars aligned, but finally we managed to sit down and chat about what they’re doing, resulting in Episode 46 of Software Gone Wild.

Nuno wrote an interesting comment to my Stretched Firewalls across L3 DCI blog post:

You're an old school, disciplined networking leader that architects networks based on rock-solid, time-tested designs. But it seems that the prevailing fashion in network design and availability go against your traditional design principles: inter-site firewall clustering, inter-site vMotion, DCI, etc.

The featured webinar of December 2015 is vSphere 6 Networking, a 6-hour deep dive into vSphere 6 networking features covering almost every single vSphere network-related feature.

What does this mean?

Trial subscribers get free access to select videos from this webinar (those marked with a yellow star in this listing) and can purchase it at significant discount.

Yesterday I described the theoretical limitations of using OpenFlow for load balancing purposes. Today let’s focus on the practical part and answer another question:

@colin_dixon @ioshints and for a fair comparison: Would a $100k OF switch be able to act as proper LB?

— Kristian Larsson (@plajjan) December 3, 2015

I wrote about the same topic years ago here and here. I know it’s hard to dig through old blog posts, so I collected them in a book.

It all started with a tweet Kristian Larsson sent me after I published my flow-based forwarding blog post:

@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

Do you need VXLAN in your data center or could you continue using traditional bridging? Do layer-2 fabrics make sense or are they a dead end in the evolution of virtual networking?

I tried to provide a few high-level answers in the Introduction to VXLAN video which starts the VXLAN Technical Deep Dive webinar. The public version of the video is now available on ipSpace.net Free Content web site.

Marek Majkowski published an awesome real-life story on CloudFlare blog: users experienced occasional short-term sluggish performance and while everything pointed to a network problem, it turned out to be a garbage collection problem in Linux kernel.

Takeaway: It might not be the network's fault.

Also: How many people would be able to troubleshoot that problem and fix it? Technology is becoming way too complex, and I don’t think software-defined-whatever is the answer.

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.

If you’re a host running on an IPv6-only network, you might want to detect the IPv6 prefix used for NAT64 (for example, to transform IPv4 literals a clueless idiot embedded into a URL into IPv6 addresses).

Apple has a wonderful developer-focused page describing NAT64 and DNS64, including the way they synthesize IPv6 addresses from IPv4 literals. You (RFC 6919) MUST read it.