Welcome!

Microservices Expo Authors: Pat Romanski, Dalibor Siroky, Stackify Blog, Elizabeth White, Liz McMillan

Related Topics: SDN Journal, Microservices Expo, Containers Expo Blog, @CloudExpo, Cloud Security

SDN Journal: Blog Post

Overlay Entropy

A Plexxi solution provides an optimized L1, L2 and L3 network

There have been many articles describing overlay networks in the past few quarters. It's a relatively straightforward concept, not far removed from some of the older VPN technologies very popular a while ago. The actual transport of packets is probably the simplest, it is the control plane that is much harder to construct and therefore explain. It is therefore also that the control plane in overlay networks has seen the most innovation and change, and is likely to change some more in standard and proprietary ways in the next little while. A perfect example is the use of IP Multicast for unknown, multicast and broadcast traffic as defined in the latest IETF draft for VXLAN, but controller implementations try and avoid IP Multicast as part of the necessary data path. Which will continue to lead to changes in the control plane for learning, distribution of destinations, etc.

A Plexxi solution provides an optimized L1, L2 and L3 network. With the advent of overlay networks, the relationship and interaction between the physical, L2 and L3 network and the overlay infrastructure is important to understand. We strongly believe the control and data planes should be interconnected and coordinated/orchestrated. In this and next week’s blog, I will describe some key touch points of the two at the data plane: entropy as a mechanism to discern flow like information and the role and capabilities of a hardware gateway.

I looked at VXLAN, NVGRE and STT as the major overlay encapsulations. VXLAN and STT are very much driven by VMWare, with STT used as the tunnel encapsulation between vSwitch based VXLAN Tunnel End Points (VTEP), VXLAN used as the tunnel encapsulation to external entities like gateways. NVGRE of course is the tunnel protocol of choice for Microsoft’s overlay solution and very similar to to previous GRE based encapsulations. All encapsulations are IP based, allowing the tunnels to be transported across a basic IP infrastructure (with the above mentioned note for IP Multicast). VXLAN and NVGRE are packet based mechanisms, each original packet ends up being encapsulated into a new packet.

VXLAN is build on top of UDP. As shown below, an encapsulated ethernet packet has 54 bytes of new header information added (assuming it is being transported again over ethernet). The first 18 bytes contain the ethernet header containing the MAC address of the source VTEP and its next IP destination, most likely the next IP router/switch. This header changes at each IP hop. The next 20 bytes contain the IP header. The protocol is set to 17 for UDP. The source IP address is that of the originating VTEP, the destination IP address that of the destination VTEP. The IP header is followed by 8 bytes of UDP header containing source UDP port, destination UDP port (4789) and the usual UDP length and checksum fields. While formatted in a normal way, the UDP source port is used in a special way to create “entropy”, explained in more detail below.

VXLAN Packet Format2

A VXLAN Encapsulated Ethernet Packet

Following the UDP header is the actual 8 byte VXLAN header. Just about all fields except the 24 bit VXLAN Network Identifier (VNI) are reserved and set to zero. The VNI is key, it determines which VXLAN the original packet belongs to. When the destination VTEP receives this packet and decapsulates it, it will use this to find the right table to use for MAC address lookups of the original packet to get it to its destination. Only the original packets (shown with Ethernet headers above) follows the VXLAN header. For every packet sent out by a VM, VXLAN adds 54 bytes of new tunnel headers between the source and destination VTEP. Intermediate systems do all their forwarding based on this new header: ethernet switches will use the Outer Ethernet header, IP routers will use the Outer IPv4 header to route this packet towards its destination. Each IP router will replace the Outer Ethernet header with a new one representing itself as the source, and the next IP router as the destination.

NVGRE packets look very similar to VXLAN packets. The initial Outer Ethernet header is the same as VXLAN, representing the source tunnel endpoint and the first IP router as the source and destination. The next 20 bytes of IP header are also similar to VXLAN, except that the protocol is 47 for GRE. NVGRE encodes the Virtualized LAN (Virtual Subnet ID or VSID in NVGRE terms) inside the GRE header, using 24 bits of the original GRE Key field to represent the VSID, leaving 8 bits for a FlowID field, which serves a similar entropy function as the UDP source port for VXLAN, explain further below. The VSID in NVGRE and VNI in VXLAN represent the overlay virtual network ID for each of the technologies. Following the GRE header, the original (Ethernet) packet. NVGRE added 46 bytes of new header information to existing packets.

NVGRE Packet Format2

A NVGRE Encapsulated Ethernet Packet

As I mentioned in last week’s blog, a tunnel endpoint is an aggregation point and as a result, all of the individual flows that are put into a specific VTEP to VTEP tunnel go through the transport network based on the new headers that have been added. Many networks rely on some form of L2 or L3 ECMP to use all available bandwidth between any two points on the network, spine and leaf networks being the prime example of an absolute dependency on a very well functioning ECMP to perform at its best. Without discussing the virtues of ECMP again, tunneled packets need something in the new header that allows an hash calculation to make use of multiple ECMP paths. With pretty much all of the L2 and L3 header identical (except for the VNI or VSID) for all traffic between two tunnel endpoints, the creators of these encapsulations have been creative in encoding entropy in these new headers so that hash calculations for these headers can be used to place traffic onto multiple equal cost paths.

For VXLAN, this entropy is encoded in the UDP source port field. With only a single UDP VXLAN connection between any two endpoints allowed (and necessary), the source port is essentially irrelevant and can be used to mark a packet with a hash calculation result that in effect acts as a flow identifier for the inner packet. Except that it is not unique. The VXLAN spec does not specify exactly how to calculate this hash value, but its generally assumed that specific portions of the inner packet L2, L3 and/or L4 header are used to calculate this hash. The originating VTEP calculates this, puts it in the new UDP header as the source port, and it remains there unmodified until it arrives at the receiving VTEP. Intermediate systems that calculate hashes for L2 or L3 ECMP balancing typically use UDP ports as part of their calculation and as a result, different inner packet flows will result in different placement onto ECMP links. As mentioned, intermediate routers or switches that transport the VXLAN packet do not modify the UDP source port, they only use its value in their ECMP calculation.

NVGRE is fairly similar. GRE packets have no TCP or UDP header, and as a result network hardware typically has the ability to recognize these packets as GRE and use the 32-bit GRE key field as an information source in their ECMP calculations. GRE tunnel endpoints encode inner packet flows with individual (but not necessarily unique) key values, and as a result, intermediate network systems will calculate different hash results to place these inner packet flows onto multiple ECMP links. NVGRE has taken 24 of these bits to encode the VSID, but has left 8 bits to create this entropy at the tunnel endpoint, the field has been renamed FlowID. The VSID and FlowID combined will be used to calculate hashes for ECMP link placement. A possible challenge is that for networks that have many many flows inside a VSID between two specific NVGRE endpoints, the 8 bits worth of differentiation may not create a “normal” ECMP distribution.

While the packet formats have been constructed to ensure that the “normal” tools of entropy can be used for ECMP and LAG by existing switching hardware, the latest hardware platforms have the ability to look well beyond the outer headers. Many bits and pieces of the new headers can be examined and decisions can be made on them. While specific switching ASICs will have slightly different tools, the latest generations of them have he ability to look at VNI and VSID even when not acting as a gateway, and packet modification or forwarding decisions can be made on their value. Inner MAC and IP headers can also be examined and acted on, with a bit more complexity. Switching ASICs are built to have quick access to the most important fields to make decisions on, access to less common fields is there, but requires some manual construction by those that program the ASIC (the networking vendors).

When the switching platform is configured to be a gateway to provide bridging functions between regular VLANs and the tunneled VXLAN or NVGRE infrastructure, the ASIC has access to the entire original packet, since it actively encapsulates or decapsulates the original packet. That gives the switch decision choices very similar to a vSwitch, but at a smaller scale. More detail on the gateway function and STT next week.

The post Overlay Entropy appeared first on Plexxi.

Read the original blog entry...

More Stories By Marten Terpstra

Marten Terpstra is a Product Management Director at Plexxi Inc. Marten has extensive knowledge of the architecture, design, deployment and management of enterprise and carrier networks.

@MicroservicesExpo Stories
While some developers care passionately about how data centers and clouds are architected, for most, it is only the end result that matters. To the majority of companies, technology exists to solve a business problem, and only delivers value when it is solving that problem. 2017 brings the mainstream adoption of containers for production workloads. In his session at 21st Cloud Expo, Ben McCormack, VP of Operations at Evernote, discussed how data centers of the future will be managed, how the p...
The nature of test environments is inherently temporary—you set up an environment, run through an automated test suite, and then tear down the environment. If you can reduce the cycle time for this process down to hours or minutes, then you may be able to cut your test environment budgets considerably. The impact of cloud adoption on test environments is a valuable advancement in both cost savings and agility. The on-demand model takes advantage of public cloud APIs requiring only payment for t...
It has never been a better time to be a developer! Thanks to cloud computing, deploying our applications is much easier than it used to be. How we deploy our apps continues to evolve thanks to cloud hosting, Platform-as-a-Service (PaaS), and now Function-as-a-Service. FaaS is the concept of serverless computing via serverless architectures. Software developers can leverage this to deploy an individual "function", action, or piece of business logic. They are expected to start within milliseconds...
As DevOps methodologies expand their reach across the enterprise, organizations face the daunting challenge of adapting related cloud strategies to ensure optimal alignment, from managing complexity to ensuring proper governance. How can culture, automation, legacy apps and even budget be reexamined to enable this ongoing shift within the modern software factory? In her Day 2 Keynote at @DevOpsSummit at 21st Cloud Expo, Aruna Ravichandran, VP, DevOps Solutions Marketing, CA Technologies, was jo...
You know you need the cloud, but you’re hesitant to simply dump everything at Amazon since you know that not all workloads are suitable for cloud. You know that you want the kind of ease of use and scalability that you get with public cloud, but your applications are architected in a way that makes the public cloud a non-starter. You’re looking at private cloud solutions based on hyperconverged infrastructure, but you’re concerned with the limits inherent in those technologies.
Is advanced scheduling in Kubernetes achievable?Yes, however, how do you properly accommodate every real-life scenario that a Kubernetes user might encounter? How do you leverage advanced scheduling techniques to shape and describe each scenario in easy-to-use rules and configurations? In his session at @DevOpsSummit at 21st Cloud Expo, Oleg Chunikhin, CTO at Kublr, answered these questions and demonstrated techniques for implementing advanced scheduling. For example, using spot instances and co...
The cloud era has reached the stage where it is no longer a question of whether a company should migrate, but when. Enterprises have embraced the outsourcing of where their various applications are stored and who manages them, saving significant investment along the way. Plus, the cloud has become a defining competitive edge. Companies that fail to successfully adapt risk failure. The media, of course, continues to extol the virtues of the cloud, including how easy it is to get there. Migrating...
For DevOps teams, the concepts behind service-oriented architecture (SOA) are nothing new. A style of software design initially made popular in the 1990s, SOA was an alternative to a monolithic application; essentially a collection of coarse-grained components that communicated with each other. Communication would involve either simple data passing or two or more services coordinating some activity. SOA served as a valid approach to solving many architectural problems faced by businesses, as app...
Some journey to cloud on a mission, others, a deadline. Change management is useful when migrating to public, private or hybrid cloud environments in either case. For most, stakeholder engagement peaks during the planning and post migration phases of a project. Legacy engagements are fairly direct: projects follow a linear progression of activities (the “waterfall” approach) – change managers and application coders work from the same functional and technical requirements. Enablement and develo...
Gone are the days when application development was the daunting task of the highly skilled developers backed with strong IT skills, low code application development has democratized app development and empowered a new generation of citizen developers. There was a time when app development was in the domain of people with complex coding and technical skills. We called these people by various names like programmers, coders, techies, and they usually worked in a world oblivious of the everyday pri...
From manual human effort the world is slowly paving its way to a new space where most process are getting replaced with tools and systems to improve efficiency and bring down operational costs. Automation is the next big thing and low code platforms are fueling it in a significant way. The Automation era is here. We are in the fast pace of replacing manual human efforts with machines and processes. In the world of Information Technology too, we are linking disparate systems, softwares and tool...
DevOps is good for organizations. According to the soon to be released State of DevOps Report high-performing IT organizations are 2X more likely to exceed profitability, market share, and productivity goals. But how do they do it? How do they use DevOps to drive value and differentiate their companies? We recently sat down with Nicole Forsgren, CEO and Chief Scientist at DORA (DevOps Research and Assessment) and lead investigator for the State of DevOps Report, to discuss the role of measure...
DevOps is under attack because developers don’t want to mess with infrastructure. They will happily own their code into production, but want to use platforms instead of raw automation. That’s changing the landscape that we understand as DevOps with both architecture concepts (CloudNative) and process redefinition (SRE). Rob Hirschfeld’s recent work in Kubernetes operations has led to the conclusion that containers and related platforms have changed the way we should be thinking about DevOps and...
"As we've gone out into the public cloud we've seen that over time we may have lost a few things - we've lost control, we've given up cost to a certain extent, and then security, flexibility," explained Steve Conner, VP of Sales at Cloudistics,in this SYS-CON.tv interview at 20th Cloud Expo, held June 6-8, 2017, at the Javits Center in New York City, NY.
These days, APIs have become an integral part of the digital transformation journey for all enterprises. Every digital innovation story is connected to APIs . But have you ever pondered over to know what are the source of these APIs? Let me explain - APIs sources can be varied, internal or external, solving different purposes, but mostly categorized into the following two categories. Data lakes is a term used to represent disconnected but relevant data that are used by various business units wit...
With continuous delivery (CD) almost always in the spotlight, continuous integration (CI) is often left out in the cold. Indeed, it's been in use for so long and so widely, we often take the model for granted. So what is CI and how can you make the most of it? This blog is intended to answer those questions. Before we step into examining CI, we need to look back. Software developers often work in small teams and modularity, and need to integrate their changes with the rest of the project code b...
"I focus on what we are calling CAST Highlight, which is our SaaS application portfolio analysis tool. It is an extremely lightweight tool that can integrate with pretty much any build process right now," explained Andrew Siegmund, Application Migration Specialist for CAST, in this SYS-CON.tv interview at 21st Cloud Expo, held Oct 31 – Nov 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA.
"Cloud4U builds software services that help people build DevOps platforms for cloud-based software and using our platform people can draw a picture of the system, network, software," explained Kihyeon Kim, CEO and Head of R&D at Cloud4U, in this SYS-CON.tv interview at 21st Cloud Expo, held Oct 31 – Nov 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA.
Kubernetes is an open source system for automating deployment, scaling, and management of containerized applications. Kubernetes was originally built by Google, leveraging years of experience with managing container workloads, and is now a Cloud Native Compute Foundation (CNCF) project. Kubernetes has been widely adopted by the community, supported on all major public and private cloud providers, and is gaining rapid adoption in enterprises. However, Kubernetes may seem intimidating and complex ...
DevOps is often described as a combination of technology and culture. Without both, DevOps isn't complete. However, applying the culture to outdated technology is a recipe for disaster; as response times grow and connections between teams are delayed by technology, the culture will die. A Nutanix Enterprise Cloud has many benefits that provide the needed base for a true DevOps paradigm. In their Day 3 Keynote at 20th Cloud Expo, Chris Brown, a Solutions Marketing Manager at Nutanix, and Mark Lav...