This is the first in a series of blog posts that examine the topic of fully programmable data pipelines and their potential to transform the network visibility industry. Within this series we will be discussing what a programmable pipeline actually is, how solutions built with programmable pipelines differ from what has been available on the market, and the advantages organizations stand to gain by adopting such solutions.
Before we begin, it is important to note that programmable pipelines are here today due to a key innovation made in the networking switch world- the development of a programmable ASIC/chip. This new chip, along with the open source language used to program the chip, have allowed a new breed of network visibility solutions to emerge. These solutions are dramatically different than legacy network packet brokers- solutions which are built using static, fixed-function ASICs.
Throughout this blog series we will make sure to cover the differences between these two solutions, as well as highlight the advanced visibility functions that are now available to users for the first time thanks to fully programmable data pipelines.
The network packet broker (NPB) industry has experienced quite a few changes over the past fifteen years. NPBs may have started out as vendor specific, purpose-built appliances with limited use cases, but today we find ourselves with options available that are fundamentally different in both form and function.
Don’t get me wrong, these solutions are still serving the primary role of what NPB’s are meant to do- distribute traffic between networks and follow-on tools & analytics- but we have seen advancements in the greater IT industry bleed through to the packet broker market which have led to the arrival of some unique solutions. As Marc Andreessen put it “software is eating the world,” and software is making its mark on network packet brokers with new, advanced capabilities that provide more efficiency, help manage overlapping services across other tools, introduce functions that couldn’t previously be done and increase operational value, as we’ll explain.
The de-coupling of software from hardware
For example, control plane management was once an esoteric function accessible via vendor providers and their proprietary access methods. The control plane can now be leveraged and managed to develop distributed visibility fabrics that can be centrally managed by an SDN controller thanks to hardware and software de-coupling. The decoupling of software from hardware and the continued evolution of software management functions, over the past 15 years, has led us to the point now where most NPB vendors have “whitebox friendly” options available for their customers. These same advancements have helped NPB vendors develop more software centric models/product offerings that are able to operate within cloud environments. Couple that with the big cloud vendors like Amazon finally opening the kimono a bit and providing more direct access to lower layers of their IT stack (thank you VPC mirroring!) and the result is officially a workable solution for cloud visibility.
Simply put, software-enabled NPBs today provide users with a much more flexible deployment model and can provide visibility across network resources regardless if the resources are based on-prem or in the cloud. NPBs today can also do so much more in terms of the functions they can perform, as opposed to what was the art of the possible back in the days of the original NPBs. Intelligent filtering, hash-based load balancing, in-line security capabilities, API accessibility- these features were once a pipe dream for many but are now considered table stakes for any NPB. Given the headway the NPB market has made over the years, one may think that we have reached a plateau of sorts. Sure, speeds and port density will always be moving in a favorable direction, but what more can network packet brokers really do?
New functions come to network packet brokers; first some history
I am happy to say the answer is “so much more”…and this is due to the emergence of fully programmable data pipelines. MantisNet has been able to leverage the emergence of programmable network switch ASICs (courtesy of Barefoot TofinoTM Ethernet switch ASICs), along with a programming language (P4) designed to manage those chips, in order to expand the possibilities of what a network visibility solution can accomplish. The real power in this approach is that the technology completely opens up access to the data plane. You now have direct access to all pieces of header information, as well as the parse graphs themselves, and can affect change on network packets in an interesting way as a result.
To better understand fully programmable data pipelines, let’s break this down into a simple block diagram that goes over how a network packet is processed when passing through a network visibility solution. Essentially you have three pieces to this diagram: the parser, the match-action unit, and the deparser. This terminology/logical segmentation came about with the emergence of programmable pipelines, but all network packet brokers (aka solutions build with fixed function, traditional ASICs) must accomplish these three stages of processing to serve as a successful intermediary between network traffic and analytic/monitoring tools.
Historically, these three stages have been completely defined by the manufacturer of the NPB's chipset, regardless if the hardware is proprietary or a whitebox switch. Essentially, the chip manufacturer determines exactly what is possible across all three stages at the time that the chip is released and put out into the market. So, what happens if there is a new network protocol that the chip is unable to identify in the “parser” stage of this pipeline? The result is that the device will not have visibility into those packets, and the data will be dropped (and you likely will not even be aware of that packet dropping; losing visibility into what’s going on in your network). You’re then at the mercy of the vendor’s NPB development cycle: hopefully the manufacturer will add that protocol in its next chip release x months from now, but who can be certain?
This fault in traditional fixed-function ASIC-based NPBs extends outside of just falling short on fringe examples of new network protocols. What if we are trying to monitor 100G network traffic? 100G traffic is notorious for being heavily encapsulated, with additional headers included that are not normally found at lower speeds and are often found in differing (or multiple) locations of the header structure. Once again, if the fixed-function chip was not built with the logic to handle this type of data at the time the silicon was manufactured, then you are unfortunately SOL.
This is where the extreme power of programmable chips (the foundation of fully programmable data pipelines) comes in to play. Unlike a traditional ASIC, the logic of what the chip can accomplish is not cemented into the silicon itself by the chip designer. It has now moved up into the software developer space and can be pushed into the chip through a programmable language.
We have now moved from a mentality of the chip dictating what a solution can achieve, to one where a vendor can more easily program the solution to achieve specific functionality based upon the client’s unique needs. Most importantly these changes to the functionality of the solution can now be quickly implemented via an over-the-air software update versus protracted development and release cycles of traditional fixed-function ASIC manufacturers (not to mention forklift upgrades). This is a powerful change in dynamics that results in a profound impact to what a network visibility solution can achieve not only today, but also further down the road as new ways of thinking are explored.
I asked our CTO, Elliott Starin, to pull together a few bullet points to list just exactly what a solution like MantisNet’s Reconfigurable Frame Processor - Next Generation (RFP-NG) can accomplish, that a traditional packet broker cannot. He was glad to school me on the specifics of the value a fully programmable data pipeline brings to users, and this list of benefits that can be achieved. In the next blog posts in this series we’ll dive deeper into these advanced capabilities.
You can read more about our list of advanced functions made possible with fully programmable data pipeline in our 'Can your packet broker do this?' series:
- Complex parsing / identifying unknown packets / de-parsing of packets
- Identify packets that don't match existing header definitions and parse graph (e.g. packets that don't parse) and direct packets out to a follow-on system for reverse engineering and further characterization
- Unique header / network overlay stripping capabilities (multiple VLANs, 802.1aq)
- Can hash and load balance based on innermost IP information in complex packet formats
- Can generate time-series data metrics for all applied ACLs (via ONT)
- Ability to set ACLs (filters) and generate octets and packet stats natively
- Cloud native instrumentation via Prometheus and Grafana
- INT (in-band network telemetry): ability to insert metadata headers with specific data of interest
- ONT (out-of-band network telemetry): ability to export metadata with specific data of interest
- Software-based, extensible, architecture; dynamic addition of protocols for full programmability of the pipeline
Learn more about adopting a fully programmable data pipeline with MantisNet’s RFP-NG.
