Category: workshop

All overlay virtual networking solutions look similar from far away: many provide layer-2 segments, most of them have some sort of distributed layer-3 forwarding, gateways to physical world are ubiquitous, and you might find security features in some products.

The implementation details (usually hidden behind the scenes) vary widely, and I’ll try to document at least some of them in a series of blog posts, starting with VMware NSX.

Traditional data centers are usually built in a very non-scalable fashion: everything goes through a central pair of firewalls (and/or load balancers) with thousands of rules that no one really understands; servers in different security zones are hanging off VLANs connected to the central firewalls.

Some people love to migrate the whole concept intact to a newly built private cloud (which immediately becomes server virtualization on steroids) because it’s easier to retain existing security architecture and firewall rulesets.

The recent Juniper product launch included numerous components, among them: a new series of data center switches (including a badly-needed spine switch), MetaFabric reference architecture (too meta for me at the moment – waiting to see the technical documentation beyond the whitepaper level), and (finally) a leaf-and-spine virtual chassis – Virtual Chassis Fabric.

Every good data center presentation starts with redefining The Problem and my VMware NSX Architecture webinar was no exception – the first section describes Infrastructure-as-a-Service Networking Requirements.

I sprinted through this section during the live session, the video with longer (and more detailed) explanation comes from the Overlay Virtual Networking webinar.

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

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!

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

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.

Remember Tore Anderson’s IPv6-only data center design he described in last June’s webinar? Wondered how he got it done? The secret sauce he used is SIIT – the stateless IPv6-to-IPv4 translation technology. His trick: turning it around.

Regardless of the advantages of photonic switching (David Husak claims it’s 20.000 times more effective than electronic switching), the programmable optical components remain ludicrously expensive, prompting Plexxi to launch a cost-optimized fixed-topology version of their data center products.

During the Networking Tech Field Day 6 Spirent showed us Avalanche NEXT – another great testing tool that generates up to 10Gbps of perfectly valid application-level traffic that you can push through your network devices to test their performance, stability or impact of feature mix on maximum throughput.

Not surprisingly, as soon as they told us that you could use Avalanche NEXT to replay captured traffic we started getting creative ideas.

One of the usual complaints I hear whenever I mention overlay virtual networks is “with overlay networks we lose all application visibility and QoS functionality” ... that worked so phenomenally in the physical networks, right?

Networking vendors are quick to point out how the opaqueness (read: we don’t have the HW to look into it) of overlay networks presents visibility problems and how their favorite shiny gizmo (whatever it is) gives you better results (they usually forget to mention the lock-in that it creates).

Now let’s step back and ask a fundamental question: how much bandwidth do we need?