Packet Pushers - Priority Queue

The Open Compute Project (OCP) describes itself as “…reimagining hardware, making it more efficient, flexible, and scalable. Join our global community of technology leaders working together to break open the black box of proprietary IT infrastructure to achieve greater choice, customization, and cost savings.”

Started by mostly large organizations with massive buying power (including Facebook), it might be easy to dismiss OCP as a project for other folks. But the OCP is starting to affect the market in many areas, including networking.

To catch us up on what the OCP Networking Project is up to, co-chair Carlos Cardenas sits down with the Packet Pushers. Carlos has written some of the most outspoken articles on PacketPushers.net, having zero trouble speaking his mind, so this will be an interesting episode.

We’ll talk about why networking was added to OCP, its efforts around designs for data center leaf and spine switches, what’s come out of the project to date, and what efforts are being targeted at the campus, including access switches and wireless APs.

Show Links:

Open Compute Wiki On Networking

OCP Networking Specs And Designs

Open Compute Mailing List

Carlos Cardenas On Twitter

Carlos’s Posts On Packet Pushers

In the beginning, there was SNMP with its MIBs and OIDs. And then there was rrdtool, MRTG, and cacti, graphing our little OID values for us in a symphony of contextless images. They looked impressive, but tended not to tell us much.

Network monitoring has evolved, and network monitoring tools along with it. Our sponsor today, Paessler, is here to discuss good and bad monitoring practices, and just how they’ve kept up with the times.

Joining Greg and Ethan, from Paessler is Greg Ross, Senior Systems Engineer. We’ll get an update on Paessler’s PRTG Network Monitor, talk about how to do monitoring right in complex networks, and how to get actionable information from disparate data points.

We’ll also talk about how to identify signs of trouble before something breaks, and get tips for working in cloud environments.

Special Offer

And Paessler has a special offer for Packet Pushers listeners: get a free network consultation when you download and install a free trial of PRTG Network Monitor. Get details and sign up here!

You can also follow Paessler on Twitter, LinkedIn, and Facebook.

Today’s show was recorded live at VMware’s Future:Net conference 2016 in Las Vegas. Greg Ferro and Ethan Banks talk with Bruce Davie, CTO, Networking at VMware; and Simon Crosby, CTO and co-founder of Bromium, about the future of security in the context of networking.

The discussion looks at security both on and between end points, and how much security can be done in the network. Do middleboxes still have a roll to play? Are there other ways to get end-to-end security? Is the endpoint the best place to protect the organization?

We also look at advances in attacker techniques, why it’s nearly impossible for the enterprise to defend its boundaries, and how microsegmentation affects the security picture.

Join us for a lively discussion with two technology luminaries about where security is going and the network’s role.

5G networks are still a ways out from deployment, but the technology will dramatically boost the capability of mobile networks by providing 1Gbps of bandwidth and lower latency, and by taking advantage of a wider spectrum range.

Besides mobility and wireless, 5G will likely have a significant impact on industrial networks, IoT, and cloud computing.

On today’s sponsored Priority Queue, we talk with Intel about 5G technology, how it works, business use cases, and its potential impact on the enterprise. We also discuss Intel’s efforts to bring 5G-enabled products to market. Our guest is Caroline Chan, Director, Wireless Access Strategy and Technology, at Intel’s Network Platform Group.

This podcast was recorded live at the Intel Developer Forum 2016 in San Francisco.

Links:

Network Transformation Is Laying the Groundwork for 5G – Intel

A Look Ahead…The Network Of 2020 and Beyond – Intel

5G Technology Overview – Intel

A 5G Network is Possible Now on Intel Architecture – Intel

Paving the Road to 5G Mobile Services – Intel

How 5G Will Power the Future Internet of Things – Intel IQ

Powering 5G Network Infrastructure with Intel Technologies – Intel

This Priority Queue episode was recorded live at the IETF 96 meeting in Berlin, Germany in July 2016. The discussion focuses on the IETF working group I2RS (Interface to the Routing System).

According the charter, I2RS “facilitates real-time or event driven interaction with the routing

system through a collection of protocol-based control or management interfaces. These allow information, policies, and operational parameters to be injected into and retrieved (as read or by notification) from the routing system while retaining data consistency and coherency across the routers and routing infrastructure, and among multiple interactions with the routing system.”

Greg is joined by two guests to explore how I2RS works and its benefits. First is Sue Hares, a co-chair of the I2RS working group. She’s also a consultant at Hickory Hill Consulting and an expert on routing.

Also joining the conversation is Russ White, a network architect and frequent Packet Pushers guest.

The Priority Queue dives deep today, with a discussion of using EVPN as an enterprise data center interconnect. This is not a feel-good, fluffy podcast about how nice EVPN is and the fun things we someday hope to be able to do with it. Rather, this show gets right into the weeds on EVPN with the specific use-case of DCI.

Join Ethan Banks as he interviews double JNCIE Clay Haynes on setting up BGP adjacencies, creating EVPN address families, interpreting BGP output containing EVPN NLRIs, handling VTEPs, walking a packet through end to end, and useful commands to know.

More about EVPN?

* Show 196 – EVPN Introduction & Use-Cases With Russ White + Jeff Tantsura

* Show 233 – Cisco Nexus Using BGP As A VXLAN Control Plane – Sponsored

* EVPN: Intro To Next Gen L2VPN

Other resources.

* MPLS in the SDN Era

* Rick Mur’s Blog – EVPN (RFC7432) Explained and EVPN Configuration

* Dan Houtz – Configuring EVPN on Juniper QFX

Want to follow Clay?

* Twitter: @dark_15

* LinkedIn: dark1587

* Blog: http://alostrealist.com

Show Notes:

Section 1 – What is EVPN?

VPN – not IPSEC, but a virtual private network nonetheless.

Provides L2 or integrated L2+L3 VPN.

Implemented in the control plane using multiprotocol BGP.

Implemented in the data plane with your choice of…

MPLS

Overlay such as VXLAN

Provider Backbone Bridging (PBB)

Section 2 – What is EVPN good for in the real world?

In a nutshell, it carries entire Ethernet frames across an L3 infrastructure.

When using MP-BGP as a control plane, MAC addresses are advertised between BGP peers.

A major use case for this is DCI.

Stretching L2 between data centers is a design problem that needs special handling to implement safely.

Extending failure domain of STP.

Sub-optimal FHRP = traffic trombone.

EVPN handles some of these stretched L2 issues.

What vendors support EVPN on what platforms?

Cisco

Juniper

Other

Section 3 – Let’s implement EVPN as an enterprise DCI.

First, some terms.

Ethernet segment

Ethernet tag

Ethernet segment identifier

EVPN Instance (EVI)

Then, some components

EVPN overlay format of NVO.

VXLAN tunnels & VTEPs

MP-BGP peers sharing EVPN data

MACs

VNIDs

Packet walk time! I’ve got these two endpoints on the same stretched L2 segment that need to talk to each other, separated by L3 infrastructure…

Lessons learned.

Architecture traps to avoid.

Redundancy concerns.

Troubleshooting tips.

Reading the BGP table.

Useful commands to know.

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