
Changed paths to avoid '..', which breaks symlinks in newer versions of sphinx. Consolidated installation include files under /_includes. Prefixed r5 versions with 'r5_' Moved files that are used up/down, but at different paths under /shared/_includes and /shared/figures Move two include files to /_includes Moved addtional images to /shared/figures/... Required for DS platform builds. Signed-off-by: Ron Stone <ronald.stone@windriver.com> Change-Id: Ia38f4205c5803b3d1fc043e6c59617c34a4e5cbd Signed-off-by: Ron Stone <ronald.stone@windriver.com>
1.8 KiB
Executable File
Redundant Top-of-Rack Switch Deployment Considerations
For a system that uses link aggregation on some or all networks, you can configure redundant switches for additional reliability.
In a redundant switch configuration, each link in a link aggregate is connected to a different switch, as shown in the accompanying figure. If one switch fails, another is available to service the link aggregate.

recommends that you use switches that support . When is used, the aggregated links on the switches act as a single interface. Both switches are normally active, providing full bandwidth to the . If there are multiple failed links on both switches, at least one connection in each aggregate pair is still functional. If one switch fails, the other continues to provide connections for all links that are operational on that switch. For more about configuring , refer to your switch documentation.
You can use an active/standby failover model for the switches, but at a cost to overall reliability. If there are multiple failed links on both switches, then the switch with the greatest number of functioning links is activated, but links on that switch could be in a failed state. In addition, when only one link in an aggregate is connected to an active switch, the bandwidth is limited to the single link.
Note
You can enhance system reliability by using redundant routers. For more information, refer to your router documentation.