ToR Switch Blade Switch LLDP Intermediary Mechanism
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing blade switch-based data center deployments face challenges in automating the configuration of Top-of-Rack (ToR) switches due to intermediate switches consuming Link Layer Discovery Protocol (LLDP) packets, breaking the logic required for direct server connection identification, which is essential for VM Tracker's auto-provisioning functionality.
Innovation Solution
A two-hop resolution mechanism is implemented, where the Top-of-Rack (ToR) switch refers to both the VM Manager's database and its local LLDP Management Information Base (MIB) to identify blade switches and determine VM connectivity, enabling auto-provisioning of networks for VMs behind blade servers by correlating server and blade switch mappings.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If blade switches are deployed as intermediate switches between ToR switches and servers, then compute power density and scalability are improved, but LLDP packet consumption breaks direct connection identification logic
Solution Approach 1:
The patent introduces an intermediary mechanism where the blade switch captures LLDP packets but generates and forwards synthetic LLDP responses back to the ToR switch. This mediator approach allows the blade switch to block actual server LLDP packets while providing the ToR switch with the information it needs about server connections, thus resolving the information loss caused by intermediate switch deployment.
Solution Approach 2:
The blade switch creates copies of LLDP information by generating synthetic LLDP responses that mirror the connection information it receives from servers. These copied LLDP packets are then forwarded to the ToR switch, allowing the ToR to maintain accurate connection tracking without receiving the original server LLDP packets directly.
2Reliability
If LLDP packets are blocked by intermediate blade switches, then network security and traffic control are improved, but VM Tracker auto-provisioning functionality breaks
Solution Approach 1:
The blade switch acts as an intermediary that selectively blocks malicious or unwanted LLDP packets while allowing synthetic LLDP response packets to pass through to the ToR switch. This maintains network security by filtering actual server traffic while preserving automation functionality through controlled information flow.
Solution Approach 2:
The blade switch performs preliminary action by pre-generating and caching LLDP response information before the ToR switch needs it for auto-provisioning. This allows the blade switch to quickly respond to ToR LLDP queries with pre-computed server connection information, enabling VM Tracker functionality without exposing the network to unauthorized LLDP traffic.
3Speed
If direct server connection identification is used for VM Tracker, then auto-provisioning speed is improved, but blade switch deployments become incompatible
Solution Approach 1:
The patent makes the LLDP information flow universal by enabling it to work both in direct connection scenarios (ToR directly connected to servers) and intermediate connection scenarios (ToR connected to blade switches connected to servers). The blade switch's synthetic LLDP response mechanism provides a common interface that maintains the appearance of direct connectivity regardless of the actual physical topology.
Solution Approach 2:
The blade switch intermediary maintains the illusion of direct connectivity by synthesizing LLDP responses that make the ToR switch believe servers are directly attached. This mediator preserves the fast auto-provisioning speed of direct connection identification while enabling blade switch deployments through the intermediate synthetic packet generation.
Data Source
AI summary
A method is described and in one embodiment includes receiving at a top-of-rack (“TOR”) switch a notification concerning a virtual machine (“VM”), wherein the received notification identifies a host associated with the VM; determining whether the identified host is directly connected to the TOR switch; and if the identified host is not directly connected to the TOR switch, identifying an intermediate switch to which the identified host is directly connected; and determining whether the identified intermediate switch to which the identified host is directly attached is attached to the TOR switch.