During the final part of the IPv6-only data centers webinar Tore Anderson described his deployment guidelines and answered a few more questions.

Another day, another stateful debate, this time centered on the number of flows per hypervisor. Previously I guestimated 2.500 connections-per-second-per-(user-facing)gigabit and 37.500 concurrent sessions per user-facing gigabit, but wanted to align my numbers with reality before reaching any conclusions.

My web sites are way too small, so I asked a few of my friends to help me get more realistic figures.

Jason Edelman wrote a great blog post after watching Ethan Banks struggle with yet another multi-vendor IPsec deployment. Some of his ideas make perfect sense (wiki-like web site documenting working configurations between vendor X and Y for every possible X and Y), others less so (tunnel broker – particularly in view of recent Tor challenges), but let’s step back a bit and ask ourselves “Why is IPsec so complex?”

OpenFlow is a simple TCAM programming protocol, and can be used to implement any network forwarding paradigm as long as:

• OpenFlow specifications include matches and actions (including rewrites) of the packet header fields used in the forwarding paradigm. For example, you cannot program SRv6 tunnels with OpenFlow because it’s not part of OpenFlow standard.
• The forwarding hardware you want to use supports the OpenFlow matches and actions you need in your forwarding paradigm.
• The forwarding paradigm does not use dynamic interfaces (example: MPLS-TE tunnels) or multipoint tunnel interfaces (example: VXLAN). OpenFlow was designed to be used on point-to-point physical interfaces and does not include interface management.

This blog post describes some of the more common OpenFlow use cases (assuming you want to use an obsolete rarely-implemented protocol).

A while ago I wrote about ATAoE and why I think a layer-2-only TFTP-like protocol shouldn’t be used these days. As always, the answer to that black-and-white opinion (and I’m full of them) is “it depends” – ATAoE works great if you do it right.

The edited videos from VMware NSX Architecture webinar are published on my demo content web site and on YouTube. Enjoy!

It all started with a message from one of my Twitter friends: “how on Earth do you find the time to blog so often?” Here’s the secret recipe: a happy little thought and a bit of fairy dust. No, got it wrong, that helps you fly. The real secret ingredients: time, process, ideas, and a pinch of motivation.

One of the holy grails of data center SDN evangelists is controller-driven traffic engineering (throwing more leaf-and-spine bandwidth at the problem might be cheaper, but definitely not sexier). Obviously they don’t call it traffic engineering as they don’t want to scare their audience with MPLS TE nightmares, but the idea is the same.

Interestingly, you don’t need new technologies to get as close to that holy grail as you wish; Petr Lapukhov got there with a 20 year old technology – BGP.

TL&DR Summary: Yes (if you’re clumsy enough).

A while ago I read Impact of Graceful IGP Operations on BGP – an article that described how changes in IGP topology result in temporary (or sometimes even permanent) forwarding loops in networks using BGP route reflectors.

Is the problem real? Yes, it is. Could you generate a BGP RR topology that results in a permanent forwarding loop? Yes. It’s not that hard.

Tassos opened an interesting can of worms in a comment to my Management, Control and Data Planes post: Is ICMP response to a forwarded packet (TTL exceeded, fragmentation needed or destination unreachable) a control- or data-plane activity?

My keynote speech @ PLNOG11 conference was focused on (surprise, surprise) overlay virtual networks and described the usual motley crew: The Annoying Problem, The Hated VLAN, The Overlay Unicorn, The Control-Plane Wisdom and The Ever-Skeptic Use Case. You can view the presentation on my web site; PLNOG organizers promised video recording in mid-October.

Just in case you’re wondering why I keep coming back to PLNOG: they’re not only as good as ever; they’re getting even more creative.

After we get rid of the QoS FUD, the next question I usually get when discussing overlay networks is “how should these networks treat IP TTL?”

As (almost) always, the answer is “It depends.”

OpenStack seems to have a great architecture: all device-specific code is abstracted into plugins that have a well-defined API, allowing numerous (more or less innovative) implementations under the same umbrella orchestration system.

Looks great in PowerPoint, but to an uninitiated outsider looking at the network (Quantum, now Neutron) plugin through the lenses of OpenStack Neutron documentation, it looks like it was designed by either a vendor or a server-focused engineer using NIC device driver concepts.

I must have confused a few readers with my blog posts describing Arista’s VARP and Enterasys’ Fabric Routing – I got plenty of questions along the lines of “how does it really work behind the scenes?” Let’s shed some light on those dirty details.

Ed Horley, an awesome IPv6 geek I had the privilege to meet at NFD6, wrote an interesting blog post arguing against IPv6 ULA usage (particularly when combined with NPT66). We would all love to get rid of NAT, however ...