The “Is CLI In My Way … or a Symptom of a Bigger Problem” post generated some interesting discussions on Twitter, including this one:

One would hope that we wouldn’t have to bring up this point in 2014 … but unfortunately some $vendors still don’t get it.

When describing Hyper-V Network Virtualization packet forwarding I briefly mentioned that the hypervisor switches create (an equivalent of) a host route for every VM they need to know about, prompting some readers to question the scalability of such an approach. As it turns out, layer-3 switches did the same thing under the hood for years.

Marcos Hernandez sent me a nice list of updates/errata after watching the NSX firewalls video from the VMware NSX Architecture webinar:

One of my regular readers sent me a long list of FCoE-related questions:

I wanted to get your thoughts around another topic – iSCSI vs. FCoE? Are there merits and business cases to moving to FCoE? Does FCoE deliver better performance in the end? Does FCoE make things easier or more complex?

He also made a very relevant remark: “Vendors that can support FCoE promote this over iSCSI; those that don’t have an FCoE solution say they aren’t seeing any growth in this area to warrant developing a solution”.

The first question I tried to answer (and probably failed to) in the SDN 101 webinar was: What exactly is SDN? Is it an architecture with physically separate centralized control plane, or is it more? Does separate control plane make sense, or is it better to program distributed devices? Watch the video recorded during the live webinar session and tell me whether you agree with my answers.

A while ago Sander Steffann and Iljitsch van Beijnum wrote a fantastic document that compared most (somewhat) widely used IPv6-over-IPv4 tunneling mechanisms. The document got published as RFC 7059 in November and is a definite must-read for anyone having to deal with this particular can of worms.

Unfortunately the document doesn’t cover the recent IPv4 sunset developments – numerous mechanisms that transport IPv4 leftovers over IPv6-only access networks (MAP-E, DS-Lite, lw4over6, 464XLAT …). One can only hope Sander and Iljitsch plan to produce a complementary document soon ;)

If you’re building a Greenfield private cloud, you SHOULD consider using virtual network services appliances (firewalls, load balancers, IPS/IDS systems), removing the need for additional hard-to-scale hardware devices. But can we go a step further? Can we replace all networking hardware with x86 servers and virtual appliances?

My good friend Ethan recently published a blog post rightfully complaining how various vendor CLIs hamper our productivity. He’s absolutely correct from the productivity standpoint, and I agree with his conclusions (we need a layer of abstraction), but there’s more behind the scenes.

I hope it’s obvious to everyone by now that flow-based forwarding doesn’t work well in existing hardware. Switches designed for large number of flow-like forwarding entries (NEC ProgrammableFlow switches, Enterasys data center switches and a few others) might be an exception, but even they can’t cope with the tremendous flow update rate required by reactive flow setup ideas.

One would expect virtual switches to fare better. Unfortunately that doesn’t seem to be the case.

Network tapping and tap aggregation are obviously the OpenFlow equivalent of the Hello World application – almost every OpenFlow controller vendor has a tap aggregation solution. Does that make sense? Sure – tap aggregation network is outside of the production data path and thus a great candidate for semi-production technology pilots.

For more details, watch the Tap Aggregation Networks video recorded during the Real Life OpenFlow-based SDN Use Cases webinar