The Fat Pipe - All Packet Pushers Pods

Today’s visit to the Priority Queue curiosity shop explores the notion of multi-layered control planes. Guest Russ White joins us to outline the concept of a control plane that’s broken out into separate functional classes. The goal is to keep the networking protocols that operate at each layer as simple as possible.

Current efforts around software-defined networking advocate a centralized controller, but Russ and Ethan review how the industry has oscillated between centralized and decentralized models for decades.

Part of the problem is that both models come with their own complexities. Limitations inherent with decentralization may be addressed via centralization, but you also inherit the limitations built into centralization.

Russ and Ethan discuss CAP Theorem as it applies to the control plane, and the balance that has to be struck when centralizing control of a distributed system, i.e. a network.

They also discuss what a layered control plane might look like. Russ outlines three categories in a layered control plane.

First is base reachability and topology (that is, what is located where on the network). Second is network policy, such as traffic engineering, filtering packets, and service chaining. Third is business logic; for example, don’t run this workload across the network until after 5:00 pm.

By separating out these layers, you can allow protocols  to do what they are expressly designed to do, rather than trying to twist and manipulate them to enable more functions than they were intended to provide.

Prepare to have your mind expanded as Russ and Ethan get conceptual.

Show Notes:

Part 1 – Why Is The Industry Having This Argument?

* Decentralized is hard (complex)!

* Centralized is hard (complex)!

* Yes, but do we ever really do away with complexity?

* This leads us to CAP theorem. Which of these are going to have, and at what cost?

* Consistency

* Availability

* Partitionability

Part 2 – Layering

* We layer lots of things…

* Protocols

* Topologies

* Can we layer the control plane?

Part 3 – A Conceptual Proposal For Control Plane Layering

* Top layer

* Business logic

* We need the control plane to do things for these overriding business reasons

* Middle layer

* Hide things

* Traffic engineering

* Flow engineering

* Lower layer

* Reachability

* React to topology changes

* ALTERNATIVELY

* Problem bounding

* APIs

* Challenges with this approach

* Should this proceed? If so, how?

Today’s Priority Queue looks at the real state of private cloud. While public cloud gets the most media attention, and some analyst firms argue that private cloud doesn’t make sense for most companies, it’s a myth that there’s only one way to ‘do cloud.’

Our guest today is Greg Knieriemen, Technology Strategist and Evangelizer at Hitachi Data Systems and co-host of the Speaking in Tech podcast.

Greg and the Packet Pushers talk about the different business cases for public and private cloud, how cloud adoption is both an IT and a company culture issue, and what digital transformation actually means.

They also discuss research about the growth of private cloud and how private cloud is valued by companies compared to public options.

It’s an episode full of unicorn riding and impassioned debate.

Links:

The REAL State of Cloud – Greg Knieriemen’s Blog

Successful Private Clouds Aren’t Spoken Of In Public – Ethereal Mind

Response: Why On-Premises Software Will Die Sooner – Ethereal Mind

Gartner Being Wrong On OpenStack – Ethereal Mind

So You Wanna Go On-prem Do Ya – Blog Dot Lusis

Infrastructure Software is Dead – Mirantis

The world is full of open-source networking projects, and one of those worth a look is CloudRouter. CloudRouter is an open source software project built on Linux. It’s designed to run in physical and virtual environments, including the cloud. Currently in version 3.0, CloudRouter supports  core routing protocols including BGP and OSPF, and supports both IPv4 and IPv6.

It also includes firewall capabilities, IP management, and bundles in implementations of open-source SDN controllers OpenDaylight and ONOS.

The Packet Pushers are joined by Jay Turner, senior director of DevOps at Console and the head of the CloudRouter project, to learn more about the software and its capabilities, and talk about deployments.

Links:

CloudRouter.org

CloudRouter features

CloudRouter community, mailing lists, GitHub, JIRA

CloudRouter on Twitter

The virtual switch in the hypervisor has been a highly competitive space for a number of years, with VMware’s Virtual Switch squaring off against Open vSwitch.

More recently, other initiatives like such as IO Visor have been attempting get away from perceived limitations. (You can listen to our podcast on the subject here.)

Meanwhile, open source projects like Romana, Project Calico and other are trying to avoid using a switch at all by using arcane methods.

Why all the fuss? Because the virtual switch is critical not only to connecting VMs to the network, but also because Network Functions Virtualization (NFV) means that our appliances will be running in KVM hypervisors on Linux.

We need a software networking edge that does the things we want.

Enter the FD.io project. This effort, originally undertaken by Cisco and now a collaborative project under the Linux Foundation, aims to accelerate software-based packet processing through a variety of initiatives, including a virtual switch/router called Vector Packet Processing (VPP).

Cisco contributed the initial VPP code to the Linux Foundation.

On this episode of Priority Queue, the Packet Pushers are joined by Dave Ward, Dave Barach, and Maciek Konstantynowicz from Cisco to talk about virtual switching, the open source project, and to get into detail about the capabilities of VPP.

Links:

FD.io Project

A bigger helping of Internet PLEASE! – Dave Ward’s detailed blog on FD.io and VPP ]()

What is VPP? – FD.io

User space – Wikipedia

PQ Show 84: Cloud Network Complexity Vs. Romana.io – Packet Pushers

PQ Show 60: The IO Visor Project And Linux Networking – Packet Pushers

Romana is an open-source project that tackles network and security issues for cloud-native applications.

Romana’s goal is to address these issues with the simplest possible solutions using technologies we’re all familiar with–no overlays required.

According to its Web site, Romana “automates the creation of isolated Cloud Native Networks and secures applications with a distributed firewall that applies access control policies consistently across all endpoints and services, wherever they run.”

Joining us on Priority Queue to talk about the project is Chris Marino. Chris is part of a team behind Romana, and the founder and CEO of Pani Networks. We’ll explore just what the Romana project is about, drill into its major components, and look at its integration with OpenStack and Kubernetes.

We’ll also play Devil’s advocate to look at limitations with the project. To get more details about Romana, check out the project’s blog.

Show Notes:

Section 1 – Are Cloud Native Networks Really That Complex?

* What do we mean when we say “cloud native network”?

* Not just private cloud, also public cloud

* The emerging container problem

* A common solution in this space is an overlay using VXLAN with an SDN controller.

* What does VXLAN do for us?

* How does the SDN controller fit in?

* So let’s do a multi-tenant packet walk

* How hard is it to troubleshoot this sort of architecture?

Section 2 – Introducing The Romana Project

* In a nutshell, what is the Romana project?

* Let’s discuss the IP scheme used

* 32 bits

* Break them up how you need

* By default, broken on the octet boundary

* Network, tenants, hosts, networks, endpoints

* Okay, so let’s talk through each of the components

* Route manager

* IPAM

* Service insertion

* Is there a Romana API?

* Explain how Romana integrates with OpenStack

* Explain how Romana integrates with Kubernetes

Section 3 – Devil’s Advocate

* I find your lack of scale disturbing

* I want to use IPv6 addressing instead of IPv4. When?

* vMotion. I really, really want that…

* Native IP with no encap makes me nervous. Why shouldn’t it?

* How do I explain Romana multi-tenancy to a security auditor?

* There is zero chance I’m going to use static routes. Will Romana integrate with my BGP or OSPF?

* How is Romana itself secured so that it’s not provisioning IPs for undesirable endpoints or hosts?

The brave new world of networking services is automated, elastic, and chained.

That is to say, if you need to push traffic through a bunch of virtual middleboxes, you’re going to automate the creation of those middleboxes. Eventually, the days of standing up hardware services and plumbing them oh-so-carefully will be gone, because the world won’t wait for you to get it done. Automation is your answer.

And when you need to create more of them to support additional volume, the services will grow dynamically – more instances stood up and torn down as needed, depending on load.

And if you have a bunch of network services an application must pass through, you’ll set up traffic patterns in a service chain so that traffic flows through the virtual network services they need to without you having to rely on physical plumbing and clever routing.

All of this happens today in the worlds of OpenStack, containers, NFV, and microservices. In other words, this isn’t the “unicorn networking no one uses” that some of you complain about. This is real stuff.

To discuss microservice orchestration for networking is our sponsor, Sonus Networks. Bryan Hill, Vice President, Platform Engineering, joins us from Sonus to explore what microservices mean and how they are linked together in a cloud architecture.

We’ll also get into details about the orchestration mechanisms within OpenStack, discuss an OpenStack reference model, talk about how virtual network functions (VNFs) and microservices relate, and review several use cases.

Link:

ETSI OpenStack Reference Model (PDF)

Here on the Priority Queue, we’re soaring over the campus, buoyed aloft by 2.4 and 5 gigahertz radio waves carrying us to the land of Aruba Networks’ wireless certifications.

Aruba offers a plethora of certifications, and now that Aruba is part of Hewlett Packard Enterprise, those certs become part of the wider HPE certification ecosystem.

Kimberly Graves is here to chat with us about the Aruba Networks certification ladder. She’ll discuss why to certify on Aruba gear, what you’ll learn, and offer training and testing insights. Kimberly is a wireless network engineer and security consultant, and is currently a senior course and exam developer at Aruba. You can follow her on Twitter at @kimberlyagraves.

Show Notes:

Section 1 – Why Certify On Aruba Gear?

* Will I learn wireless fundamentals?

* Are there a lot Aruba installations out there that need certified people?

* Will my Aruba certs help me operate non-Aruba wireless networks?

Section 2 – Certification Levels And Tracks

* What are the main levels of certification (associate, professional, expert, etc.)?

* What are the major certification tracks?

* Which tracks are seeing the most growth or demand from the industry?

Section 3 – Training, Testing And Costs

* Will I be able to get certified without hands-on training? If not, how can I fix that?

* I’m a self-paced learner. What resources are available to me?

* Books

* Training

* Community

* Is there a recommended minimum spec for a home lab?

* I like to go to class. What are my options?

* Online

* Brick & mortar

* How are tests administered?

* Lower-level exams

* Expert exams

* Between training and testing, how much is this all going to cost?

If SDN is about automation and orchestration to configure the network, then the unasked (and unanswered question) is how do we test it? And how do we automate the testing?

Recently, Matt Oswalt announced ToDD (Testing On Demand: Distributed), an open source tool for validating network changes.

As Matt notes on his GitHub page, if you want to define the success of change, “…the only way to do that is to put your network through the same paces that the real-world does, and get detailed information back on how that test performed.”

Matt joins us to talk about test-driven automation, and to share details about the ToDD project. Also joining the conversation is Chris Young, a networking professional who’s worked with a preview of ToDD.

Links:

The Power of Test-Driven Network Automation – Keeping It Classless

Network Programmability and Automation by Jason Edelman; Scott S. Lowe; Matt Oswalt

An Introduction To ToDD – Youtube

Matt Oswalt’s Github page

kontrolissues.net – Chris Young’s Blog

Show Notes:

Part 1: Test-Driven Network Automation

* What does success look like?

* Automation without verification says to me that speed is more important than consistency and predictability – and that’s just not the case in the real world.

Part 2: ToDD

* Concepts

* Agents – runs the tests

* Groups – defines which agents run the tests

* Testruns – defines the tests

* Testlets – standardizes the tests

* Post-Test Analytics

* InfluxDB

* Graphana

Part 3: Future of ToDD and TDNA

* Maturation of ToDD itself

* Vendor platforms

* Maturation of rest of pipeline

* Automated baselines (machine learning?)

* We need to get better about not doing manual, bespoke things to our networks, including verification of changes. Automation without verification is pointless (and dangerous)

P4 is a language for programming the forwarding plane of packet-processing devices such as switches right down to the chip level, allowing network operators to customize how a device processes packets.

The goal of P4 is to enhance the flexibility of a network architecture and enable changes without having to wait for chip manufacturers or software developers to incorporate new features or protocol support.

P4 is an open-source project under the Apache 2.0 license. The code is maintained by the P4 consortium, which was started by Nick McKeown at Stanford University and Jennifer Rexford at Princeton University.

Our guest today to drill into the weeds about P4 is Professor McKeown. He’s been involved in several advances in networking technology over the last two decades. In particular, Nick has been a key driver of Software Defined Networking, and was a co-founder of Nicira Networks, which became VMware NSX. He is a full professor in Computer Science at Stanford University.

Links:

P4.org

Let’s get started (A blog from Jennifer Rexford and Nick McKeown introducing P4)

P4: Programming Protocol-Independent Packet Processors (Whitepaper)

Programming Protocol-Independent Packet Processors (Slide presentation by Jennifer Rexford)

This episode of Priority Queue, sponsored by Aruba, a Hewlett Packard Enterprise company, explores the ongoing evolution of the digital workplace.

As wireless networking has become both reliable and preferred by users, the next step is to fully utilize this network.

The explosion of mobile and IoT devices are transforming the way we communicate and consume services. Mobility changes the very nature of our work environments, where collaborative open spaces and non-routine schedules are becoming the norm.

Ozer Dondurmacioglu, Product Marketing Lead at Aruba, joins the Packet Pushers to talk about  how Aruba is helping IT networking teams can get ready for the digital workplace with the announcement of new products and solutions, including Aruba ClearPass for secure remote access.

This podcast was recorded at the Aruba Atmosphere Conference in 2016.

Links:

Policy management with Aruba ClearPass

Unified wired and wireless network infrastructure from Aruba

Network management with Aruba AirWave

Mobile engagement with Aruba Meridian

Wi-Fi analytics with Aruba ALE