The Fat Pipe - All Packet Pushers Pods

A few years back, the number of data center-oriented overlays the market saw got to be a bit humorous. There was VXLAN, NVGRE, and STT all targeted (mostly) at helping with network virtualization and scale inside the data center.

The funny part was how similar these overlays all seemed to be. Why not get behind one standard as an industry?

Then in February 2014, Geneve was announced. Some of us face-palmed. Another overlay? What could possibly be the point of another one? Well, there was — and is — a point.

Geneve, which is an IETF project, aims to take the best parts of STT, NVGRE, and VXLAN. And while you might assume VXLAN has won the overlay war, Geneve is seeing active development for some good reasons we’ll discuss today.

Several folks who are involved in Geneve were kind enough to give up some of their time for this conversation:

Jon Hudson, Futurist & Principal Engineer, Office of the CTO at Brocade; Dinesh Dutt, Chief Scientist at Cumulus Networks; and Jesse Gross, Senior Staff Engineer at VMware.

Show Notes:

-Why was Geneve conceived in the first place? What was going on at the time?

-In the IETF project hierarchy, Geneve is grouped with NVO3. What is NVO3, and how does Geneve fit into that framework?

-Geneve wants to take the best parts of STT, NVGRE, and VXLAN. What are those parts, and why do they represent significant advantages?

* STT

* NVGRE

* VXLAN

-Geneve is extensible, which gives it a long-term market advantage. What do we mean by extensible here?

-What is the IETF status of Geneve as a standard?

-I thought VXLAN won. If that’s not the case, what market adoption are we seeing for Geneve?

* Hardware (silicon) vendors

* Software/NFV vendors

* Open source community projects

Will Geneve ultimately replace VXLAN, etc.? Or will it be just another overlay option?

Links:

Geneve – Russ White

Geneve, VXLAN, And Network Virtualization Encapsulation – Bruce Davie, VMware

On today’s Priority Queue, we discuss the idea of NSX Everywhere. VMware NSX is not a new topic on Packet Pushers. We’ve been covering NSX since Nicira was a startup, and kept up with its evolution over the years.

The last Priority Queue show we did with VMware was episode 56 on NSX in production. If you want to catch up with where NSX is at, you might want to listen to that show before you listen to this one.

This show is an evolution of the NSX story, bringing up the notion of using NSX Everywhere. Typically we think of NSX as a data center play; a centrally managed network overlay for network virtualization, micro-segmentation, and centrally managed firewall services.

Guido Appenzeller, Chief Technology Strategy Officer in the network and security business unit at VMware, joins Ethan and Greg in this sponsored podcast to talk about NSX’s capabilities for containers, the cloud, mobile devices, and more.

What We Discuss:

* How the conversation is changing from ‘What is SDN?’ to ‘Where will it make a difference in our organization?’

* NSX 6.2 updates, including support for containers and Amazon’s cloud

* Instantiating new features in software rather than hardware

* The impact of containers on networking and infrastructure

* How NSX and microsegmentation apply to container security

* Why hypervisors will still be relevant for containers

* Using NSX to help enforce mobile device policy

* Why separating policy from IP addressing makes sense

Links:

You can follow Guido on Twitter at @appenz. He also blogs at Network Heresy. To find out more about NSX, check out vmware.com/products/nsx/.

IT has been trained to operate equipment, but can they–and should they–learn the fundamentals that underpin the infrastructure? Does the enterprise have the skills,  resources, and competency to handle the transition to the cloud?

These questions caused a passionate debate with Kelsey Hightower @kelseyhightower and Keith Townsend @ctoadvisor on whether enterprises have been able to:

* Retain the right people

* Build skills and knowledge

* Have enough staff

* Have good leadership

Without these human resources, an enterprise might outsource to a vendor or a reseller to get the advice and support they need. Hear what our debaters have to say, and tell us what we got wrong (and right) in the comments section.

With IPv4 address space officially exhausted in ARIN’s region, we’ve moved into a market of IPv4 scarcity. If you want new publicly routable IPv4, you’ll have to get it from your ISP (what normally happens when you order a circuit), or from some other party willing to sell their address space to you.

To facilitate the transaction of IPv4 addresses between parties, many different IPv4 broker services have popped up. Is this a service your organization should take advantage of? Are there risks involved in IPv4 transactions like this?

John Curran, President and CEO of ARIN, joins us to help us understand the issues surrounding IPv4 broker services.

Show Notes:

– Level setting. What does it really means that ARIN is out of IPv4 address space to allocate?

* ARIN did not reserve any blocks, like some RIRs did.

* ARIN allocated the last of the IPv4 space for its region.

* This does not mean that service providers are out. In fact, this is where most end users are going to get IPv4 address space from.

– IPv6 is the future, but adoption remains slow in the United States. From ARIN’s point of view, what major obstacles remain in the way of full IPv6 adoption?

– A sort of gray market for IPv4 addresses has emerged now that all allocations are gone. In general, what is ARIN’s view of this market?

– Getting IPv4 address space from someone ARIN has allocated to isn’t as simple as buying the address block from them. ARIN is still involved. Please describe that involvement.

– Many different IPv4 brokers have sprung up to facilitate IPv4 transactions between buyers and sellers. Does ARIN govern this market or license brokers in any official capacity?

– What is ARIN’s advice to companies that are considering an IPv4 broker service?

* Things to look for in a broker

* Red flags

On this Packet Pushers Priority Queue, we interview Rob Sherwood, CTO of Big Switch Networks, to gain an alternate view on OpenFlow TTPs (table type patterns). We first talked about TTPs in Weekly 220 in a discussion with Curt Beckmann back in January 2015. While Curt was fairly enthused that TTPs were going to move the ball forward, Rob is not convinced that TTPs are the long-term answer to make it easier for OpenFlow controllers and switches to share capabilities.

What We Discuss

* How OpenFlow is used by a switch to make decisions

* What tables are used by a switch to store actionable information impacting packet forwarding

* How TTPs describe these tables – the schemas that TTPs provide

* Why defining specific TTP schemas is short-changing hardware capabilities in some silicon, and might even result in sub-optimal performance in specific operations

* The emergence of P4 as a “language of constraints”

* Silicon manufacturers obfuscate details of their specific chips as a competitive advantage. That puts TTPs that describe switching capabilities generically at a disadvantage. Without knowing specifics, it’s probably not possible to write a TTP that will result in a chip being used optimally

* TTP is the best solution we have today. But perhaps not tomorrow

Links

Weekly 220: OpenFlow + Table Type Patterns with Curt Beckmann

Rob Sherwood on Twitter

Purpose-built hardware appliances for routing, load balancing, firewalling and other network services are giving way to virtual instances designed to run on x86-based servers. This trend is broadly defined as network functions virtualization (NFV).

It’s part of the shift toward ‘software-defined’ environments where an orchestration system invokes a series of network functions to deliver a set of services to a consumer.

The trend is taking hold in part because x86-based machines are cheaper and easier to scale than specialized hardware appliances.

However, a challenge with hypervisor networking is performance. How do you get the throughput you need out of an x86 server when the tastiest hardware bits of the CPU core and NICs are abstracted away?

Today on Packet Pushers Priority Queue, we’re going to discuss the hypervisor performance bottleneck, some of the workarounds that exist today, and the commercial-grade virtual acceleration for hypervisor networking with our sponsor, 6WIND. Yann Rapaport, product manager at 6WIND, joins us for the discussion.

We’ll talk about the reasons why virtual switches struggle to fill physical pipes, walk through the packet flow through a hypervisor, and talk about packet processing in Linux. We’ll look at some of the efforts to address performance issues, including SR-IOV, and OVS with DPDK.

We also drill into 6WIND’s technology, including Virtual Accelerator, Turbo Router, and Turbo IPSec.

For more information about 6WIND, see the Packet Pushers blog 6WIND Offering Accelerated L3 Virtual Appliances.

Links:

Hardware Versus Software Switching – 6WIND Whitepaper

6WIND Turbo Router + 6WIND Virtual Accelerator vs. Linux Routing + Open vSwitch – 6WIND Video

6WIND Turbo IPsec + 6WIND Virtual Accelerator vs. Linux IPsec + Open vSwitch – 6WIND Video

Blazing performance with 6WIND Speed Series Turbo Appliances – SDX Central

6WIND Offering Accelerated L3 Virtual Appliances – Packet Pushers