Community hub
0 subscribers7 pages, 0 posts
Recent from talks
All channels
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Welcome to the community hub built to collect knowledge and have discussions related to Generic Network Virtualization Encapsulation.
Nothing was collected or created yet.
Generic Network Virtualization Encapsulation
View on Wikipediafrom Wikipedia
Generic Network Virtualization Encapsulation (Geneve) is a network encapsulation protocol created by the IETF in order to unify the efforts made by other initiatives like VXLAN and NVGRE,[1] with the intent to eliminate the wild growth of encapsulation protocols.[1][2]
Open vSwitch is an example of a software-based virtual network switch that supports Geneve overlay networks. It is also supported by AWS Gateway Load Balancers.
References
[edit]- ^ a b J. Gross; I. Ganga; T. Sridhar, eds. (November 2020). Geneve: Generic Network Virtualization Encapsulation. Internet Engineering Task Force. doi:10.17487/RFC8926. ISSN 2070-1721. RFC 8926. Proposed Standard.
- ^ "Intel Supports Geneve to Help Unify VXLAN & NVGRE". sdxcentral.com. Retrieved 2020-04-03.
 | This computer networking article is a stub. You can help Wikipedia by adding missing information. |
Generic Network Virtualization Encapsulation
View on Grokipediafrom Grokipedia
Overview
Definition and Purpose
Generic Network Virtualization Encapsulation (GENEVE) is an IETF standards-track protocol that encapsulates inner network packets, such as Ethernet frames, within outer UDP/IP packets to enable virtual network overlays on physical underlay networks.[2] This tunneling mechanism operates over UDP port 6081, providing a standardized transport for virtualized traffic across diverse infrastructures.[2] The primary purpose of GENEVE is to offer a flexible and extensible framework for network virtualization that supports the inclusion of metadata beyond basic tenant isolation, thereby addressing the fragmentation caused by multiple proprietary or limited encapsulation protocols.[2] By design, it accommodates evolving requirements in control planes and hardware capabilities without necessitating frequent protocol revisions, promoting interoperability in dynamic environments.[2] In network virtualization, GENEVE serves as a common backplane interconnecting virtual switches, hypervisors, and physical switches in data centers, facilitating multi-tenancy through virtual network identifiers and enabling workload mobility across distributed systems.[2] It integrates seamlessly with software-defined networking (SDN) by abstracting virtual topologies from the underlying physical hardware, allowing operators to manage overlays independently of transport details.[2] This protocol emerged in response to the surge in virtualization demands during the post-2010s cloud computing era, where the rapid adoption of technologies like virtual machines and containers led to a proliferation of encapsulations such as VXLAN and NVGRE, each with inherent limitations like fixed identifier spaces.[2] GENEVE unifies these efforts under a single, adaptable standard to mitigate protocol silos and enhance scalability in large-scale virtualized deployments.[2]Key Features
GENEVE provides extensibility through variable-length options encoded in a Type-Length-Value (TLV) format, enabling the inclusion of up to 252 bytes of metadata (resulting in a total header size of up to 260 bytes) for custom fields such as security tags or policy information.[3] This design allows network operators to adapt the protocol to evolving requirements without altering the core encapsulation structure.[4] The protocol features a compact fixed header of only 8 bytes, optimized for efficient hardware processing, which includes a version field set to 0 (Ver=0), a 6-bit option length indicator, and a 24-bit Virtual Network Identifier (VNI) for tenant isolation.[3] This minimal header size reduces overhead in high-throughput environments while maintaining essential identification capabilities.[5] GENEVE operates independently of any specific control plane, with the data plane dedicated solely to forwarding decisions, while the extensible metadata supports integration with software-defined networking (SDN) controllers without necessitating protocol modifications.[6] Additionally, it includes an O bit to indicate control packets containing control messages and a Critical option bit (C bit) to denote the presence of mandatory options that must be processed, ensuring robust handling of complex topologies.[3][7] For load balancing, GENEVE leverages entropy through UDP source port randomization, derived from hashing elements of the encapsulated packet headers, to facilitate even distribution across Equal-Cost Multi-Path (ECMP) forwarding fabrics.[8] This mechanism enhances scalability in large-scale data centers. GENEVE also unifies capabilities from earlier protocols like VXLAN, allowing coexistence and gradual migration.[9]History and Development
Initial Proposal
The initial proposal for Generic Network Virtualization Encapsulation (GENEVE) emerged in early 2014 as an individual Internet-Draft submitted to the Internet Engineering Task Force (IETF), authored by Jesse Gross and T. Sridhar from VMware, Pankaj Garg from Microsoft, Chris Wright from Red Hat, and Ilango Ganga from Intel.[10] This draft, titled "Geneve: Generic Network Virtualization Encapsulation," outlined a new tunneling protocol aimed at addressing limitations in existing network virtualization overlays. The proposal was motivated by the rapid evolution of software-defined networking (SDN) and network function virtualization (NFV), which demanded more adaptable encapsulation methods to support diverse hardware and software ecosystems in data center environments.[10] A primary driver for GENEVE's development was the fragmentation in the encapsulation landscape, exemplified by earlier protocols such as Network Virtualization using Generic Routing Encapsulation (NVGRE), proposed in 2011, and Virtual eXtensible Local Area Network (VXLAN), introduced in 2012. These protocols, while effective for basic tenant isolation using fixed identifiers like 24-bit VXLAN Network Identifiers (VNIs), lacked sufficient flexibility for carrying additional metadata required by advanced SDN controllers and NFV services, leading to potential obsolescence as network architectures evolved.[10] The GENEVE authors sought to mitigate this by designing a protocol that could accommodate varying device capabilities without necessitating frequent redesigns.[10] The early goals of GENEVE emphasized creating an extensible framework protocol to future-proof network virtualization against hardware and control plane changes, with an initial emphasis on UDP-based encapsulation to leverage IP fabrics as a scalable underlay.[10] This approach allowed for the inclusion of variable-length options to transport system state and metadata beyond simple identifiers, promoting interoperability across heterogeneous environments.[10] By focusing on a generic structure, the proposal aimed to unify overlay networks in a way that supported the growing demands of virtualized infrastructures.[10] Following iterations of the individual draft, GENEVE was adopted into the NVO3 working group in 2015, marking its progression toward standardization within the IETF framework for network virtualization overlays.[11] This adoption laid the groundwork for further refinement, culminating in its publication as RFC 8926 in 2020.[12]Standardization Process
The standardization of Generic Network Virtualization Encapsulation (GENEVE) began with its entry into the IETF's Network Virtualization Overlays (NVO3) Working Group in 2015, where it was submitted as draft-ietf-nvo3-geneve-00.[11] This marked the transition from an individual submission to a collaborative effort within the WG to refine the protocol for broader adoption. The draft underwent multiple revisions, from -00 in May 2015 to -15 in February 2020, incorporating feedback on critical aspects such as security considerations (e.g., integration with IPsec and DTLS), extensibility through variable-length options, and interoperability across diverse network environments.[13] These iterations addressed reviews from areas like SECDIR and TSVART, ensuring robust handling of transit device processing and option namespaces.[13] Key milestones included WG last call in 2019, and subsequent IESG evaluation leading to publication as RFC 8926 on November 6, 2020, with authors J. Gross, I. Ganga, and T. Sridhar.[12] The RFC specifies GENEVE as a standards-track protocol for network virtualization encapsulation.[12] As part of the standardization, IANA registered UDP port 6081 for GENEVE in 2014 (confirmed in the RFC) and established the Geneve Option Class registry, with IETF-defined classes in the range 0x0000-0x00FF allocated via IETF Review.[14][12] By 2025, no major revisions to RFC 8926 have been issued, reflecting the protocol's stability post-publication.[15]Technical Details
Encapsulation Mechanism
The encapsulation mechanism of Generic Network Virtualization Encapsulation (GENEVE) involves wrapping an inner packet, such as an Ethernet frame, within a series of headers to enable tunneling over IP networks. The process begins with the inner packet, which represents the original data unit from a virtual network tenant. This is followed by the addition of the GENEVE header, a compact 8-byte fixed structure that includes essential control fields. Next, variable-length options may be appended for metadata, after which a UDP header is added, with the destination port set to 6081 as assigned by IANA for GENEVE traffic. The source port in the UDP header is selected by the encapsulating endpoint to provide entropy for load balancing mechanisms like Equal-Cost Multi-Path (ECMP) routing. Finally, an outer IP header (supporting both IPv4 and IPv6) encapsulates the UDP packet, and an optional outer Ethernet header may be included if the transport requires Layer 2 framing, such as over a physical Ethernet fabric.[2] At the receiving tunnel endpoint, decapsulation reverses this process to recover the original inner packet. Upon receipt, the endpoint first validates the GENEVE header's Version field, which must be 0; packets with unknown versions are dropped to ensure compatibility. The Option Length field is then checked to determine the position of the payload start, allowing the endpoint to skip over any options correctly. If the Critical bit is set in the header, all options must be processed; failure to understand a critical option results in packet discard. The payload is extracted based on the Protocol Type field in the GENEVE header, which identifies the inner protocol—commonly Ethertype 0x6558 for Ethernet frames, but extensible to others like IPv4 or MPLS for broader applicability. This design ensures that transit devices along the underlay network forward the packet without inspecting the inner contents, preserving encapsulation integrity.[2] GENEVE's flexibility in payload support stems from its Protocol Type field, enabling encapsulation of diverse protocols beyond just Ethernet, which facilitates integration with various network virtualization environments. A typical packet flow example involves traffic from a tenant virtual machine (VM) on one hypervisor: the inner Ethernet frame carrying the VM's data is encapsulated at the source endpoint, tunneled across a data center IP fabric (e.g., a Clos topology), and decapsulated at the destination endpoint to deliver the frame to another VM, maintaining virtual network isolation over the shared underlay.[2]Header Structure
The Generic Network Virtualization Encapsulation (GENEVE) header consists of a fixed 8-byte portion followed by optional variable-length fields, enabling flexible tunneling of network traffic over UDP.[2] The fixed header provides essential metadata for identifying virtual networks, payload types, and processing instructions, while keeping the core structure compact to minimize overhead in high-speed networks.[2] The fixed header is structured as follows, with fields aligned in a 64-bit (8-byte) layout:| Bits | Field | Description |
|---|---|---|
| 0-1 | Version (Ver) | 2 bits; set to 0 for the current version of GENEVE. Packets with unknown versions must be dropped by tunnel endpoints.[2] |
| 2-7 | Option Length (Opt Len) | 6 bits; specifies the length of the optional fields in multiples of 4 bytes (range 0-63), excluding the fixed header. This allows the header to scale up to a maximum total size of 260 bytes (8 + 63*4).[2] |
| 8 | O (OAM) bit | 1 bit; when set to 1, indicates a control packet (e.g., for operations, administration, and maintenance) that must not be forwarded by tunnel endpoints but directed to a high-priority control queue. Transit devices treat it as a regular data packet for forwarding decisions, such as equal-cost multipath (ECMP) routing, which benefits from UDP port entropy.[2] |
| 9 | C (Critical) bit | 1 bit; when set to 1, signals the presence of critical options that all tunnel endpoints must parse; failure to process them results in packet drop.[2] |
| 10-15 | Reserved (Rsvd.) | 6 bits; must be set to 0 on transmission and ignored on receipt to ensure compatibility.[2] |
| 16-31 | Protocol Type | 16 bits; identifies the type of the inner payload packet using Ethertype values (e.g., 0x0800 for IPv4, 0x6558 for Ethernet frames), providing flexibility to encapsulate various protocols directly.[2] |
| 32-55 | Virtual Network Identifier (VNI) | 24 bits; carries the virtual network ID for segmentation, supporting up to 16,777,216 (2^24) distinct virtual networks to isolate tenant traffic in multi-tenant environments.[2] |
| 56-63 | Reserved | 8 bits; must be set to 0 on transmission and ignored on receipt.[2] |
Variable Options
Generic Network Virtualization Encapsulation (GENEVE) supports extensibility through variable-length options that follow the fixed header, enabling the carriage of custom metadata in a Type-Length-Value (TLV) format. Each option consists of a 4-byte header followed by variable-length data, allowing tunnel endpoints to exchange additional information beyond the core encapsulation fields.[2] The TLV header is structured as follows: the first 16 bits represent the Option Class, which defines a namespace for the subsequent Type field to avoid collisions across different implementations; the next 8 bits are the Type field, where the most significant bit serves as the Critical (C) bit (1 for critical options, 0 for non-critical), and the remaining 7 bits specify the data format; the following 3 bits are Reserved (R) and must be set to zero; finally, the last 5 bits indicate the Length, specifying the data size in multiples of 4 bytes, ranging from 0 (no data, total option size 4 bytes) to 31 (124 bytes of data, total 128 bytes per option). The variable data field then carries the actual payload, which must be processed according to the Type. Options are 4-byte aligned, with any necessary padding added at the end of the variable-length section to ensure the inner packet starts on a 4-byte boundary.[2] Processing rules for options differ based on the C bit and the role of the device. Non-critical options (C=0) may be safely ignored by tunnel endpoints if not understood, while transit devices must forward them without modification. Critical options (C=1), however, require tunnel endpoints to either process them correctly or drop the packet if the Type is unrecognized; transit devices do not inspect or alter options and thus cannot drop based on criticality. This design ensures robust extensibility without disrupting underlay networks.[2] Options in GENEVE facilitate various use cases, such as policy enforcement for access control and service chaining, load-balancing decisions based on endpoint metadata, and the inclusion of contextual information like timestamps or security tags to aid in virtualization orchestration. For instance, an option might carry system state data to influence routing or apply fine-grained policies at the tunnel endpoint.[2] The protocol imposes limits to maintain practicality: the base header's 6-bit Opt Len field allows up to 252 bytes for the entire options section (0 to 63 units of 4 bytes), resulting in a maximum total header size of 260 bytes when added to the 8-byte fixed header; this accommodates up to 63 options if each is minimal (4 bytes), though practical deployments rarely approach this limit due to MTU constraints.[2] Option Classes are managed via an IANA registry to promote interoperability, with ranges allocated as follows: 0x0000–0x00FF for IETF Review, 0x0100–0xFEFF for First Come First Served, and 0xFF00–0xFFFF for Experimental Use. Representative registered classes include 0x0100 for Linux kernel implementations, 0x0101 for Open vSwitch, and 0x0102 for Open Virtual Network, enabling vendor-specific extensions like custom metadata handling.[16][2]Comparisons with Other Protocols
With VXLAN
VXLAN, proposed in 2012 and defined in RFC 7348, is a network virtualization encapsulation protocol featuring a fixed 8-byte header that includes an 8-bit flags field, a 24-bit Virtual Network Identifier (VNI), and reserved bits, transported over UDP using destination port 4789.[17] It supports up to 16 million network segments through the VNI but is limited to Ethernet payloads and lacks provisions for variable-length options or extensibility beyond its rigid structure.[17] In comparison, GENEVE introduces greater flexibility with its base 8-byte header augmented by optional Type-Length-Value (TLV) structures, allowing up to 252 bytes of variable metadata for enhanced extensibility, while VXLAN's fixed header provides no such capability.[2] GENEVE's 16-bit Protocol Type field enables support for diverse payload types beyond Ethernet, addressing VXLAN's restriction to Layer 2 Ethernet frames and accommodating evolving network requirements.[2][17] GENEVE's TLV-based design offers advantages in Software-Defined Networking (SDN) integration by permitting the inclusion of policy, security, or telemetry metadata, promoting future-proofing in dynamic environments, whereas VXLAN's simplicity supports easier adoption on legacy hardware but omits features like the O bit in GENEVE, which indicates control packets.[2] Both protocols share a similar 24-bit VNI for virtual network identification, as detailed in GENEVE's header structure.[2] For interoperability, GENEVE and VXLAN both rely on UDP over IPv4 or IPv6 transport, facilitating coexistence in mixed environments, with GENEVE's options enabling it to emulate VXLAN behaviors without requiring protocol changes.[2][18] This compatibility supports transitional deployments, though GENEVE's extensibility positions it as a more adaptable long-term solution compared to VXLAN's constrained format.[18]With NVGRE
Network Virtualization using Generic Routing Encapsulation (NVGRE) is a protocol proposed by Microsoft in 2011 that leverages the Generic Routing Encapsulation (GRE) mechanism to enable network virtualization in multi-tenant data centers.[19] It encapsulates inner Ethernet frames within an outer IP packet using a GRE header, without relying on UDP transport, and features a fixed 8-byte header that includes a 24-bit Virtual Subnet Identifier (VSID) for tenant isolation, supporting up to 16 million virtual networks.[20] NVGRE also natively accommodates IP multicast traffic for broadcast and unknown unicast handling, utilizing administratively scoped multicast addresses or N-way unicast replication, which facilitates service discovery in virtualized environments but can introduce complexity in underlay fabrics due to multicast state management.[20] In contrast to NVGRE's GRE-based encapsulation, GENEVE employs UDP over IP, which enhances entropy for Equal-Cost Multi-Path (ECMP) load balancing by varying the UDP source port based on inner packet flows, making it more compatible with modern network fabrics that hash on transport-layer headers.[2] NVGRE's reliance on GRE keys for flow identification provides less effective load distribution in ECMP scenarios, as GRE lacks inherent transport-layer variability.[2] Furthermore, while NVGRE uses a rigid header structure without support for additional metadata or options, GENEVE incorporates variable-length Type-Length-Value (TLV) options, enabling the inclusion of extensible metadata such as security tags or policy information directly in the encapsulation.[2] This absence of options in NVGRE limits its adaptability to evolving network requirements, whereas GENEVE's design allows for future-proofing through IANA-registered TLVs without protocol revisions.[2] GENEVE offers broader protocol flexibility and stronger alignment with software-defined networking (SDN) paradigms by decoupling the encapsulation from specific control plane implementations, permitting integration with diverse orchestration systems.[2] NVGRE's multicast support, while beneficial for initial discovery protocols in virtual networks, often necessitates additional underlay configurations that can strain large-scale fabrics, whereas GENEVE relies on unicast overlays with optional multicast emulation via head-end replication, simplifying deployment in SDN-controlled environments.[2] For migrations, GENEVE facilitates interoperability by using its Protocol Type field to encapsulate NVGRE packets directly, allowing a shared control plane to manage transitions without disrupting existing NVGRE deployments.[2]Implementations and Use Cases
Software Implementations
Open vSwitch (OVS), a widely used open-source virtual switch, has provided full support for GENEVE since version 2.5, released in February 2016, enabling encapsulation, decapsulation, and parsing of Type-Length-Value (TLV) options for flexible metadata transport.[21] This implementation integrates seamlessly with software-defined networking (SDN) controllers, such as OpenStack Neutron, allowing dynamic tunnel creation and policy enforcement through OpenFlow flows.[22] The Linux kernel offers native GENEVE support starting from version 3.18 in December 2014, with tools like iproute2 enabling interface creation and configuration for tunneling operations.[23] For example, a basic GENEVE tunnel can be set up using the commandip link add geneve0 type geneve id 100 remote 192.168.1.1 ttl 64, which creates a virtual interface with specified virtual network identifier (VNI), remote endpoint, and time-to-live. Enhanced options, including IPv6 and advanced TLV handling, were refined in subsequent releases like kernel 4.18 in 2018.[24]
Other software implementations include the Data Plane Development Kit (DPDK) libraries, which accelerate GENEVE processing in user space for high-performance networking applications, supporting encapsulation and offload features since DPDK 16.07 in 2016. VMware NSX-T has used GENEVE as its native overlay protocol since version 2.0 in 2018, providing full support for encapsulation in virtualized environments.[25]
For advanced configurations, OVS supports injecting custom TLV options via OpenFlow rules. A representative example involves adding a flow to set a metadata TLV during encapsulation:
ovs-ofctl add-flow br0 "in_port=1,actions=set_field:0x102->tun_geneve_option,class=0,type=2,len=4,load:0xdeadbeef->value,output:2"
ovs-ofctl add-flow br0 "in_port=1,actions=set_field:0x102->tun_geneve_option,class=0,type=2,len=4,load:0xdeadbeef->value,output:2"