Stretched Subnet Routing via Abbreviated Hardware Entries
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Interconnected data centers face limitations in supporting a large number of host destinations due to the maximum number of entries in Forwarding Information Base (FIB) tables, which restricts the scalability of stretched subnets across multiple data centers.
Innovation Solution
The method involves configuring border leaves and ToR switches to store abbreviated routes in hardware tables, allowing for optimized routing by representing all external destination hosts in a single entry, reducing the need for extensive FIB table entries and enabling efficient forwarding of traffic across multiple data centers.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Quantity of substance
If traditional FIB table routing is used for stretched subnets, then routing accuracy to specific host destinations is maintained, but the number of supported host destinations is limited by FIB table entry capacity
Solution Approach 1:
The patent segments routing information into two distinct components: aggregated subnet-level routing stored in hardware FIB tables for efficient forwarding, and detailed host-level routing stored in software for comprehensive destination identification. This segmentation allows the system to support more host destinations by storing only aggregated subnet routes in hardware while maintaining accurate host routing through software-based host route tables.
Solution Approach 2:
The patent introduces a new dimensional approach by implementing a two-tiered routing architecture that operates at different levels: hardware-based subnet-level aggregation and software-based host-level detail. This dimensional separation allows the system to overcome hardware FIB table capacity limitations while maintaining precise host destination routing through software-host route table correlations.
2Adaptability or versatility
If abbreviated routes are stored in hardware tables for external destinations, then FIB table capacity is reduced and scalability is improved, but routing complexity increases due to dual route table management
Solution Approach 1:
The patent applies local quality by implementing different routing strategies for different destination types: abbreviated aggregated routes are stored in hardware FIB tables for external destinations to optimize scalability, while complete host-level routes are maintained in software for internal destinations to ensure precise routing. This localized approach allows each routing component to be optimized for its specific function.
Solution Approach 2:
The patent introduces host route tables as an intermediary layer between the abbreviated hardware routes and the actual host destinations. These software-based host route tables serve as a mediator that correlates abbreviated subnet routes with specific host destinations, enabling the system to maintain detailed host routing information without consuming hardware FIB table capacity.
3Productivity
If host routes are distributed to all ToR switches, then optimal forwarding to specific hosts is achieved, but hardware resource consumption increases across the network
Solution Approach 1:
The patent merges routing functions by combining hardware-based aggregated subnet routing with software-based detailed host routing. Instead of distributing complete host routes to all ToR switches in hardware (which would consume excessive resources), the system merges abbreviated hardware routes with software host route tables to achieve both efficient forwarding and accurate host destination identification.
Data Source
AI summary
In one embodiment, a method for improving routing for a stretched subnet includes receiving a first communication on a border leaf of the stretched subnet, where the border leaf is a top of rack (ToR) switch configured to facilitate connectivity between an internal data center fabric and at least one external site associated with the stretched subnet, based on routing information received with the received communication, identifying a source address for the received communication as either from within the internal data center fabric or from the at least one external site, and if the source address is from the external site, storing an abbreviated route based on the source address in at least one hardware table, where the abbreviated route is a route to the at least one external site, and upon subsequent receipt of a second communication to be forwarded to the source address, forwarding the second communication in accordance with the abbreviated route.