Tenant-Specific VTEPs for VXLAN Service Isolation
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing cloud data center environments face challenges in efficiently managing multi-tenancy within Virtual Extensible LAN (VXLAN) networks, particularly in reducing broadcast, unidentified unicast, and multicast (BUM) traffic flooding and enhancing service isolation among tenants.
Innovation Solution
The techniques enable multiple VXLAN Virtual Tunnel Endpoints (VTEPs) per compute node, allowing for tenant-specific VTEPs to be assigned to each tenant, and configuring packet processors to direct packets based on virtual destination addresses, thereby providing service isolation and reducing flooding.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Device complexity
If multiple tenants share a single VTEP on a compute node, then device complexity is reduced, but service isolation among tenants deteriorates and BUM traffic flooding increases
Solution Approach 1:
The patent segments the shared VTEP function into multiple tenant-specific VTEPs (one per tenant). Each VTEP maintains separate forwarding tables, flood lists, and packet processing contexts, enabling independent control and isolation of tenant traffic while eliminating the service isolation problems of shared VTEPs.
Solution Approach 2:
The patent introduces a new dimension of tenant identification by assigning unique VTEP instances to each tenant. This transforms the flat shared-resource model into a hierarchical structure where VTEPs are organized by tenant, enabling multi-dimensional traffic isolation (by tenant, by VNI, by flood list) without significantly increasing overall system complexity.
2Ease of operation
If a single VTEP is used per compute node, then ease of operation is improved, but BUM traffic flooding across the network increases
Solution Approach 1:
The patent segments the monolithic flood list of a shared VTEP into multiple tenant-specific flood lists, each associated with a specific VTEP. This segmentation enables precise control over BUM traffic propagation, allowing the system to flood only the necessary subset of compute nodes for each tenant's workloads rather than broadcasting to all nodes.
Solution Approach 2:
The patent applies local quality by making each VTEP's flood list tenant-specific and localized to the compute nodes hosting that tenant's workloads. This localized approach reduces unnecessary BUM traffic propagation to compute nodes hosting other tenants' workloads, reducing network overhead and energy consumption.
3Reliability
If tenant-specific VTEPs are implemented, then service isolation among tenants is improved, but device complexity increases
Solution Approach 1:
The patent implements a universal packet processing framework that can handle both shared and tenant-specific VTEPs through a common architecture. The main packet processor and tenant-specific packet processors share common data structures and processing logic, allowing the system to provide tenant-specific isolation while maintaining a unified, manageable configuration approach.
Solution Approach 2:
The patent introduces an intermediary layer (the main packet processor) that coordinates between the external network and multiple tenant-specific packet processors. This intermediary manages the complexity of multiple VTEPs by providing a unified entry point and coordinating packet distribution to the appropriate tenant-specific processors, thereby reducing the operational complexity despite increased functional granularity.
4Ease of operation
If VNIs are used for multi-tenancy, then ease of operation is improved, but the number of available virtual networks is limited by the 24-bit VNI space
Solution Approach 1:
The patent adds another dimension to virtual network identification by introducing tenant-specific VTEPs as a secondary identification layer. Instead of relying solely on the 24-bit VNI space, the system now uses a combination of (tenant_id, VNI) pairs, where each tenant can have their own VTEP supporting VNIs. This dimensional extension effectively multiplies the available virtual network capacity while maintaining VNI-based management simplicity.
Solution Approach 2:
The patent segments the VNI address space by tenant, with each tenant having their own VTEP that can support the full 24-bit VNI range. This segmentation allows multiple tenants to use overlapping or identical VNI values without conflict, as each VTEP maintains its own forwarding table and context, thereby exponentially increasing the total number of available virtual networks across the multi-tenant system.
Data Source
AI summary
In general, this disclosure describes techniques for enabling multiple Virtual Extensible LAN (VXLAN) Virtual Tunnel Endpoints (VTEPs) per compute node within a computing infrastructure. In one example, a computing device comprises a network interface controller (NIC) and processing circuitry having access to storage media encoded with instructions, the processing circuitry configured to receive, by a main packet processor, a packet from the NIC. The processing circuitry is further configured to send, by the main packet processor, based on a virtual extensible local area network (VXLAN) tunnel endpoint (VTEP) indicated by a packet, the packet to a tenant-specific packet processor associated with the VTEP. The processing circuitry is further configured to send, by the tenant-specific packet processor, at least a portion of the packet to a workload. The processing circuitry is further configured to process, by the workload, the at least a portion of the packet.