Methods and media for facilitating in-service software upgrades in virtual switch stacks

Abstract

This disclosure relates to in-service software upgrade in a virtual switching stack. One aspect of the technology can provide a system for facilitating in-service software upgrade (ISSU) for a switch in a virtual switching stack. During operation, the system can initiate an ISSU that facilitates uninterrupted traffic flow. The system can upgrade a first set of daemons of the switch, the first set of daemons managing operations of the switch. The system can also upgrade a database stored on the switch. The database can store operational information of the switch. The system can also upgrade a second set of daemons of the switch, the second set of daemons configuring forwarding information about forwarding hardware of the switch and facilitating data plane operations for the switch. The forwarding information configured on the forwarding hardware can remain unchanged during the upgrade. The system can configure the upgraded second set of daemons to obtain control plane information from a backup switch that serves as a director switch for the virtual switching stack.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to communication networks. More particularly, the present disclosure relates to methods and systems for facilitating interruption-free in-service software upgrade (ISSU) in networks operating as virtual switching stacks. BRIEF DESCRIPTION OF DRAWINGS

[0002] Figure 1A An example of a virtual switching stack supporting interruption-free in-service software upgrade (ISSU) is illustrated in accordance with an aspect of the present application.

[0003] Figure 1B An example of a switch in a virtual switching stack supporting interruption-free ISSU is illustrated in accordance with an aspect of the present application.

[0004] Figure 2 An example of a phase of ISSU in a virtual switching stack is illustrated in accordance with an aspect of the present application.

[0005] Figure 3A An example of a phase of ISSU in a standby switch of a virtual switching stack is illustrated in accordance with an aspect of the present application.

[0006] Figure 3B An example of a phase of ISSU in a member switch of a virtual switching stack is illustrated in accordance with an aspect of the present application.

[0007] Figure 3C An example of a phase of ISSU in a conductor switch of a virtual switching stack is illustrated in accordance with an aspect of the present application.

[0008] Figure 4 A flow diagram illustrating the progress of a conductor switch in a virtual switching stack facilitating ISSU is presented in accordance with an aspect of the present application.

[0009] Figure 5A A flow diagram illustrating the progress of a standby switch in a virtual switching stack facilitating ISSU is presented in accordance with an aspect of the present application.

[0010] Figure 5B A flow diagram illustrating the progress of a member switch in a virtual switching stack facilitating ISSU is presented in accordance with an aspect of the present application.

[0011] Figure 6FIG. illustrates an example of facilitating switches in a virtual switching stack of ISSU, according to an aspect of the application.

[0012] In the drawings, like reference numerals refer to like elements throughout. DETAILED DESCRIPTION

[0013] The following description is presented to enable any person skilled in the art to make and use the application, and is provided in the context of particular applications and its requirements. Various modifications to the disclosed examples will be readily apparent to those skilled in the art, and the general principles defined herein can be applied to other examples and applications without departing from the spirit and scope of the application. Thus, the present application is not intended to be limited to the aspects shown, but is to be accorded the widest scope consistent with the claims.

[0014] The Internet is a delivery medium for various applications running on physical and virtual devices. Such applications bring a gradually increasing amount of network traffic. As a result, device vendors compete to build switches with generic capabilities, such as in-service software upgrade, which allows a switch to upgrade its operating software (e.g., install a binary of a new switch image) while remaining in service. This allows a switch of a network to upgrade its software without interrupting traffic flow through the network.

[0015] Generally, in a complex network, such as a virtual switching stack, different switches are assigned different roles. When a switch is assigned a role, the switch can need to perform a particular set of operations. For example, one switch can be assigned a task to maintain control plane information, while another switch can operate as a member switch in the complex network. For such a network, ISSU for the two switches can differently affect traffic flow in the network. As a result, deploying ISSU in a complex network can be challenging and can need to be orchestrated such that interruption to traffic flow through the network can be reduced.

[0016] Aspects described herein solve the problem of facilitating ISSU in a virtual switching stack without interrupting traffic flow by (i) coordinating ISSU among switches of different switch roles in the stack in different stages such that traffic flow remains uninterrupted; and (ii) upgrading, at each stage, a subset of software elements of a subset of switches of the stack based on their respective roles. Front Plane Stacking (FPS) is a network virtualization technology that can virtualize multiple physical switches (e.g., in the same layer) as one virtual switching stack. The stack can operate a unified control plane. As a result, the stack can appear as a single switch to upper and lower layer devices.

[0017] To facilitate control and operation of the stack, different switches of the stack are configured with different roles, such as a conductor, a backup, and a member. The conductor switch of the stack can maintain control plane operations, while the backup switch serves as a backup to the conductor switch. The remaining switches can be referred to as member switches. Depending on the roles, operations of daemons and contents of databases at the switches of the stack can be different. Coordination for ISSU can upgrade daemon and database versions (e.g., update database schema) based on the respective roles of the switches, such that the data plane of the respective switches can continue to forward traffic during the upgrade process.

[0018] With existing technologies, multiple switches in a network can be configured to operate as a virtual switching stack for providing resiliency, scalability, and efficient bandwidth utilization using FPS technologies such as Virtual Switching Framework (VSF). The switches in the stack can be coupled to each other via inter-switch links (e.g., point-to-point copper or fiber links). The switches in the stack can use the links to forward encapsulated data plane traffic and switch control plane traffic. Typically, a conductor switch can run control plane daemons (such as routing and management protocol daemons) and propagate resulting control information (such as new routes) to other switches of the stack. The control plane traffic allows the stack to maintain its topology and state for operating as a single logical switch.

[0019] Similar to any computing technology, a piece of software facilitating daemons on respective switches can be upgraded to improve performance, stability, and security of the stack. The upgraded software can be integrated into a new switch image that can be deployed on the switches of the stack. Since the switches in the operational stack can actively forward traffic, it can be necessary to install the new switch image while the stack remains in service. ISSU can allow a user (e.g., an administrator) to install the new switch image in the switches while the stack continues to forward traffic.

[0020] However, ISSU can not be supported in a stack. A rolling stack upgrade mechanism can be used to upgrade the switches in the stack, where the respective switches in the stack can be upgraded one by one until all switches in the stack are upgraded. With the rolling upgrade method, the switch being upgraded can need to be rebooted, which can stop packet forwarding at the switch during the reboot process. Thus, the switch can become unavailable for a period of time, impacting traffic flow through the stack. Therefore, if the stack includes a large number of switches, the combined period of unavailability of the stack during the rolling upgrade process can become significant and detrimental to the performance of the stack.

[0021] To address this issue, the switches in the stack can be upgraded in multiple phases such that traffic flow is uninterrupted. In each of the phases, a subset of the switches can be selected for ISSU based on the respective roles of the switches. Upon selection, a subset of software elements of the respective selected switches can be selected for upgrade in the phase. The software elements can include daemon processes and database servers that support the operation of the selected switches, which can be upgraded in the phase without interrupting traffic flow through the switches. To support such phased-based coordinated software upgrade, the respective switches of the stack can be equipped with an instance of an upgrade coordinator that facilitates a coordinated ISSU process in the stack. In each phase, the upgrade coordinator can only upgrade software elements of the switches that do not require the switches to stop traffic forwarding. In this way, the coordinated ISSU process can eventually upgrade the software (e.g., daemons and databases) of the respective switches of the stack without interruption.

[0022] In a first phase, the upgrade coordinator can install a new switch image on the standby switches and the member switches, which can include a new database version. The database can be a specialized relational database for network devices (e.g., Open vSwitch Database (OVSDB)). The installation can upgrade and restart the management daemons and databases of the corresponding switches. The new database version can transition the databases of the corresponding switches to a new database schema. Here, the management daemons can include all switch daemons except the line card daemons (or line card agents). Examples of the management daemons can include, but are not limited to, control plane daemons that manage control plane protocols and operations, platform daemons that facilitate platform-specific operations, and helper daemons that support the operations of other daemons. On the other hand, the line card daemons can obtain control information (e.g., routes and forwarding ports) needed to forward packets and program the forwarding hardware (i.e., application-specific integrated circuits (ASICs)) of the line cards accordingly.

[0023] In the second phase, the upgrade orchestrator can freeze the internal state of the line card of the respective switch to prevent any control plane changes. Thus, the forwarding information associated with the data path programmed at the switch hardware can remain unchanged when used to forward traffic. The line card daemon on the respective switch of the stack can then be upgraded and restarted. Thus, the underlying hardware can continue to function without any changes during this phase. Upon restart, the upgrade orchestrator can configure the line card daemon, including the line card daemon of the conductor switch, to use the standby switch for the subsequent control plane upgrade.

[0024] Since the conductor switch can remain responsible for the control plane of the stack, the control plane daemon on the conductor switch can continue to process control plane upgrades, if any, during the upgrade process and store them in the local database (i.e., the conductor database). However, because the line card daemon of the stack is configured to obtain upgrades from the standby switch (i.e., from the standby database of the standby switch), the changes can not be propagated in the stack. This allows the stack to remain in control plane without impacting traffic flow through the stack.

[0025] In the third phase, the conductor database is synchronized with the standby database. The control plane upgrades stored in the conductor database can then be propagated to the standby database. Since the line card daemon of the stack is configured to obtain upgrades from the standby switch, the synchronized control plane upgrades can be propagated in the stack. Subsequently, the upgrade orchestrator can trigger a failover that allows the standby switch to start operating as the conductor of the stack. This failover can be considered artificially triggered because the failover is not triggered due to a failure of the conductor switch.

[0026] At this point, the standby switch can assume the role of the conductor and initiate the local control plane daemon to operate with the role of the conductor. Since the switches in the stack no longer rely on the previous conductor switch to obtain control information, the upgrade orchestrator can install a new switch image on the previous conductor switch and upgrade the management daemon accordingly. When the upgrade is complete, the previous conductor switch can start operating as a new standby switch. In this manner, the upgrade orchestrator can provide a coordinated ISSU process in the stack without interruption.

[0027] In this disclosure, the term "switch" is used in a general sense and can refer to any standalone or fabric switch operating in any network layer. "Switch" should not be interpreted to limit examples of the present invention to Layer-2 networks. Any device that can forward traffic to an external device or another switch can be referred to as a "switch." Any physical device or virtual device (e.g., a virtual machine or switch operating on a computing device) that can forward traffic to an end device can be referred to as a "switch." Examples of "switches" include, but are not limited to, Layer-2 switches, Layer-3 routers, routing switches, components of Gen-Z networks, or fabric switches that include multiple similar or heterogeneous smaller physical switches and / or virtual switches.

[0028] The term "packet" refers to a group of bits that can be transported together across a network. "Packet" should not be interpreted to limit examples of the present invention to a particular layer of a network protocol stack. "Packet" can be replaced by other terms that refer to a group of bits, such as "message," "frame," "cell," "datagram," or "transaction." Furthermore, the term "port" can refer to a port that can receive or transmit data. "Port" can also refer to hardware, software, and / or firmware logic that can facilitate operation of the port.

[0029] Figure 1A An example of a virtual switch stack that supports ISSU is illustrated in accordance with an aspect of the present application. Network 100 can include multiple switches and devices and can include heterogeneous network components, such as Layer-2 hops and Layer-3 hops as well as tunnels. In some examples, network 100 can be an Ethernet, InfiniBand, or other network and can use corresponding communication protocols, such as Internet Protocol (IP), Fibre Channel over Ethernet (FCoE), or other protocols. Network 100 can include switches 101, 102, 103, 104, and 105, each of which can be associated with a MAC address and an IP address. Respective switches of network 100 can deploy instances of a relational database. For example, switches 102, 104, and 103 can deploy databases 112, 114, and 116, respectively. End devices 122 and 124 can be coupled to switches 102 and 105, respectively.

[0030] The respective links in network 100 can be physical links or tunnels across one or more physical links. Examples of tunnels can include, but are not limited to, VXLAN, Generic Routing Encapsulation (GRE), Network Virtualization using GRE (NVGRE), Generic Network Virtualization Encapsulation (Geneve), Internet Protocol Security (IPsec), and Multiprotocol Label Switching (MPLS). The respective pairs of switches in network 100 can be BGP peers. Network 100 can be coupled to a management device 120, which can manage network 100 and provision the switches 101, 102, 103, 104, and 105. Further, management device 110 can allow a user (or administrator) to issue instructions to any of these switches to configure the switch.

[0031] A user (e.g., a network administrator) can use management device 120 to configure network 100 based on an FPS such as VFS to virtualize physical switches 101, 102, 103, 104, and 105 into a virtual switching stack 110. Stack 110 can operate a unified control plane in network 100 and can appear as a single switch to other devices 122 and 124. To facilitate control and operation of stack 100, different switches of stack 110 are configured with different roles. In stack 110, switches 102 and 104 can be configured with a conductor role and a backup role of stack 110, respectively. The remaining switches of network 100 can be configured with a member role of stack 110. The member switches can not run networking protocols and hold state. The ports of the member switches can be controlled and programmed by the conductor switch 102. The member switches can be upgraded to the backup role if the backup switch 102 takes over as conductor or a new backup switch is needed.

[0032] The director switch 102 can maintain control plane operations of the stack 110, while the standby switch 104 operates as a backup for facilitating high availability of the director switch 102. The director switch 102 can also control the corresponding line cards in the stack 110, including the line cards in the switches 101, 103, 104, and 105. The director switch 102 can run control plane daemons such as routing and management protocol daemons, and propagate resulting control information such as new routes to the other switches of the stack 110. The control plane traffic allows the stack 110 to maintain its topology and state for operating as a single logical switch. The director switch 102 can be assigned a control IP address 130 that allows other switches to obtain the control information. Depending on the role, the operations of the daemons and the content of the databases at the switches of the stack 110 can be different. The database 112 of the director switch 102 can be referred to as a director database, which stores control information representing the control plane of the stack 110. Such control information can include routing and forwarding information.

[0033] The database 114 of the standby switch 104 can be referred to as a standby database that receives synchronization information from the director database 112 (e.g., periodically or in response to updates to the control information). Accordingly, the corresponding control information databases 112 and 114 can be kept synchronized. Based on the synchronized information in the database 114, if a failover is triggered, the standby switch 104 can start operating as a director. For example, if the director switch 102 fails, the other switches can discover the failure (e.g., due to missing periodic heartbeat messages from the switch 102). Upon discovery, the switch 104 can assign the director role to itself and start using a local control plane to manage the control plane of the stack 110. Then, the IP address 130 can be associated with the switch 104. Accordingly, the other switches can then start obtaining their control information from the new director switch 104 via the IP address 130.

[0034] Switches in the stack 110 can be coupled to each other via inter-switch links (e.g., point-to-point copper or fiber-based Ethernet links). The switches in the stack 110 can use these links to forward data plane traffic and exchange control plane traffic. Respective packets on the inter-switch links are encapsulated with a stack encapsulation header associated with the action 110. For example, when the end device 112 sends an Ethernet packet to the end device 114, the switch 102 can receive the packet and determine that the end device 114 is reachable via the switch 105. The switch 102 can then encapsulate the packet with a stack encapsulation header and forward the encapsulated packet to the switch 105. The source and destination addresses of the stack encapsulation header can correspond to the switches 102 and 105, respectively. Thus, when the switch 105 receives the encapsulated packet, the switch 105 can decapsulate the stack encapsulation header and forward the Ethernet packet to the end device 114.

[0035] A software that facilitates daemons on respective switches of the stack 110 can be upgraded to improve performance, stability, and security of the stack 110. The upgraded software can be integrated into a new switch image that can be deployed on the switches of the stack 110. Since the switches in the stack 110 can be operational and can actively forward traffic, the new switch image can need to be installed while the stack 110 remains in service. ISSU can allow a user to install the new switch image in the switches while the stack 110 continues to forward traffic. With existing techniques, ISSU can not be supported in the stack 110 because different switches are assigned different roles. For example, if the director switch 102 is upgraded with ISSU, the schema of the database 112 can be upgraded and thus can not be synchronized with the database 114. Thus, failover can result in inconsistencies in the stack 110.

[0036] Further, the switches in the stack 110 can be upgraded using a rolling stack upgrade mechanism, where respective switches in the stack 110 can be upgraded one at a time until all switches in the stack 110 are upgraded. With the rolling upgrade method, the switch 105 can need to be rebooted when the switch 105 is upgraded. Thus, packet forwarding can be stopped at the switch 105 during the reboot process. Thus, the switch 105 can become unavailable for a period of time, affecting traffic flow through the stack 110. In particular, traffic to and from the end device 124 can be dropped while the switch 105 is unavailable. Thus, if the stack 110 includes a large number of switches, the combined period of unavailability of the stack 110 during the rolling upgrade process can become significant and detrimental to the performance of the stack 110.

[0037] To address this issue, the switches in the stack 110 can be upgraded in multiple phases such that traffic flow via the stack 110 remains uninterrupted. In each of the multiple phases, a subset of the switches of the stack 110 can be selected for ISSU based on the respective roles of the switches. Upon selection, a subset of the software elements of the respective selected switches of the stack 110, such as daemon processes and database servers, can be selected for upgrade in that phase. To support such phased coordinated software upgrades, the respective switches of the stack 110 can be equipped with an instance of an upgrade coordinator that facilitates coordinated ISSU processes in the stack 110. In each phase, the upgrade coordinator can only upgrade software elements of switches that do not require the switches to stop traffic forwarding. In this manner, the upgrade coordinator can eventually upgrade the software of the respective switches of the stack 110 without interruption.

[0038] In a first phase, the upgrade coordinator can install new switch images on the standby switch 102 and the member switches 101, 103, and 105, which can include a new database version. The installation can upgrade and restart the management daemons and databases of the switches 101, 103, 104, and 105. Here, the new database version of the database 114 can transition the database 114 to a new database schema. The new version of the database 114 can then be synchronized with the previous version of the database 114. This synchronization at least populates a subset of the columns of the new version of the database 114. The management daemons can then start operation using the new version of the database 114. The previous version of the database 114 can then be removed. This process can also be repeated for the member switches 101, 103, and 105.

[0039] In a second phase, the upgrade system can freeze the internal state of the line cards of the respective switches of the stack 110 to prevent any control plane changes. Thus, the forwarding information associated with the data paths programmed at the forwarding hardware can remain unchanged while being used to forward traffic. In other words, the line cards of the stack 110 can continue to forward traffic based on the existing forwarding information without needing to be programmed for any control plane upgrades. The line card daemons on the respective switches of the stack 110 can then be upgraded and restarted. Upon restart, the upgrade coordinator can configure the line card daemons, including the line card daemon of the director switch 102, to use the standby switch 104 for subsequent control plane upgrades.

[0040] Accordingly, instead of director switch 102, standby switch 104 can begin controlling the corresponding line cards of stack 110. Since director switch 102 can still be responsible for the control plane of stack 110, the control plane daemon on director switch 102 can continue to process control plane upgrades, if any, during the upgrade process and store them in database 112. However, the changes can not be propagated in stack 110 because the line card daemons of stack 110 can then be configured to obtain upgrades from standby database 114 of standby switch 104. This allows stack 110 to remain in control plane without affecting traffic flow through stack 110.

[0041] In a third stage, database 112 is synchronized with database 114. The control plane upgrades stored in database 112 can then be propagated to database 114. Since the line card daemons of stack 110 are configured to obtain upgrades from standby switch 104, the synchronization of control plane upgrades can be propagated in stack 110. Subsequently, the upgrade coordinator can trigger a manual failover, which allows standby switch 104 to begin operating as the director of stack 110. The failover can be considered manual because it is not triggered due to a failure of director switch 102. Moreover, unlike a regular failover, which can transfer control of stack 110 to standby switch 104, control of the line cards has already been transferred to standby switch 104.

[0042] At this point, switch 104 can assume the role of director and initiate local control plane daemons to operate with the role of director of stack 110. Since the switches in the stack are no longer dependent on the previous director switch 102, the upgrade coordinator can install a new switch image on switch 102 and upgrade the local management daemons accordingly. When the upgrade is complete, switch 102 can begin operating as the new standby switch in stack 110. In this manner, the upgrade coordinator can provide a coordinated ISSU process in stack 110 with no interruption.

[0043] Figure 1B An example of a switch in a virtual switching stack that supports in-service software upgrade (ISSU) is illustrated in accordance with an aspect of the present application. Switch 102 can include database 112, which can be an instance of a specialized relational database for network devices (e.g., an OVSDB instance). Switch 102 can operate a database management system (DBMS) that facilitates database 112. Switch 102 can be equipped with a plurality of line cards 160, which can include line cards 162, 164, 166, and 168. The installation of a binary file of a new switch image on switch 102 can upgrade the version of database 112. The new database version can transition database 112 to a new database schema.

[0044] In addition, the installation can upgrade and restart the management daemons 142 and line card daemons (or line card agents) 144 of the switch 102. Here, the management daemons can include all daemons of the switch 102 except the line card daemons 144. Examples of the management daemons 142 can include, but are not limited to, a control plane daemon that manages control plane protocols and operations on the switch 102, a platform daemon that facilitates platform-specific operations on the switch 102, and a helper daemon that supports operations of other daemons on the switch 102. On the other hand, the line card daemons can obtain control information (e.g., routes and forwarding ports) required for forwarding packets and program the forwarding hardware (i.e., application-specific integrated circuits (ASICs)) of the line cards accordingly.

[0045] Further, to facilitate the in-service ISSU, the switch 102 can include an upgrade coordinator 152, a schema migration framework (SMF) 154, a hot patch process 156, and a data path coordinator 158. The upgrade coordinator 152 can include a process for coordinating the ISSU in the stack 110. An instance of the upgrade coordinator 152 can run on a corresponding switch of the stack 110. The hot patch process 156 can install binary files from a new switch image. Since the installation of the binary files is performed in stages, the upgrade coordinator 152 can interact with the hot patch process 156 to coordinate the staged installation of the corresponding binary files.

[0046] Further, the SMF 154 can migrate a database from an older version to a newer version. Thus, the SMF 154 can upgrade the schema of the database. For example, the switch 102 uses the database 112 to keep control information, dataplane forwarding tables, and states of processes. Since a new schema of the database 112 can have table structures (e.g., can include new columns for tables), synchronization between versions of the database 112 can be challenging. The SMF 154 can identify corresponding columns of different database versions and migrate stored data to the new version.

[0047] Furthermore, the data path coordinator 158 can upgrade the line card daemon without affecting traffic flow through the line card. The data path coordinator 158 can run actively on the command switch 102 and remain inactive in other switches in the stack 110 (e.g., standby switch 104). The data path coordinator 158 can migrate the data plane forwarding state from an older version of the database 112 to a newer version. In this way, the upgrade coordinator 152, SMF 154, hot patcher 156, and data path coordinator 158 can operate in combination to facilitate ISSU for switch 102 and stack 110.

[0048] The upgrade coordinator 152 on the command switch 102 can initiate the ISSU process for stack 110. Figure 2 An example of an ISSU phase in a virtual switching stack according to one aspect of this application is illustrated. During phase 1, the upgrade coordinator 152 can upgrade standby switch 104 and member switches (such as switch 103). In this example, the upgrade of switch 103 is also applied. Figure 1A Switches 101 and 105. The upgrade coordinator 152 of the command switch 102 can stop the management daemon 212 of the standby switch 104 and the management daemon 214 of the member switch 103. The upgrade coordinator 152 can request hot patch processes 256 and 266 of switches 104 and 103 respectively to install binaries from the new switch image.

[0049] Then, hot-patching processes 256 and 266 can extract binary files 202 for the management daemons from the switch image and install them on switches 104 and 103, respectively. Furthermore, the installation of binary files 202 can install new versions of database servers 234 and 236 (e.g., OVSDB servers) and update the versions of databases 114 and 116 on switches 104 and 103, respectively. Therefore, databases 114 and 116 can be transformed into a new architecture 204 corresponding to the new database versions and can be operated using database servers 234 and 236, respectively. Since the management daemon 142 and database 112 of the controller switch 102 were not upgraded in Phase 1, the controller switch 102 can continue to operate the control plane without interruption. Once binary files 202 are installed, upgrade coordinators 252 and 262 on switches 104 and 103 can start the new versions of the corresponding database servers 234 and 236, respectively.

[0050] The upgrade coordinators 252 and 262 can also initiate table synchronization from the old version to the new version for the databases 114 and 116, respectively, using the SMFs 254 and 264 of the standby switch 104 and the member switch 103, respectively. The synchronization can include the columns needed for the operation of the standby switch 104 and the member switch 103. Even though the standby switch 104 can maintain a copy of the conductor database 112 to support failover, the copy of the conductor database 112 can not be synchronized with the new version, thereby reducing the memory overhead of the ISSU. The upgrade coordinators 252 and 262 can then restart the management daemons 212 and 214, respectively, based on the binary files 202. The management daemons 212 and 214 can then connect to the database servers 234 and 236, respectively, and resume their operations. In this phase, the conductor switch 102 can continue to determine the control plane updates 210 and store them in the database 112.

[0051] In phase 2, the line card daemons of the stack 110 are upgraded. The data path coordinators 158 on the conductor switch 102 can freeze the data paths on all line cards of the stack 110, such as the line cards 160, 222, and 224 of the switches 102, 104, and 103, respectively. The frozen data paths on the line cards can ensure that there are no runtime changes to the line cards during the ISSU. To facilitate the operation of the frozen line cards, the data path coordinators 158 can generate a current snapshot 230 of the data plane forwarding information of the database 112. The snapshot 230 can also be referred to as an ISSU cache. The snapshot 230 can not change during the upgrade process. The conductor switch 102 can provide the snapshot 230 to the standby switch 104, which can then synchronize the snapshot 230 with the new version of the database 114.

[0052] In general, the conductor switch 102 can consider the other switches of the stack 110, such as the standby switch 104 and the member switch 103, as line card modules. Accordingly, the line card daemons 216 and 218 of the switches 104 and 103 can connect to the conductor switch 102 to receive data path information, respectively, to program the forwarding hardware of the local line cards 222 and 224, respectively. The line card daemons 216 and 218 can maintain the internal state of the forwarding hardware in the memory of the switches 104 and 103, respectively. The data path coordinators 158 can instruct the line card daemons 144, 216, and 218 of the switches 102, 104, and 103, respectively, to store the internal hardware state (e.g., ASIC state) in the corresponding state files 242, 244, and 246, respectively. These state files can be hot start files, which can be used to reconcile the hardware state when one hardware is restarted.

[0053] Subsequently, the upgrade orchestrator 152, 252, and 262 can stop the line card daemon processes 144, 216, and 218 of the switches 102, 104, and 103, respectively. The upgrade orchestrator 152, 252, and 262 can then request the hot patch processes 156, 256, and 266, respectively, to install the new binaries 206 for the line card daemon processes on the switches 102, 104, and 103, respectively. When the installation is complete, the line card daemon processes 144, 216, and 218 can restart with the hot start files 242, 244, and 246 as input, respectively. The line card daemon processes 144, 216, and 218 can use the corresponding hot start files to tune with the internal state of the local line cards 160, 222, and 224, respectively.

[0054] The upgrade orchestrator 152, 252, and 262 can then instruct the line card daemon processes 144, 216, and 218 to connect to the standby database 114, which can store the forwarding information represented in the new database version (e.g., based on the snapshot 230), respectively. The line card daemon processes 144, 216, and 218 can repopulate the data plane information by connecting to the standby database 114 and obtaining the corresponding information. In other words, the new versions of the line card daemon processes 144, 216, and 218 can synchronize with the data plane in the new database version of the database 114 (i.e., based on the schema 204) stored on the standby switch 104. In this stage, the conductor switch 102 can continue to determine control plane updates 210 and store them in the database 112.

[0055] In stage 3, the conductor switch 102 is upgraded. Since the conductor switch 102 has stored the control plane updates 210 in the old version of the database 112, the upgrade orchestrator 152 can synchronize the database 112 with the database 114 based on using the SMF 154. In this way, the control plane updates 210 can be transferred to the new database version, which can correspond to the schema 204. The upgrade orchestrator 152 can stop the management daemon process 142 of the conductor switch 102 and enable the artificial failover 250. The management daemon process 212 on the standby switch 104 can then start operating in the conductor mode, and thus, the switch 104 can start operating in the role of the conductor in the stack 110. To start operating in the conductor mode, the control plane daemon of the management daemon process 212 can be activated, which can cause the switch 104 to start participating in routing and management protocols.

[0056] Upon handing over control to the switch 104, the upgrade coordinator 152 can request the hot patch process 156 to install the remaining portion of the new switch image, as the hot patch process 156 has already installed the binary file 206 on the switch 102. The hot patch process 156 can then install the binary file 202 on the switch 102. The installation of the binary file 202 can install the new version of the database server 232 and update the version of the database 112 of the switch 102. Thus, the database 112 can transition to the new schema 204 corresponding to the new database version and can operate with the database server 232. The database 112 can then synchronize with the database 114, thereby ensuring that the latest information is present in the database 112. The management daemon 142 on the switch 102 can then restart and begin operating in the standby mode, and thus, the switch 102 can begin operating as a standby switch in the stack 110. In this way, the ISSU can be used to install a new switch image on the stack 110 without affecting the forwarding operation.

[0057] Figure 3A An example of the stages of ISSU in a standby switch of a virtual switch stack in accordance with an aspect of the present application is illustrated. During stage 1, the standby switch 104 can stop the management daemon (operation 302) and install binary files except for the line card daemon (operation 304). The switch 104 can then start the new version of the database 114 (and corresponding database server) and synchronize with the old version of the database 114 (operation 306). Subsequently, the switch 104 can remove the old version of the database 114 (operation 308) and start the management daemon (operation 310).

[0058] During stage 2, the switch 104 can take a snapshot of the conductor database as an ISSU cache and synchronize with the local database 114 (operation 312). The switch 104 can then backup the hardware state of the local line card into a hot start file (operation 314), stop the line card daemon (operation 316), and install the binary file of the line card daemon (operation 318). Subsequently, the switch 104 can start the line card daemon and tune the hardware state using the hot start file (operation 320). The switch 104 can then resume control of the line card of the stack 110 (operation 322).

[0059] During stage 3, the switch 104 can synchronize the local database 114 with the conductor database (i.e., the ISSU cache) (operation 324). The switch 104 can then stop the line card daemon (operation 326) and install the binary file of the line card daemon (operation 328). Subsequently, the switch 104 can start the line card daemon (operation 330) and tune the hardware state using the hot start file (operation 332). The switch 104 can then resume control of the line card of the stack 110 (operation 334). Figure 1AThe standby switch 104 can then initiate a takeover from the director switch (operation 326). Subsequently, the switch 104 can start the management daemon in director mode and change the local role to director (operation 328). In this manner, the standby switch 104 can be upgraded with ISSU without impacting traffic flow through the switch 104. When the upgrade process is complete, the switch 104 can begin operating as the new director of the stack 110.

[0060] Figure 3B FIG. 6 illustrates an example of a phase of ISSU in a member switch of a virtual switching stack in accordance with an aspect of the present application. During phase 1, the member switch 103 can stop the management daemon (operation 332) and install binary files except for the line card daemon (operation 334). The management daemon on the switch 103 can include the platform and helper daemons, and can exclude the control daemon. The switch 103 can then start a new version of the database 116 (and corresponding database server) and synchronize with the old version of the database 116 (operation 336). Subsequently, the switch 103 can remove the old version of the database 116 (operation 338) and start the management daemon (operation 340).

[0061] During phase 2, the switch 103 can back up the hardware state of the local line card into a hot start file (operation 342), stop the line card daemon (operation 344), and install binary files for the line card daemon (operation 346). Subsequently, the switch 103 can start the line card daemon and tune the hardware state using the hot start file (operation 348). The switch 103 can then connect the line card daemon to the standby switch (e.g., switch 104) to provide control of the line cards of the stack 110 (operation 350). During phase 3, the switch 103 can detect a failover (operation 352) and connect to the new director switch (operation 354).

[0062] Figure 3C FIG. 7 illustrates an example of a phase of ISSU in a director switch of a virtual switching stack in accordance with an aspect of the present application. During phase 1, the director switch 102 can initiate installation of binary files on the standby switch and member switches (operation 360). During phase 2, the switch 102 can freeze the datapath on all line cards of the stack 110 to prevent runtime changes (operation 362). The switch 102 can then back up the hardware state of the local line card into a hot start file (operation 364). The switch 102 can also generate a snapshot of the director database 112 as an ISSU cache and provide the snapshot to the standby switch (e.g., switch 104) (operation 366). Subsequently, the switch 102 can start the standby switch in director mode (operation 368). Figure 1Athe switch 104 in the stack 110 (operation 366).

[0063] The switch 102 can then instruct all switches to install the binary files for the line card daemon and stop the local line card daemon (operation 368). The switch 102 can install the binary files for the line card daemon, start the line card daemon, and use the hotstart file to tune the hardware state (operation 370). The switch 102 can then release control of the line card of the stack 110 (operation 372). During phase 3, the switch 102 can synchronize the local database 112 with the standby database (i.e., the database 114 of the switch 104 in the stack 110) (operation 374). The switch 102 can stop the management daemon (operation 376) and initiate failover to provide control to the standby switch (operation 378). Figure 1A

[0064] Subsequently, the switch 102 can install the binary files other than the line card daemon (operation 380). The switch 102 can then change the local role to standby, start the new version of the database 112 (and corresponding database server), and synchronize with the new conductor database 114 (operation 382). The switch 104 can remove the old version of the database 112 and start the management daemon in standby mode (operation 384). In this manner, the conductor switch 102 can be upgraded with ISSU without impacting traffic flow through the switch 102. When the upgrade process is complete, the switch 102 can start operating as the new standby for the stack 110.

[0065] Figure 4 A flow diagram illustrating a process of a conductor switch in a virtual switching stack facilitating ISSU is presented in accordance with an aspect of the present application. During operation, a switch can instruct a hot patch process to install binary files other than the line card daemon of a new switch image on a standby switch and a member switch (operation 402), and determine whether installation is complete (operation 404). The switch can continue to wait for installation to complete on the standby switch and the member switch. On the other hand, when installation is complete, the switch can freeze the datapath on the line card to prevent changes (operation 406) and generate a hotstart file of the line card hardware state (operation 408).

[0066] ​The switch can generate a snapshot of the local database and provide that snapshot to the standby switch (operation 410). The switch can stop the line card daemon and instruct the hot patching process to install the line card daemon's binary file onto the stack (e.g., on all switches) (operation 412). The switch can restart the line card daemon and tune its state according to the hot-start file (operation 414). Subsequently, the switch can transfer control of the line card to the standby switch (operation 416) and determine whether the transfer is complete (operation 418). The switch can continue to wait for the transfer to complete on the standby switch and member switches.

[0067] On the other hand, when the handover is complete, the switch can synchronize the local database with the standby database (operation 420). The switch can then stop the local management daemon and initiate a failover to give control of the stack to the standby switch (operation 422). The switch can instruct the hot patching process to install the binary files of the new switch image, excluding the line card daemon, on the local switch (operation 424). The switch can then restart the database server, start the database with the new architecture, and synchronize with the new command switch (operation 426). The switch can then change its role to standby switch and restart the management daemon in standby mode (operation 428).

[0068] Figure 5A A flowchart illustrating a process facilitating the operation of a standby switch in an ISSU virtual switching stack, according to one aspect of this application, is presented. During operation, the switch can stop the local management daemon based on an instruction to the hot patching process (operation 502) and install the binary file of the new switch image, excluding the line card daemon, on the local switch (operation 504). The switch can then restart the database server, start the database with the new schema, and synchronize with the previous instance (operation 506). The switch can remove the previous instance of the local database (operation 508).

[0069] The switch can restart the local management daemon process (operation 510). Subsequently, the switch can receive a snapshot of the controller database (operation 512) and generate a hot-start file for the line card hardware status (operation 514). The switch can stop the line card daemon process based on instructions for the hot-patching process and install the binary file for the line card daemon process (operation 516). The switch can then restart the line card daemon process and tune its status according to the hot-start file (operation 518).

[0070] The switch can resume control of the line card from the director switch (operation 520) and synchronize the local database with the director database (operation 522). The switch can determine whether a failover is detected (operation 524). The switch can continue to wait until a failover is detected. On the other hand, when a failover is detected, the switch can initiate a takeover from the director switch through the failover (operation 526). The switch can then change its role to the director switch and start managing the daemon in the director mode (operation 528).

[0071] Figure 5B A flow diagram illustrating a process of facilitating a member switch in a virtual switch stack of an ISSU according to an aspect of the present application is presented. During operation, a switch can stop a local management daemon according to an indication of a hot patch process (operation 552) and install binary files of a new switch image on the local switch except for a line card daemon (operation 554). The switch can then restart a database server, start a database with a new schema, and synchronize with a previous instance (operation 556). The switch can remove the previous instance of the local database (operation 558). The switch can restart the local management daemon (operation 560).

[0072] Subsequently, the switch can generate a hot start file of a line card hardware state (operation 562). The switch can stop a line card daemon according to an indication of a hot patch process and install binary files for the line card daemon (operation 564). The switch can then restart the line card daemon and tune the state according to the hot start file (operation 566). The switch can connect the line card daemon to a standby switch for providing control (operation 568). The switch can determine whether a failover is detected (operation 570). The switch can continue to wait until a failover is detected. On the other hand, when a failover is detected, the switch can connect to a new director switch (e.g., using a control IP address) (operation 572).

[0073] Figure 6An example of a switch that supports efficient port reconfiguration based on independent data and control planes is illustrated in accordance with an aspect of the application. In this example, switch 600 can include a plurality of communication ports 602, a packet processor 610, and a storage device 650. Switch 600 can also include a switch hardware 660 (e.g., processing hardware of switch 600 such as an ASIC chip) that includes information based on which switch 600 processes packets (e.g., determines an output port for a packet). In other words, switch hardware 660 includes switch circuitry for switch 600. Packet processor 610 can extract and process header information from a received packet. Packet processor 610 can identify a switch identifier (e.g., a MAC address and / or an IP address) associated with switch 600 in a header of a packet.

[0074] Communication ports 602 can include inter-switch communication channels for communicating with other switches and / or user devices. The communication channels can be implemented via conventional communication ports and based on any open format or proprietary format. Communication ports 602 can include one or more Ethernet ports that are capable of receiving frames encapsulated in Ethernet headers. Communication ports 602 can also include one or more IP ports that are capable of receiving IP packets. The IP ports are capable of receiving IP packets and can be configured with IP addresses. Packet processor 610 can process Ethernet frames and / or IP packets. Respective ports of communication ports 602 can function as ingress ports and / or egress ports.

[0075] Switch 600 can maintain a database 652 (e.g., in storage device 650). Database 652 can be a relational database and can run on one or more Database Management System (DBMS) instances. Database 652 can store information associated with routing, configuration, and interfaces of switch 600. Switch 600 can include an ISSU logic block 630 that can facilitate ISSU of switch 600. ISSU logic block 630 can include an upgrade coordinator logic block 632, an SMF logic block 634, a hot patch logic block 636, and a data path coordinator logic block 638. Logic blocks 632, 634, 636, and 638 can correspond to upgrade coordinator 152, SMF 154, hot patch process 156, and data path coordinator 158 of FIG. 1, respectively. Figure 1B

[0076] ​The upgrade coordinator logic block 632 can include processes for coordinating ISSU in a virtual switching stack that includes the switch 600. The hot patch logic block 636 can install binary files from a new switch image on the switch 600. The SMF logic 634 can migrate a database 652 from an older version to a newer version. Thus, the SMF 154 can upgrade the schema of the database 652. Further, the data path coordinator 638 can upgrade line card daemons of the switch 600 without impacting traffic flow through the line cards, which can provide a subset of the ports 602.

[0077] The switch 600 can also include a stack logic block 640, which can operate the switch 600 as a member of a virtual switching stack. The stack logic block 640 can include a conductor logic block 642 and a backup logic block 644. The conductor logic block 642 can allow the switch 600 to operate as a conductor switch of the stack. Further, the backup logic block 642 can allow the switch 600 to operate as a backup switch of the stack and facilitate failover when needed.

[0078] One aspect of the technology can provide a system for facilitating in-service software upgrade (ISSU) for a switch in a virtual switching stack, the virtual switching stack including a plurality of switches operating on a unified control plane. During operation, the system can initiate the ISSU on a switch based on a plurality of phases for a new switch image, the plurality of phases facilitating uninterrupted traffic flow via the virtual switching stack. The system can upgrade, in a first phase, a first set of daemons of the switch based on the new switch image, the first set of daemons managing operation of the switch. The system can also upgrade, in the first phase, a database stored on the switch based on the new switch image. The database can store operational information of the switch, the switch forwarding traffic in a network based on the operational information. The system can further upgrade, in a second phase, a second set of daemons of the switch based on the new switch image, the second set of daemons configuring forwarding information about forwarding hardware of the switch and facilitating data plane operations for the switch. The forwarding information configured on the forwarding hardware can remain unchanged during the upgrade. Subsequently, the system can configure the upgraded second set of daemons to obtain control plane information from a backup switch serving as a backup for a conductor switch for the virtual switching stack, thereby upgrading the switch without interrupting traffic at the switch. The conductor switch can facilitate the unified control plane of the virtual switching stack.

[0079] In one variation of the aspect, the switch operates as a backup switch. The system can upgrade, in a third phase, a role of the switch to a new conductor switch for the virtual switching stack.

[0080] In one variant of this aspect, upgrading the database stored on the switch can include transitioning the database to a new version that operates based on the new architecture. The system can then synchronize the new version of the database with the previous version of the database.

[0081] In another variant, the system can upgrade, in the first phase, a database server that manages operations of the database based on the new switch image.

[0082] In another variant, the system can, in the second phase, take a snapshot of a second database of the conductor switch. Here, the second database operates based on the previous version. The system can then synchronize the new version of the database with the snapshot.

[0083] In one variant of this aspect, the system can use forwarding hardware of the switch to forward traffic based on the forwarding information while upgrading the second set of daemons.

[0084] In one variant of this aspect, the system can store, in the second phase, state information of the forwarding hardware in a state file. The system can then tune the state information based on the state file for the upgraded second set of daemons.

[0085] In one variant of this aspect, the switch can operate as a member switch of a virtual switching stack. The system can detect, in the third phase, a failover from the conductor switch to a backup switch. The system can then connect to the backup switch for unified control plane of the associated virtual switching stack.

[0086] Another aspect of the technology can provide a system for facilitating an in-service software upgrade (ISSU) for a switch in a virtual switching stack, the virtual switching stack comprising a plurality of switches operating on a unified control plane. During operation, the system can initiate the ISSU on the switch based on a plurality of phases for a new switch image, the plurality of phases facilitating uninterrupted traffic flow via the virtual switching stack. The system can instruct, in a first phase, a remote switch to upgrade a first set of daemons of the remote switch based on the new switch image, the first set of daemons managing operations of the remote switch. The system can also instruct, in the first phase, the remote switch to upgrade a remote database stored on the remote switch based on the new switch image. The remote database can store operational information of the remote switch, the switch forwarding traffic in a network based on the operational information. The system can also upgrade, in a second phase, a second set of daemons of the switch based on the new switch image, the second set of daemons configuring forwarding information about forwarding hardware of the switch and facilitating data plane operations for the switch. The forwarding information configured on the forwarding hardware can remain unchanged during the upgrade. Subsequently, the system can configure the upgraded second set of daemons to obtain control plane information from a standby switch functioning as a backup to a conductor switch for the virtual switching stack, upgrading the switch without interrupting traffic at the switch. The conductor switch can facilitate the unified control plane of the virtual switching stack.

[0087] In one variation of this aspect, the switch operates as the conductor switch. The system can upgrade, in a third phase, the first set of daemons of the switch based on the new switch image. The system can also upgrade, in the third phase, a local database stored on the switch based on the new switch image.

[0088] In another variation, the system can trigger, in the third phase, a failover to hand over management of the unified control plane to the standby switch.

[0089] In another variation, upgrading the local database stored on the switch can include transitioning the local database to a new version operating based on a new architecture. The system can then synchronize the local database with a database stored on the standby switch.

[0090] In another variation, the system can upgrade, in the third phase, a database server managing the database based on the new switch image.

[0091] In another variation, the system can generate, in the second phase, a snapshot of the local database and send the snapshot to the conductor switch.

[0092] In one variation of this aspect, the system can use the forwarding hardware of the switch to forward traffic based on the forwarding information while upgrading the second set of daemons.

[0093] In one variation of this aspect, the system can store state information of the forwarding hardware in a state file in the second phase. The system can then tune the state information based on the state file for the upgraded second set of daemons.

[0094] The data structures and code described in this detailed description are typically stored in a computer-readable storage medium, which can be any device or medium that can store code and / or data for use by a computer system. Computer-readable storage media includes, but is not limited to, volatile memory, non-volatile memory, magnetic storage devices, and optical storage devices such as magnetic disks, magnetic tapes, CDs (compact discs), DVDs (digital versatile discs or digital video discs), or other medium capable of storing computer-readable media now known or later developed.

[0095] The methods and processes described in the detailed description section can be implemented as code and / or data stored in a computer-readable storage medium, which can be executed by a computer system. When the computer system reads and executes the code and / or data stored on the computer-readable storage medium, the computer system performs the methods and processes embodied as data structures and code and stored within the computer-readable storage medium.

[0096] The methods and processes described herein can be executed by, and / or included in, hardware modules or apparatus. These modules or apparatus can include, but are not limited to, application-specific integrated circuit (ASIC) chips, field-programmable gate arrays (FPGAs), dedicated or shared processors for a particular use, and / or other programmable logic devices now known or later developed. When the hardware modules or apparatus are activated, they perform the methods and processes included within them.

[0097] The foregoing description of embodiments of the present application has been presented for the purposes of illustration and description. It is not intended to be exhaustive or to limit the disclosure to the precise form disclosed. Many modifications and variations are possible in light of this disclosure. It was chosen to present the described embodiments in order to provide an understanding of the principles of the application. The scope of the present application is defined by the appended claims.

Claims

1. A method for facilitating in-service software upgrade (ISSU) of a service, comprising: initiating, for a new switch image, the ISSU for a switch in a virtual switching stack based on a plurality of phases that facilitate uninterrupted traffic flow via the virtual switching stack, wherein the virtual switching stack comprises a plurality of switches operating on a unified control plane; in a first phase, upgrading, based on the new switch image, a first set of daemons of the switch that manage operation of the switch; in the first phase, upgrading, based on the new switch image, a database stored on the switch, wherein the database stores operational information of the switch based on which the switch forwards traffic in a network; in a second phase, upgrading, based on the new switch image, a second set of daemons of the switch that configure forwarding information about forwarding hardware of the switch and facilitate data plane operations for the switch, wherein the forwarding information configured on the forwarding hardware remains unchanged during the second phase the second set of daemons are upgraded; configuring the upgraded second set of daemons to acquire control plane information from a standby switch that serves as a backup for a conductor switch for the virtual switching stack, wherein the conductor switch facilitates the unified control plane of the virtual switching stack; and in response to detecting a manually triggered failover from the conductor switch to the standby switch, connecting to the standby switch for associating the unified control plane of the virtual switching stack.

2. The method of claim 1, further comprising: in a third phase, upgrading a role of the standby switch to a new conductor switch for the virtual switching stack.

3. The method of claim 1, wherein upgrading the database stored on the switch comprises: transitioning the database to a new version that operates based on a new schema; wherein the method further comprises initiating table synchronization for the database from a previous version to the new version.

4. The method of claim 3, further comprising: in the first phase, upgrading, based on the new switch image, a database server that manages the operation of the database.

5. The method of claim 3, further comprising: in the second phase, acquiring a snapshot of a second database of the conductor switch, wherein the second database operates based on the previous version; and synchronizing the snapshot with the new version of the database.

6. The method of claim 1, further comprising: in upgrading the second set of daemons, forwarding traffic using the forwarding hardware of the switch based on the forwarding information.

7. The method of claim 1, further comprising: in the second phase, storing state information of the forwarding hardware in a state file; and tuning, by the upgraded second set of daemons, the state information based on the state file.

8. A non-transitory computer-readable storage medium storing instructions that, when executed by a computer, cause the computer to perform a method comprising: initiating, for a new switch image, an in-service software upgrade (ISSU) for a switch in a virtual switching stack based on a plurality of phases that facilitate uninterrupted traffic flow via the virtual switching stack, wherein the virtual switching stack comprises a plurality of switches operating on a unified control plane; in a first phase, upgrading, based on the new switch image, a first set of daemons of the switch that manage operation of the switch; in the first phase, upgrading, based on the new switch image, a database stored on the switch, wherein the database stores operational information of the switch based on which the switch forwards traffic in a network; in a second phase, upgrading, based on the new switch image, a second set of daemons of the switch that configure forwarding information about forwarding hardware of the switch and facilitate data plane operations for the switch, wherein the forwarding information configured on the forwarding hardware remains unchanged during the second phase in which the second set of daemons are upgraded; configuring the upgraded second set of daemons to obtain control plane information from a standby switch that serves as a backup for a conductor switch for the virtual switching stack, wherein the conductor switch facilitates the unified control plane of the virtual switching stack; and in response to detecting a manually triggered failover from the conductor switch to the standby switch, connecting to the standby switch for associating the unified control plane of the virtual switching stack.

9. The non-transitory computer readable storage medium of claim 8, wherein upgrading the database stored on the switch comprises: transitioning the database to a new version that operates based on a new schema; wherein the method further comprises initiating table synchronization for the database from a previous version to the new version.

10. The non-transitory computer-readable storage medium of claim 8, wherein the method further comprises: in the second phase, storing state information of the forwarding hardware in a state file; and tuning, by the upgraded second set of daemons, the state information based on the state file.

11. The non-transitory computer-readable storage medium of claim 8, wherein the method further comprises: forwarding traffic using the forwarding hardware of the switch based on the forwarding information while upgrading the second set of daemons. in response to detecting a manually triggered failover from the conductor switch to the standby switch, connecting to the standby switch for associating the unified control plane of the virtual switching stack. transitioning the database to a new version that operates based on a new schema; wherein the method further comprises initiating table synchronization for the database from a previous version to the new version.

10. The non-transitory computer-readable storage medium of claim 8, wherein the method further comprises: in the second phase, storing state information of the forwarding hardware in a state file; and tuning, by the upgraded second set of daemons, the state information based on the state file. forwarding traffic using the forwarding hardware of the switch based on the forwarding information while upgrading the second set of daemons. in response to detecting a manually triggered failover from the conductor switch to the standby switch, connecting to the standby switch for associating the unified control plane of the virtual switching stack. transitioning the database to a new version that operates based on a new schema; wherein the method further comprises initiating table synchronization for the database from a previous version to the new version.

Images