Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Cascade Triggers Failover over Fabric

IP.com Disclosure Number: IPCOM000235742D
Publication Date: 2014-Mar-25
Document File: 5 page(s) / 357K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is an enhanced Level 2 Failover scheme for a spine-leaf topology based Performance Optimized Datacenter (PoD) solution. This cascade triggers failover is a distributed solution to help the Network Interface Controller (NIC) teaming feature perform correctly.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 01 of 5

Cascade Triggers Failover over Fabric

It is a trend today to deploy a Performance Optimized Datacenter (PoD) solution on the edge of a data center. A spine-leaf topology is usually used in such a PoD solution (Figure 1) with all server links connected to access switches and with all the

uplinks connected to aggregation switches.

Figure 1: PoD Solution with a spine-leaf topology

Level 2 (L2) Failover was designed primarily to support the network adapter, Network Interface Controller (NIC), teaming on servers. Traditional L2 Failover monitoring uplinks alone is not enough in such a PoD case, as the links between a pair of aggregation and access switches may also go down. An improved L2 Failover scheme is required to help the server NIC teaming feature behave correctly.

The solution is an enhanced L2 Failover scheme for a spine-leaf topology based PoD solution. This cascade triggers failover is a distributed solution. Cascade triggers failover is composed of a main failover trigger, which is running on the master, and multiple sub triggers, which are running on member switches.

1


Page 02 of 5

Figure 2: Cascade triggers failover fabric

The main failover trigger monitors both aggregate switches' configured uplinks and internal links between the master and each server port's member switch, and runs control over all configured server ports. Whenever configured uplinks fail, it forces all configured server ports down. Whenever any internal links fail, main trigger forces a failed connected member's server ports down and leaves other well connected members' server port unchanged.

Each sub failover trigger is running on each member switch and monitoring the internal link between its member switch and master switch. Whenever the monitored internal link fails, it forces the associated member switch's configured server port down; however, it will never bring up any server port, even if its monitored internal port is up.

Each sub failover trigger is auto generated according to the user configured main failover trigger, which is running on the master. The double trigger auto detects the internal ports between the master and each relative member switches, according to the configured uplink ports and server ports. It is running on a member switch, without any effect on the master switch, and does not cause any user configuration and master Central Processing Unit (CPU) consumption.

Sub failover brings down the associated server port via a local Application Protocol Interface (API) call, but not a remote API call as traditional failover and multiple monitors' failover do. This results in faster failover trigger down than trad...