CN104813617A - Network node and method for determining whether to issue a management action to trigger a virtual rack split alarm in an operable node of a virtual rack system - Google Patents

Abstract

The virtual chassis system includes a plurality of network nodes configured with a master virtual chassis address. The network nodes are connected via Virtual Fabrication Links (VFLs), which provide connections for exchanging packets between the network nodes. The virtual rack system is operable to provide an alert to help prevent a virtual rack split event in response to an administrative action. The topology of the virtual chassis system is analyzed to determine the possible impact of one or more management actions. Based on this analysis, an alert is generated when a management action that may directly or indirectly result in virtual rack splitting is requested.

Description

Network node and method for determining whether to issue a management action to trigger a virtual rack split alarm in an operable node of a virtual rack system

technical field

The present invention relates generally to data networks, and more particularly to systems and methods for providing topology redundancy and resiliency between nodes of one or more data networks.

Background technique

A data network includes various computing devices such as networked personal computers, IP telephony devices or servers that communicate with each other and/or with various other network elements or remote servers connected to the network. For example, data networks may include, but are not limited to, Metro Ethernet or Enterprise Ethernet networks that support multiple applications including, for example, Voice over IP (VoIP), data, and video applications. Such networks regularly include interconnected nodes, often referred to as switches or routers, for routing traffic through the network.

One of the key challenges facing data networks is the need for network resiliency, the ability to maintain high availability despite possible component failures, link failures, or similar conditions. High availability is key to providing satisfactory network performance. Network resiliency can be obtained partly through topology redundancy, that is, by providing redundant nodes (and components within redundant nodes) and multiple physical paths between nodes to prevent single point of failure, and partly through L2/L3 protocols in The redundancy is utilized to converge on alternate paths to switch/route traffic through the network in the event of a failure. It will be appreciated that detection and aggregation times must occur quickly (advantageously, less than a second) in the network to enable seamless transitions to alternate paths. Various types of network topologies are implemented within the network to provide redundancy between network elements, such as ring networks, partial mesh networks, full mesh networks, hub networks, and the like. Aggregation times and redundancy between network elements typically vary depending on the type of network implemented in the network.

The architecture of network elements is also variable and affects the resilience of the network. For example, various node architectures include single switching units, stackable switching units, multi-socket rack-based network units, and more. Typically, one of these types of node architectures is selected and implemented as a type of network topology based on cost and network requirements. However, once implemented, it is sometimes difficult to upgrade or transition from one network topology type to another. It is also difficult to switch from one type of node architecture to another within a network topology or to combine various types of node architectures within one network.

Accordingly, what is needed is a system and method for providing resiliency between architectures with one or more different types of nodes within one or more different types of network topologies.

Description of drawings

Figures 1a-c show a schematic block diagram of an embodiment of a virtual rack system according to the present invention;

FIG. 2 shows a logic flow diagram of an embodiment of a network topology discovery process in a virtual rack system according to the present invention;

Fig. 3 shows a schematic block diagram of an embodiment of a topology database in a network node of a virtual chassis system according to the present invention;

Fig. 4 shows a schematic block diagram of an embodiment of a network node in a virtual chassis system according to the present invention;

5 shows a schematic block diagram of an embodiment of a network interface module of a network node of a virtual chassis system according to the present invention;

6 shows a schematic block diagram of an embodiment of a prepended header of a packet in a virtual chassis system according to the present invention;

FIG. 7 shows a schematic block diagram of an embodiment of packets flowing through network nodes in a virtual chassis system according to the present invention;

Fig. 8 shows a schematic block diagram of an embodiment of a virtual rack management application according to the present invention;

Fig. 9 shows a schematic block diagram of an embodiment of master (master) address reservation (retention) in the virtual rack system according to the present invention;

Fig. 10 shows a schematic block diagram of an embodiment of master address release in a virtual rack system according to the present invention;

Fig. 11 shows a schematic block diagram of an embodiment of a failure of a primary network node in a virtual rack system according to the present invention;

Fig. 12 shows a schematic block diagram of an embodiment of a VFL fault in a virtual rack system according to the present invention;

FIG. 13 shows a logic flow diagram of an embodiment of a method for recovering from a failure of a primary network node in a virtual rack system according to the present invention;

14 shows a logic flow diagram of an embodiment of a method for generating one or more reset lists in a virtual rack system according to the present invention;

FIG. 15 shows a schematic block diagram of an embodiment of generating a reset list in the virtual rack system according to the present invention; and

FIG. 16 shows a logic flowchart of an embodiment of a method for generating a network node reset list in a virtual rack system according to the present invention;

Fig. 17 shows a schematic block diagram of another embodiment of generating a reset list in the virtual rack system according to the present invention;

18 shows a logic flow diagram of an embodiment of a method for generating a network interface module reset list and a VFL member port reset list in a virtual rack system according to the present invention;

19 illustrates a logic flow diagram of an embodiment of a method for handling management actions to help prevent virtual rack splits in a virtual rack system according to the present invention; and

20 illustrates a logic flow diagram of an embodiment of a method of handling management actions for configuration of one or more parameters to help prevent virtual rack splits in a virtual rack system in accordance with the present invention.

Detailed ways

The following standards are involved in this application and are hereby incorporated by reference: 1) Link Aggregation Control Protocol (LACP), which was previously added to Clause 43 of the IEEE 802.3 standard by the IEEE 802.3ad task group in March 2000, and Currently incorporated in IEEE 802.1AX-2008, November 3, 2008; and 2) IEEE Std. 802.1Q, Virtual Bridged Local Area Networks, 2003 edition.

Figure 1a illustrates an embodiment of a virtual chassis system 100 comprising a plurality of network nodes 110 operatively coupled by a collective of dedicated links for communicating control and addressing information, referred to as Virtual Fabric Link (VFL) 120 . The VFL 120 and its operation are described in detail in U.S. Patent Application No. 13/010,168, filed January 20, 2011, entitled "SYSTEM AND METHOD FOR MULTI-CHASSIS LINKAGGREGATION," which pending application is hereby incorporated for all purposes incorporated by reference and made a part of this US utility patent application. VFL 120 provides connections between network nodes 110 for exchanging information related to traffic forwarding, MAC addressing, multicast streams, Address Resolution Protocol (ARP) tables, Layer 2 control protocols (e.g. spanning tree, Ethernet loop protection, logical link detection protocol), routing protocols (such as RIP, OSPF, BGP), and the status of network nodes and external links.

In an embodiment, multiple network nodes 110 work as a single virtual network node with unified management capabilities. A master network node such as network node 110 a is selected, and the local MAC address of master network node 110 is adopted by other network nodes 110 as the master MAC address of virtual rack system 100 . External nodes 112 use the primary MAC address to address network nodes 110 in virtual chassis system 100 . Likewise, network node 110 operates transparently with external node 112 and is viewed by external node 112 as a single logical device.

External nodes 112 are operatively coupled to one or A plurality of network nodes 110 . To provide enhanced resiliency and remove single or even two points of failure, VC-LAG 114 operatively couples external nodes to two or more network nodes 110 in virtual chassis system 100. External nodes can use load balancing techniques to distribute traffic over available VC-LAG links 114 . For example, one of the physical links of the physical link VC-LAG 114 is selected by an external node to be based on a load-balancing algorithm (typically including hashing on source and destination Internet Protocol (IP) or Media Access Control (MAC) address information. column function) to transmit packets for more efficient use of bandwidth.

During normal operation, the network nodes 110 within the virtual chassis system share a primary MAC address for use as system identification for many kinds of layer 2 and layer 3 protocols. For example, spanning tree protocol and LACP protocol use the primary MAC address as the identifier of the virtual rack system 110 . Internet Protocol (IP) routing also utilizes the primary MAC address to identify the virtual rack system 100 to external network elements in the network, e.g. peers use the MAC address as the Ethernet destination for packets destined for the virtual rack system 100 address. Likewise, network nodes 110 in virtual chassis system 100 are viewed by external network nodes 112 as a single logical node. Furthermore, the network nodes 110 in the virtual chassis system 100 are managed as a single node with a unified management, operation and maintenance management system.

Since the network nodes 110 in the virtual chassis system 100 are viewed as a single logical device by the external nodes 112 , the external nodes 112 are operable to actively forward traffic on all links of the VC-LAG 114 . This feature enables multiple homing from external nodes 112 to network nodes 110 without spanning tree protocol between external nodes and network nodes, while also facilitating carrier-level of edge uplink failures as well as network node 110 failures Detection and aggregation time. Another advantage of the active forwarding mode for all VC-LAG 114 uplinks of the virtual chassis system 100 is the increased efficiency of VC-LAG 114 link bandwidth usage.

In the virtual chassis system 100, network nodes 110 are assigned globally unique identifiers called chassis identifiers or chassis IDs. Within virtual chassis system 100, network node 110 assigns an internal VFL identifier (VFID) to each VFL 120 it configures. Since the VFID of the VFL is used for the internal identification and configuration of the VFL 120, the network node 110 may assign to the VFL 120 a VFID that is the same as or different from the VFID assigned to the VFL 120 by another network node 110. VFL 120 provides connections for exchanging information between network nodes 110 related to traffic forwarding, MAC addressing, multicast streams, Address Resolution Protocol (ARP) tables, Layer 2 control protocols (such as spanning tree, Ethernet loop protection, logical link detection protocol), routing protocols (such as RIP, OSPF, BGP), which are described in detail in U.S. Patent Application No. 13/010,168 "SYSTEM AND METHOD FOR MULTI- CHASSIS LINKAGGREGATION". In an embodiment, synchronization of layer 2 address tables, such as media access control (MAC) address tables, between network nodes 110 is driven by packet flow on layer 2 via VFL 120 and by a periodic keep-alive mechanism through which According to the periodic keep-alive mechanism, a network node 110 with a given MAC address floods a specific packet carrying such a MAC address as a source address. The synchronization mechanism also needs to implement a standard MAC flushing mechanism to handle the situation where the network node 110 or some of its components go down. MAC address source learning on the VFL120 is achieved by flooding of unknown destination MAC addresses. During the source learning process, the network nodes 110 exchange packets on the VFL 120 with a preamble header that includes the source MAC address and associated hardware device information, such as the source chassis ID, source network interface identifier, and source Port identifier information. The network nodes 110 use this information to maintain synchronized MAC address tables using minimal messaging based MAC table synchronization. With synchronized MAC address tables, network nodes 110 are operable to process and forward packets between network nodes 110 in virtual chassis system 100 .

Figure 1a shows network nodes 110 coupled in a partial mesh network topology. However, the network nodes 110 in the virtual chassis system 100 can be coupled in any one of various types of network topologies without affecting the operation of the virtual chassis system 100 . FIG. 1 b shows a virtual chassis system 100 with a plurality of network nodes 110 coupled by VFLs 120 configured in a ring network topology. Figure 1c shows a virtual chassis system 100 with a plurality of network nodes 110 configured in a hub and spoke or star network topology. Other network topologies such as linear, tree, full mesh, hybrid, etc. that virtual chassis system 100 also supports are not described here. To support multiple different types of network topologies, the network nodes 110 in the virtual chassis system 100 are operable to perform a network topology discovery process.

FIG. 2 shows a logic flow diagram of an embodiment of the network topology discovery process 130 in the virtual rack system 100 . This process is performed by the active network nodes 110 in the virtual chassis system 100 upon startup, restart, indication of a state change in the network, or at predetermined time periods. In step 132, the network node 110 detects that it is operating in virtual chassis mode. For example, one or more parameters of the network node 110 are configured to indicate the mode of operation of the virtual chassis. The network node 110 detects that the parameter indicates virtual chassis mode operation (rather than, for example, stand-alone mode or multi-chassis mode). Next in step 134, the network node 110 executes one or more control protocols to discover other network nodes 110 in the virtual chassis system 100 and exchange topology and configuration information. Network nodes 110 use this information to build a topology database for virtual chassis system 100 . The topology database includes: identification information of other network nodes 110 (e.g., local MAC address, rack identifier), identification information of the network interface hosting the active VFL 120 (or other active inter-switch link), identification information of the VFL 120 and associated member ports on the network node 110 . In this way, the network nodes 110 know the active connections between the network nodes 110 in the virtual chassis system 100 and the configuration information of other network nodes 110 . Table 1 below is an example of the topology database of the network node 110a after the discovery phase, eg Chassis ID=1 in this example. Table 1 includes exemplary information stored in the topology database, but other information and data not shown may also be included in the topology database. Additionally, the topology database may be stored in a separate database or table or combined with other tables or databases in the network node 110 .

Table 1

In step 136 of FIG. 2 , a master network node is selected to perform management and other tasks of the virtual chassis system 100 . The local MAC address of the master network node is then adopted by the other network nodes 110 . Table 2 below is an example of the topology database for the selected master network node 110 with Chassis ID=1. As shown in Table 2, in the topology database, the network node with rack ID=1 is represented as having a master role and the other nodes are represented as having a slave role.

Table 2

The selection of the master network node 110 is based on a prioritized list of parameters including rack priority, up time, rack ID and rack MAC address. The uptime parameter may give priority to network nodes 110 that have been operating longer. The Rack Priority parameter is a user-configurable priority that defines the user preference of the master network node 110 regardless of Rack ID or uptime. The use of various parameters increases the flexibility in the selection of the master network node 110 . The rack group parameters shown in the topology database identify the virtual rack system 100 . One or more additional virtual rack systems 100 with different rack group identifications may also operate in the network. The topology database also identifies the active or master control manager module (CMM) in the network node 110 and the chassis type of the network node 110 .

In step 138 of the network topology discovery process 130 , the network node 110 executes one or more protocols to monitor the connections in the virtual chassis system 100 and the state or condition of the network node 110 . The current state of the network nodes 110 is maintained in the topology database. A detected state change of the network nodes 110 in the virtual chassis system 100 may initiate a change of routing, a change of master node, and the like. Through topology self-discovery and monitoring of network nodes 110, virtual chassis system 100 is operable to support multiple different types of network topologies with minimal pre-configuration and intervention.

FIG. 3 shows an example of the topology database 144 of the network nodes 110 in the virtual chassis system 100 after the master network node 110 is selected. In this example, network node 110a is employed as the master network node, and network nodes 110b and 110c are slave nodes. The local MAC address of network node 110a (eg, primary MAC address=A) is adopted by network nodes 110a-c as the virtual chassis MAC address. In addition, the primary MAC address (MAC=A) is adopted as the application MAC address for the management application.

The virtual chassis system 100 is also operable to include network nodes 110 having one or more different types of node architectures, such as single module, stackable, or multi-socket chassis-based architectures. Fig. 4 shows a schematic block diagram of an embodiment of a network node 110 in a virtual chassis system 100 with different types of node architectures. In this example, network node 110a has a multi-slot chassis-based architecture with multiple network interface modules 152a-n. Typically, multi-slot rack-based architectures share an enclosure, control management modules (CMMs) 150a-b, and a common power supply with one or more network interface modules (NIMs) 152a such as line cards or port modules -n. The network interface module 152n includes a queuing module 212 and a switching module 210 and these modules are connected by a fabric switch 214 integrated into the backplane of the rack.

The network node 110b in this example has a stackable node architecture and includes a plurality of network elements 140a - n coupled by backplane connections 142 . Each network element 140a-n is operable as an independent node and contains its own enclosure, control management module (CMM) 150, switching module 210, queuing module 212, and power supply. In some stacking architectures, one network unit (network unit 140a in this example) is designated as the primary or master unit of the stack for management purposes.

The network node 110c has a single modular node architecture, such as a single stackable unit 140 or alternatively, a multi-socket rack-based architecture with a single network interface module 152 .

Network nodes 110a-c correspond to one or more of network elements 110 in virtual chassis system 100 in FIGS. 1a-c. For example, virtual chassis system 100 is operable to include network nodes 110 with only multi-socket chassis-based node architectures or to include network nodes 110 with only stackable node architectures or to include node architectures with two or more types A combination of network nodes 110, where two or more types are based, for example, on a multi-socket rack architecture, a stackable node architecture, and a single module node architecture. Although not shown, virtual chassis system 100 may also include network nodes 110 comprised of other types of node architectures and configurations.

Network node 110a and network node 110b are operatively coupled by VFL 120a. Network nodes 110a and 110b designate VFL 120a with an internal VFL identifier (VFID), eg VFID=3 for network node 110a and VFID=0 for network node 110b as shown in FIG. 3 . Network node 110a and network node 110c are operatively coupled by VFL 120b. Network nodes 110a and 110c identify VFL 120b with an internal VFL identifier (VFID), eg VFID=2 for network node 110a and VFID=1 for network node 110c as shown in FIG. 3 . In addition, network nodes 110a-c are also operatively coupled to one or more other network nodes 110 via additional VFLs 120, as shown in FIGS. 1a-c. VFL 120a between network nodes 110a and 110b is described as a generalization of the operation and configuration of VFL 120 between different network nodes 110 in virtual chassis system 100 .

VFL 120a between network node 110a and network node 110b is operatively coupled to one or more VFL member ports in one or more switch modules 210. For redundancy in the event of failure of one or more ports, links, or modules, VFL 120a is operable to include a plurality of aggregated links using LACP or similar aggregation protocol generation. For example in FIG. 4, VFL 120a includes a first subset A of physical links between NIM 152a of network node 110a and stacked network elements 140a of network node 110b and a stacked A second subset B of physical links between network elements 140b.

Network nodes 110 are assigned unique chassis identifiers in virtual chassis system 100 . The chassis ID for each network node 110 is unique and global, and through topology discovery, a network node 110 can be aware of the chassis IDs of its peer network nodes 110 in the virtual chassis system 100 . Additionally, unique hardware device identifiers or module identifiers (MIDs) for various components such as the switch modules 210 and port interfaces in the network node 110 are generated to allow for local and remote management purposes. In an embodiment, the hardware device identifier MID of the switch module 210 has global meaning within the virtual chassis system, while MIDs for other components, such as the queuing module 212, may only have local meaning. For example, the hardware device identifier assigned to the switching module 210 may be known by other network nodes 110 , while the hardware device identifiers of other devices are restricted to the local network node 110 and have little meaning for other network nodes 110 . For example, the port interface of the switch module 210 is assigned a globally unique hardware device identifier, and the identifier includes a chassis ID, a switch module ID, and a port interface ID. In an embodiment, the network nodes 110 in the virtual chassis system operate in preamble mode to exchange data and control packets through the VFL 120.

Figure 5 shows a schematic block diagram of an embodiment of a network interface module (NIM) 152 operating in preamble mode in greater detail. Although network interface module 152 is shown, stackable network unit 140 or a single module network unit is operable to perform similar functions to operate in preamble mode. The switch module 210 includes a plurality of external ports 240 connected from the virtual chassis system 100 to the external nodes 112 . One or more of external ports 240 may include member ports for VC-LAG 114, LAG 116, single or other trunk groups, fixed links, and the like. External ports 240 may be of the same physical interface type, such as copper ports (CAT-5E/CAT-6), multimode fiber ports (SX), or single mode fiber ports (LX). In another embodiment, external port 240 may have one or more different physical interface types.

External ports 240 are assigned external port interface identifiers (port IDs), such as device port values, such as gport and dport values associated with switch module 210 . In an embodiment, the chassis ID of the network node 110, the MID of the switch module 210, and the external port interface identifier (port ID) are used as the global unique identifier. In another embodiment, a globally unique module identifier (MID) is assigned to the switch modules 210 of the network nodes of the virtual chassis system based on the chassis identifier. For example, exchange MIDs 0-31 are assigned to rack ID=1, exchange MIDs 32-63 are assigned to rack ID=2, etc. In this case, the globally unique switch MID and the external port identifier (port ID) are used as the globally unique identifier of the physical external port interface 240 in the network node 110 of the virtual chassis system 100 .

When a packet is received on external port 240, switch module 210 passes the packet to Prepend Header Interface (PPHI) 246, which adds a prepend header (or otherwise modifies the packet header) to include the Hardware Device Information (HDI) associated with the source and/or destination MAC address. In an embodiment, the preamble header may include other information such as packet priority and load balancing identifier. The PPHI performs a lookup procedure in the MAC/HDI forwarding table 250 in order to obtain the HDI information associated with the packet's MAC address. The MAC/HDI forwarding table 250 stored in the address table memory 248 includes a list of MAC addresses and associated hardware device information. The hardware device information uniquely identifies the network node 110, switch module 210, and/or port interface 240 used to route packets. The hardware device information includes, for example, the chassis ID of the switch module 210, the MID, and/or the port interface ID of the port 240 associated with the destination MAC address. The MAC/HDI forwarding table 250 may include one or more tables, such as source trunk mapping, trunk bit table, trunk group table, VLAN mapping table and so on. In an embodiment, MAC/HDI forwarding table 250 or portions thereof may be located in a queuing module of NIM 152 or other modules.

Based on the topology database 144, a VFL routing configuration table 254 is generated at the network node 110 to determine routing of unicast traffic. VFL Routing Configuration Table 254 includes a Chassis ID and an associated VFL ID (VFID). The VFID associated with the chassis ID identifies the VFL 120 in the virtual chassis system 100 for routing the packet to the network node 110 identified by the destination chassis ID. In another embodiment, when a globally unique module identifier (MID) is assigned to a switch module 210 of a network node 110 in a virtual chassis system 100, the VFL routing configuration table 254 includes a globally unique MID and an associated VFL ID ( VFID). In an embodiment, the VFL routing configuration table 254 is generated using a shortest path algorithm, a flow-based algorithm, or other types of routing algorithms. An example of a VFL routing configuration table 254 for the virtual chassis system 100 shown in FIG. 1 a is shown in Table 3 below.

table 3

Although MAC/HDI forwarding table 250 and VFL routing table 254 are shown as separate tables in address table memory 248, these tables may be combined or data from one of the tables may be included into the other table or these tables may be split into one or more other tables.

In an embodiment, the hardware device information HDI in the preamble header of the packet includes the outgoing VFID of the VFL port 252 associated with the destination rack ID, as shown in Table 3. The preamble header also includes hardware device information HDI related to the source port receiving the packet, such as the port interface ID, the MID of the switch module 210 and the rack ID. In an embodiment, additional information such as VLAN ID, packet type (multicast, unicast, broadcast), packet priority, and load balancing identifier is also added to the preamble header.

Packets with preamble headers are then sent to queuing module 212 for routing on fabric switch 214 . Based on the VFL routing configuration table 254, the queuing module 212 routes the packet with the preamble header to the switching module 210 connected to the outgoing VFL 120.

The queuing module 212 includes a packet buffer 260 , a queue management 262 for providing traffic and buffer management, and a global HDI address table 264 . The global HDI address table 264 maps outgoing VFL IDs to the appropriate queues in the queuing modules 212 of one or more of the other NIMs 15. For example, queuing module 212 switches packets to the appropriate egress queue(s) of one or more of VFL port interfaces 252 for transmission on egress VFL 120. In an embodiment, the determination of the egress queue corresponding to a particular VFL port interface is operatively based on a load balancing identifier in a preamble header.

Although switching module 210 and queuing module 212 are shown as separate integrated circuits or modules, one or more functions or components of these modules may be included in other modules or combined into optional modules or in one or more integrated circuits be realized.

FIG. 6 shows a schematic block diagram of an embodiment of a preamble header of a packet in the virtual chassis system 100 . Preamble header 300 includes fields for source HDI 302, destination HDI 304, VLAN ID 306, packet type 308, source MAC address 310, and destination MAC address 312. In an embodiment, the preamble header may also include a load balancing identifier 314 and a packet priority 316 . Destination HDI 304 includes, for example, a port identifier (device port (dport) and/or global port value (GPV)), the MID of the switch module 210, and/or the chassis of the destination network node 110 associated with the destination MAC address ID. The source HDI 302 includes, for example, a port identifier (device port (dport) and/or global port value (GPV)), the MID of the switch module 210, and/or the chassis ID of the source network node associated with the source MAC address. Load balancing identifier 314 is used by queuing module 212 to determine VFL member ports for transmission of packets on outgoing VFL 120 . Packet priority 316 is used by queuing module 212 to determine a particular priority queue.

FIG. 7 shows a schematic block diagram of an embodiment of a packet flowing through a network node 110 a to another network node 11 b in a virtual chassis system 100 . In this example, the external device 300 from the virtual rack system 100 having the source MAC address "MAC1" transmits a packet having the destination MAC address "MAC2". Network node 110a with chassis ID=1 in this example receives packets at external port interface 240 on switch module 210n, for example with MID=31, said external port interface 240 has for example port ID=2 . The switch module 210n extracts the destination MAC address MAC2 and performs an address table lookup in the MAC/HDI forwarding table 250 to determine the hardware device information (HDI) associated with the destination MAC address MAC2. The destination HDI may include, for example, a destination chassis ID and a device module identifier (MID) and port identifier associated with the destination MAC address. The destination HDI may also include identifiers of one or more other network nodes or hardware modules in the path to the destination device associated with the destination MAC address. When the destination MAC address is associated with another network node, eg, the destination rack ID is not a local rack ID, then the switch module 210 determines the outgoing VFL ID associated with the destination rack ID. The outgoing VFL ID may be added to the destination HDI in the preamble header. For the example shown in FIG. 5, VFL routing table 254 indicates that destination rack ID=2 is associated with VFL 120 having VFID=3.

The switching module 210n also includes in the preamble header the source hardware device information (HDI) related to the originating external port interface, for example, port ID=2. The source HDI may include one or more hardware device identifiers, such as the MID of the original switch module 210, the source port identifier, the MID of the source NIM 152, the source rack ID, and the like. Furthermore, in an embodiment, the preamble header includes a packet priority and a load balancing identifier determined based on parameters retrieved from the original packet (source MAC address, destination MAC address, source IP address, destination IP address).

The packet with the prepended header is sent to the queuing module 212n, which then determines the NIM 152 on the network node 110 to send the packet based on the destination HDI. When the destination HDI indicates a local external port interface on the network node (eg, based on the destination MID contained in the preamble header), the queuing module places the packet on an egress queue for transmission to the corresponding NIM 152 of the local external port interface. In another example shown in FIG. 5, when the destination HDI indicates that the packet needs to be sent on the VFL 120 to another network node 110 in the virtual chassis system 100, the queuing module determines the outgoing NIM 152 from the VFL ID to send The grouping. In this example, the queuing module determines that VFID=3 is operably coupled to NIM 152a and sends the packet with the prepended header to NIM 152a via fabric switch 214. In a load balancing approach, when multiple switching modules 210 are operatively coupled to egress VFL 120, the traffic to be transmitted may be distributed among multiple switching modules 210. In addition, the selection of VFL member ports (high priority queue, low priority, etc.) on the switch module 210 is operatively based on the load balancing identifier parameter carried in the pre-mounted header. The queuing module 212a on the NIM 152a receives packets with a pre-pending header and queues the packets for transmission on the VFL 120 with VFID=3. Switching module 210a then sends the packet on VFL 120 with VFID=3 to network node 110b with chassis ID=2 with a preamble header including source and/or destination HDI.

In an embodiment, the switch module 210a may change the preamble header prior to transmission on the VFL 120. For example, the switch module 210a may convert a locally meaningful destination HDI (eg, a gport value or a local hardware device identifier) to a globally meaningful HDI or remove the outgoing VFID from the header.

In an embodiment, the MAC/HDI forwarding table 250 in the NIM 152 is populated or updated in response to layer 2 packets flowing through the virtual chassis system 100. Since the prefix header includes source MAC address and source HDI information, the NIMS 152, such as the specific switch module 210 in an embodiment, can populate the MAC/HDI forwarding table 250 with this information. Switching module 210 is capable of synchronizing MAC/HDI forwarding table 250 between network modules 110 in virtual chassis system 100 by operating in preamble mode to switch layer 2 packets with source MAC address and source HDI on VFL 120 . Although MAC/HDI forwarding table 250 and VFL routing table 254 are described as being located within switching module 210 , these tables may alternatively or additionally be included within queuing module 212 n or other modules of network node 110 . In another embodiment, CMM 150 (primary and secondary) may also include MAC/HDI forwarding table 250 and VFL routing table 254.

FIG. 8 shows a schematic block diagram of an embodiment of a virtual chassis manager application or module 400 operable in the network node 110 of the virtual chassis system 100 . In an embodiment having a network node 110 based on a multi-socket rack node architecture, the virtual rack manager module 400 is comprised of a central management module (CMM) 150 (referred to as VCM-CMM 402) at the network node 110 and the The functions are distributed among the processing modules 266 (referred to as VCM-NIM 404) in the designated network interface module (NIM) 152 of the network node. In a stackable node architecture, a designated or master stackable network unit 140 operates the VCM-NIM 404. The use of a designated NIM 152 or stackable unit 140 avoids centralizing the functionality of the VCM module 400 on the CMM 150 only. An example of the distribution of functions of the virtual rack manager module 400 is shown in Table 4.

Table 4

In an embodiment, the VCM-CMM 402 includes an interface between the virtual chassis manager module 400 and the unit and/or network manager module 406 and to other applications 408 registered with the VCM module 400 operable on the network node 110 Interface. The virtual chassis manager module 400 notifies registered applications 408 when to operate in virtual chassis mode. More generally, the virtual chassis manager module 400 provides a wide range of notifications to inform interested applications of the status of the virtual chassis system in the local node environment and in other network nodes 110 of the virtual chassis system 100 . Some state information is driven by administrative configuration, while other state information is triggered by runtime decisions, either by network nodes individually or by multiple network nodes 110 in a virtual chassis system, when controlling data exchange, negotiation, and agreement made. The virtual chassis manager module 400 is also connected with a VLAN management application module 410, a spanning tree protocol (STP) application module 412, a source learning application module 414, a link aggregation application module 416 and a port manager application module 418 for These system components request services. For example, VCM 400 may request a VLAN manager to configure a VFL member port as a member of a control VLAN in order to allow setup of an inter-process communication channel between network nodes 110 in virtual chassis system 100.

VCM-NIM 404 performs module identification configuration (eg MID) of hardware modules. VCM-NIM 404 also interfaces with queue manager 262 in queuing module 212 to perform hardware device/queue mapping functions and inter-rack loop avoidance functions. The VCM-NIM 404 also includes a virtual shelf state function for control and management of the VFL 120. Virtual Organization Link Control manages and configures VFLs 120 and interfaces with port manager application module 418 to monitor and/or control the status of VFLs 120 and their corresponding member ports. It also tracks and updates the status of the VFL 120. The VCM-NIM 404 uses the standard LACP protocol or other similar protocols to track the state of each VFL member port and the link state of the physical layer. In addition to the LACP protocol, the Virtual Chassis Status Protocol performs periodic "keep alive" checks (hello protocol) in order to check the status and/or operability of components running on designated NIMs on both Virtual Chassis switches sex. All Virtual Chassis protocol packets must be assigned high priority in the system to avoid false/premature failure detections, as such premature failure detections can have very serious disruptive effects in the system. By running the virtual rack stateful protocol on the primary designated NIM 152, the backup designated NIM module can assume control of stateful protocol processing in the event of a failure.

VCM-CMM 402 and VCM-NIM 404 register with port manager application module 418 to receive port status and status link events about member ports and links of VFL 120. In another embodiment, the virtual chassis manager module 400 may include a port manager application module to monitor the port and link status of the VFL 120. The Virtual Chassis Manager module 400 tracks the operational state of the VFL 120 and processes events related to the VFL state, ie Aggregate Create/Delete Aggregate/Aggregate Up/Aggregate Down. The port management application module 418 provides link status notifications to both the VCM-CMM 402 and the VCM-NIM 404.

In an embodiment, a transmission control protocol is implemented in the virtual chassis system 100 to transport control protocol packets between designated NIMs 152 or stacked network elements 140 of the network nodes 110. Transmission Control Protocol is operable in network nodes 110 having different node architectures. For multi-socket rack-based node architectures, a designated NIM 152 with a designated processing module 266 operates the transmission control protocol, for example as part of the VCM-NIM 404. In a stackable node architecture, a designated or master stack network unit 140 operates the transmission control protocol.

The shelf supervisor module 420 provides an interface to the hardware of the network node 110 and controls the monitoring and startup or restart of various application modules, controls software reloading and software upgrades (e.g., in-service software upgrade ISSU), provides 406 provides a command line interface (CLI), and controls access to the state or image file of the network node's 110 system. During virtual rack mode, rack supervisor module 420 controls the boot sequence, controls software reload and ISSU, and provides an interface for accessing virtual rack parameters.

The configuration manager module 422 is operable to convert the operation of the network node 110 from a virtual chassis mode to a standalone mode or vice versa. The configuration manager module is also operable to configure the virtual chassis manager module 400 and the multi-chassis manager module 424 . The operation of the configuration manager module 422 and the operational states of the network node 110 are described in more detail below.

Network nodes 110 in virtual chassis system 100 may operate in multiple modes of operation, including virtual chassis mode, standalone mode, and multi-chassis (MC-LAG) mode. Depending on the mode of operation, various parameters and configurations are modified. Table 5 shows the assignment of chassis IDs to network nodes 110 depending on the mode of operation.

operating mode Min Rack ID Maximum Rack ID independent 0 0 Multi-rack (MCLAG) 1 2 virtual rack 1 N

table 5

In standalone mode, network node 110 is operated as a single node and uses its configured local MAC address instead of the global virtual chassis MAC address. As described in detail in U.S. Patent Application No. 13/010,168, filed January 20, 2011, entitled "SYSTEM AND METHOD FOR MULTI-CHASSISLINK AGGREGATION," in multi-chassis mode, two network nodes are configured as virtual Nodes, their MAC forwarding tables and ARP tables are synchronized, however they still act as separate bridges and routers, each of them using their own local rack MAC address. In the virtual rack mode as described herein, N network nodes are configured as virtual rack nodes in the virtual rack system 100 . A globally unique rack ID from 1 to N is assigned to each of the plurality of network nodes in the virtual rack system 100 .

When network node 110 is operating in standalone mode, port identifiers and configurations follow the format: 0/<slot>/<port>, where rack ID equals "zero" and slot identifies a multi-socket fabric or stackable network Each network interface module (NIM) 152 in unit 140, and port is the port interface identifier. When the network node 110 is operating in multi-chassis mode, the port configuration follows the format: <rack>/<slot>/<port>, where the rack ID is equal to 1 or 2 and represents the operating/current/running rack Rack ID. When the network node 110 is operating in virtual rack mode, the port configuration follows the format: <rack>/<slot>/<port>, where the rack ID is a number in the range 1, 2...N and represents the operation /current/running rack ID.

In the virtual rack system 100 , when a failure that causes a loss of communication with the main network node 110 is detected, a split or break occurs in the virtual rack system 100 . When the network nodes 110 in the virtual chassis system are split into two or more subsets, the topology of the virtual chassis system 100 and thus the services it provides can be severely affected. This condition is known as a virtual rack split or rupture. When the Virtual Chassis topology is split, the Virtual Chassis system 100 faces multiple problems due to multiple node reset events: duplicate MAC addresses, duplicate configurable resources (e.g. IP interfaces), loss of connectivity, management Lost access, and instability.

A virtual rack split may typically be triggered by a failure of one or more of the nodes 110, such as a power failure, hardware/software failure, in-service software upgrade, and the like. A virtual chassis split may also be triggered by one or more of the VFLs 120 coupled to the network node 110 becoming inoperable, e.g., a VFL 120 being physically broken, removed, brought down administratively, or due to A crash caused by a hardware/software failure related to a module hosting such a link or to the link itself. In an embodiment, when a virtual chassis split occurs between two subsets of the virtual chassis network 100, the first subset of network nodes 110 can no longer communicate with the master network node in the second subset. The remaining active network nodes in the first subset elect a new primary network node. In an embodiment, the remaining active network node retains the primary MAC address of the failed primary network node. In another embodiment, the remaining active network nodes adopt the local MAC address of the newly selected master network node as the new virtual rack MAC address of the virtual rack system 100 .

FIG. 9 shows a schematic block diagram of an embodiment of master address reservation in the virtual rack system 100 . The primary network node 110a is unable to communicate with the remaining nodes 110b, 110c in the virtual rack system 100 due to a functional breakdown or planned outage for maintenance or an inoperable VFL 120 link or other failure. The remaining network nodes 110b and 110c elect a new master network node, in this example network node 110b. In this embodiment, the remaining network nodes 110 b and 110 c retain the MAC address of the former master network node 110 a as the virtual rack MAC address of the virtual rack system 100 . The former master network node 110a is removed from the topology database 144 and MAC matrix of the remaining active network nodes 110b and 110c. This embodiment is referred to as primary MAC address reservation because the previous primary MAC address is reserved by the remaining active network node 110 as the virtual chassis MAC address.

FIG. 10 shows a schematic block diagram of an embodiment of master address release in the virtual rack system 100 . Primary network node 110a cannot communicate with the remaining nodes in virtual rack system 100 due to functional breakdown or planned outage for maintenance or inoperable VFL 120 link or other failure. The remaining network nodes 110b and 110c elect a new master network node, network node 110b in this example. In this embodiment, the remaining network nodes 110b and 110c release the previous master network node 110a MAC address as the virtual chassis MAC address. The remaining active network nodes 110 b and 110 c adopt the local MAC address of the newly selected primary network node 110 b as the virtual rack MAC address of the virtual rack system 100 . The former master network node 110a is removed from the topology database and MAC matrix of the remaining active network nodes 110b and 110c. This embodiment is referred to as a master MAC release due to the release of the inactive previous master MAC address as a virtual chassis MAC address.

The remaining network node 110 determines to reserve or release the MAC address of the inactive master network element based on one or more factors. For example, one factor is whether the MAC reservation feature is administratively enabled. Another factor is whether a change in the state of the primary network node causes a virtual rack split in the system, eg, the primary network node and/or one or more other nodes are still operating using the MAC address of the failed previous primary network node. A discovery or monitoring protocol or other type of control protocol is used to determine the pre- and post-failure topology of the primary network node to determine if a partition has occurred in the virtual chassis system. When a split in the virtual rack system has occurred, for example, the newly elected master network node determines that the previous master network node and/or one or more other nodes are still working, which releases the previous master network node as the virtual rack MAC address. MAC address. The newly selected master network node can also change the user port to the blocking state to prevent the duplicate operation of the two MAC addresses as the virtual rack MAC addresses.

FIG. 11 shows a schematic block diagram of an embodiment of a failure of a primary network node in the virtual chassis system 100 . In this example, master network node 110a has failed and is inoperable. The newly elected master network node 110b attempts to determine the status of the previous master network node 110a by executing one or more protocols (Hello protocol, ping, etc.), or may request a status update of the network node 110a from the cell manager module 406 . The newly elected master network node 110b attempts to differentiate between the failure of the VFL link 120a or the failure of the previous master network node 110a. When the newly elected master network node 110b determines that the previous master network node 110a has failed, e.g. it is no longer operational, the newly elected master network node 110b retains the MAC address of the previous master network node 110a as the virtual chassis MAC address , as shown in Figure 9. When the previous master network node 110a is removed from the active topology database 144, the newly selected master network node 110b retains the MAC address of the previous master node, and the rack supervisory module 420 starts the MAC reservation timer. The MAC retention timer is configurable and sets a predetermined period of time for the former master network node 110a to reset and become active. Once the predetermined period of time has elapsed, an alert message is generated by the newly elected master network node 110b if the previous master network node 110a is still inoperable. The virtual rack system manager may determine to issue a user command to release the reserved MAC address and adopt the newly selected local MAC address of the master network node 110 b as the virtual rack MAC address of the virtual rack system 100 .

FIG. 12 shows a schematic block diagram of an embodiment of a VFL failure in the virtual rack system 100 . In this example, the VFL 120a coupled to the primary network node 110a fails while the previous primary network node 110a remains operational. The newly elected master network node 110b attempts to determine the status of the previous master network node 110a by executing one or more protocols (Hello protocol, ping, etc.), or may request a status update of the network node 110a from the cell manager module 406 . The newly elected master network node 110b attempts to differentiate between the failure of the VFL link 120a or the failure of the previous master network node 110a. When the newly selected master network node 110b determines that the VFL 120a has failed but the previous master network node 110a is operational, the newly selected master network node 110b releases the MAC address of the previous master network node 110a, as shown in FIG. 10 . The remaining active network nodes 110 b and 110 c adopt the local MAC address of the newly selected primary network node 110 b as the virtual rack MAC address of the virtual rack system 100 . In addition, the newly elected primary network node 110b switches the user ports to the blocking state to prevent duplication of the two MAC addresses as virtual chassis MAC addresses. The release of the MAC address of the former master network node 110a will also affect other layer 2 and layer 3 services. For example, Spanning Tree Protocol and LACP may need to be reconfigured and/or restarted and layer 3 packets may need to be sent to neighboring nodes in response to a MAC address change.

FIG. 13 illustrates a logic flow diagram of an embodiment of a method 600 of recovering from a failure of a primary network node in a virtual chassis system 100 . At step 602, a loss of communication with a primary network node is detected in the virtual rack system 100 due to a functional breakdown or planned outage for maintenance or an inoperable VFL 120 link or other failure. The remaining network nodes in the virtual chassis system select a new master network node in step 604 . In step 606, the newly selected master network node determines whether to enable the MAC reservation function. If enabled, at step 608, the newly elected primary network node determines whether the failure caused a fragmentation of the virtual-chassis system, e.g., the primary network node and/or one or more other nodes are inoperable or still using the previous primary MAC address Work. When the split of the virtual rack does not occur, the remaining network nodes retain the MAC address of the previous master network node 110 a as the virtual rack MAC address of the virtual rack system 100 at step 610 . At step 612, a MAC reservation timer starts counting a predetermined period of time. In step 614, upon expiry of the predetermined time period, an alert message is generated by the newly selected master network node if the previous master network node 110a is still inoperable.

When the newly selected main network node determines that the virtual rack split has occurred, for example, the previous main network node is still working in step 608, or the MAC reservation function is disabled in step 606, then the newly selected main network node in step 616 is released The MAC address of the former primary network node as the virtual rack MAC address. In step 618 , the remaining active network nodes adopt the local MAC address of the newly selected master network node as the virtual rack MAC address of the virtual rack system 100 .

When a Virtual Chassis split occurs, the topology of the Virtual Chassis system and thus the services it provides to end users can be severely affected. When the topology of a virtual rack is split, the virtual rack system 100 faces multiple problems due to multiple switch reset events: duplicate MAC addresses, duplicate configurable resources (such as IP interfaces), loss of connectivity, Loss of management access, and instability. A virtual rack split may typically be triggered by a failure of one or more of the nodes 110, such as a power failure, hardware/software failure, in-service software upgrade, and the like. A virtual rack split can also be triggered by one or more of the VFLs 120 becoming inoperable, for example, a VFL 120 being physically snapped, removed, administratively collapsed, or due to a connection with the module or chain hosting such a link. The collapse caused by the hardware/software failure related to the road itself. One cause of a virtual rack split includes administrative actions, such as issuing an administrative command that resets or shuts down a portion of the virtual rack system resulting in a split topology. Other management actions that may trigger virtual rack splits include inconsistent configuration of parameters, such as a) configuring different control VLANs on different network nodes within the virtual rack topology; b) configuring Different hello intervals; c) configuring different rack groups on different network nodes within the topology of the virtual rack. Since the virtual chassis system 100 supports multiple network topologies and network nodes may be geographically separated, it is difficult to foresee the impact of management actions.

In an embodiment, methods and apparatus in the network node 110 provide alerts to help prevent administrative actions in the virtual chassis system 100 from directly or indirectly causing a virtual chassis split event. For example, management actions that may directly or indirectly result in virtual rack splitting include, inter alia: resetting a network node, resetting a network interface module 152 hosting one or more VFLs 120, bringing down a VFL 120, setting up a network node 110 Enter shutdown/non-service state and configure inconsistent parameters on different network nodes 110 . Additionally, indirect events arising from administrative actions that may directly or indirectly result in virtual rack splitting include, inter alia: switches being reset in response to ISSU (In-Service Software Upgrade) operations and hosting one or more The network interface module NIM 152 of the VFL 120 is brought down. In an embodiment, the current topology of the virtual chassis system 100 is analyzed to determine the possible impact of one or more management actions. Based on this analysis, alerts are generated when management actions are requested that may directly or indirectly result in virtual rack splitting.

FIG. 14 shows a logic flow diagram of an embodiment of a method 700 of generating one or more reset lists in the virtual rack system 100 . In step 702, the network nodes use one or more control protocols to discover other network nodes 110 in the virtual chassis system 100 and exchange topology and configuration information. The network nodes 110 use the topology information to build the topology database 144 of the virtual chassis system 100 described herein. The topology database includes, for example, the following types of topology information: identification information (e.g., local MAC address, chassis identifier) of other network nodes 110, network interface module NIM 152 hosting the VFL 120 (or other active inter-switch link) Identification information for the VFL 120 and its associated member ports on the managed network interface module NIM 152. The topology database 144 is maintained in the CMM 150 of the network node 110 and may be replicated in the cell manager module 406 operatively coupled to the network node 110 in the virtual chassis system 100. The description of the topology database 144 includes exemplary information, however other information and data not described herein may also be included in the topology database. Additionally, topology database 144 may be stored in a separate database or table or combined with other tables or databases in network node 110 .

In step 704 , the topology information is analyzed to determine one or more reset lists or structures representing the impact of one or more management actions on the virtual chassis system 100 . For example, the generated network node reset list includes a list of network nodes that, if individually reset, would trigger a virtual chassis split. It may also include a list of network nodes that need to be reset at the same time to prevent virtual racks in the system from splitting. The generated network interface module reset list includes a list of network interface modules 152 hosting active VFLs 120 and a status indicating whether resetting the network interface modules 152 will cause the virtual chassis to split. Other reset lists and structures not specifically described herein that represent the effect of one or more management actions on virtual chassis system 100 may also be generated.

In an embodiment, the reset list is accessed in response to one or more administrative actions to provide information on the possible effects of the administrative actions. For example, the reset list is analyzed for devices (network nodes, NIMs or port interfaces) affected by management actions such as reloading or reconfiguring the network node 110, reloading or reconfiguring Management commands such as setting the network interface module NIM 152, disabling the network interface module 152, shutting down the network node, executing ISSU, disabling the port interface, disabling the VFL 120, etc.

Processing of the management action continues when the reset list indicates that the management action will not cause the virtual rack to split. However, an alert is displayed when the reset list indicates that administrative actions may cause virtual rack splits. The alert includes an indication that a virtual rack split may occur, eg, in response to the administrative action. The alert may also include one or more recommendations to avoid virtual rack splits, for example, reset the intended device with one or more other devices (such as network nodes, NIMs or port interfaces) specified in the reset list device) (such as a network node, NIM, or port interface). In another embodiment, the management action is prevented from being processed. An alert or another message is issued including a notification that an administrative action is not to be performed.

FIG. 15 shows a schematic block diagram of an embodiment of generating a reset list in the virtual rack system 100 . In this embodiment, a network node reset list is generated that provides a list of the chassis identifiers of the network nodes and whether a reset of the network node would cause a virtual chassis in the virtual chassis system to split corresponding indicators. Resetting of a network node includes shutting down, rebooting, resetting, powering down, out of service state, or otherwise becoming inoperable in response to an administrative action. For example, administrative actions may include administrative commands to reset a network node, reboot a network node, power down a network node, set the state of the network node 110 to a shutdown or out-of-service state, or otherwise cause the network node to become inoperable. Manage actions. The topology information in topology database 144 includes available paths between network nodes 110 in virtual chassis system 100 . In the example of FIG. 15, network nodes 110a, 110b, and 110c have a linear topology, and topology database 144 includes the following example information in Table 6 for available paths between network nodes 110a, 110b, and 110c.

Table 6

For this example of topology information in virtual chassis system 100 of FIG. 15, a reset of network node 110a (with chassis ID = 1) would not cause a split of the virtual chassis in the system. Similarly, a reset of network node 110c (with Chassis ID = 3) will not cause a virtual chassis split in the system. However, a reset of network node 110b (with Chassis ID = 2) will cause a split of the virtual chassis in the system, because the first subset of nodes (network nodes 110a) will be split or separated or unable to communicate with the nodes in the system. The second subset (network nodes 110c) communicates. In this example embodiment, to prevent virtual chassis splitting, the network node reset list indicates that the combination of network nodes 110b and 110c should be reset at the same time to prevent virtual chassis splitting. Table 7 below shows an exemplary network node reset list for this embodiment of the virtual chassis system 100 .

reset network node Indicators for virtual rack splits reset suggestion RackID = 1 Fake N/A RackID=2 real rack_id=2,3 RackID = 3 Fake N/A

Table 7

The reset list is stored in the reset list table 710 in the CMM 150 of one or more network nodes 110 in the virtual chassis system 100 and/or in a unit operatively coupled to the virtual chassis system 100 In the manager module 406. In an embodiment, reset list 710 is generated or stored by cell manager module 406 . When a management action is entered into the unit manager module, the unit manager module 406 performs an analysis of the reset list 710 and determines whether to issue an alert for the management action. The element manager module 406 includes locally coupled or remote devices to one or more network nodes 110 . In another embodiment, the CMM 150 of one or more network nodes 110 of the virtual chassis system 100 generates or stores the reset list 710. When the CMM 150 of the network node 110 receives an administrative action, the CMM 150 accesses the reset list 710 and determines whether to issue an alert for the administrative action.

FIG. 16 shows a logic flow diagram of an embodiment of a method 750 for generating a reset list of network nodes in the virtual chassis system 100 . The analysis is performed for a plurality of network nodes 110 in the virtual chassis system 100 . In step 752, one of the plurality of network nodes 110 (eg, the source network node) is selected for analysis. In step 754, the topology information in the topology database 144 is accessed to determine the first destination node from the source network node. In step 756, the number of paths between the source node and the destination node is determined from the topology information 144 in the topology database. In step 758, when the number of paths is greater than 1, then in step 762, for the reset ID=destination network node, the alarm state of virtual rack split is false. Since there are multiple paths, resetting the destination node does not split or isolate the source network node from the virtual chassis system 100 . When the number of paths is equal to 1 in step 758 and the destination node is the last hop along the path in step 760, then in step 762 the virtual chassis splits for reset ID=destination network node The alarm status of is false. When in step 758 the number of paths is equal to 1 and in step 760 the destination node is not the last hop along the path, then in step 764 a virtual rack split warning indication for reset ID=destination network node tor is set to true. In step 766, the analysis determines other network nodes on the path between the source network node and the destination network node. The destination network node and the other network nodes are listed on the network node reset list as suggestions to reset simultaneously to avoid virtual chassis splits. In step 768, it is determined whether other destination nodes need to be analyzed. If so, the process proceeds to step 754. If there are no further destination nodes to analyze, then in step 770 the network node reset list of the source network node is stored.

FIG. 17 shows a schematic block diagram of another embodiment of generating a reset list in the virtual rack system 100 . A virtual rack split may occur when one or more NIMs 152 hosting a VFL 120 are reset. Resetting of the NIM 152 includes shutting down, rebooting, resetting, powering down, out of service state, or otherwise becoming inoperable in response to an administrative action. For example, in network node 110b, NIM 152c hosts VFL 120a that is operably coupled to network nodes 110a and 110b. When the NIM 152 is reset in response to an administrative action, the VFL 120a will be inoperable causing a virtual chassis split in the system. A first subset of nodes (network nodes 110a) will split from a second subset of nodes in the system (network nodes 110b and 110c), for example the first subset of nodes (network nodes 110a) will not be able to split with nodes in the system The second subset of the network nodes (network nodes 110b and 110c) communicate. In an embodiment, to prevent virtual rack splitting, a network interface module reset list is generated that includes a list of NIMs that should not become inoperable in response to administrative actions to avoid virtual rack splitting. Table 8 below shows an exemplary network interface module reset list for an embodiment of virtual chassis system 100 in FIG. 16 . A network interface module is identified by its network node 110 chassis ID and slot number.

reset NIM(rack ID, NIM ID) Indicators for virtual rack splits rack ID=1, NIM ID=slot 1 Fake Rack ID = 1, NIM ID = slot 2 Fake Rack ID=1, NIM ID=Slot 3 Fake Rack ID=1,NIM ID=Slot 2,3 real Rack ID = 2, NIM ID = slot 1 real rack ID=2, NIM ID=slot 2 Fake Rack ID=2, NIM ID=Slot 3 real Rack ID=3, NIM ID=Slot 1 Fake Rack ID = 3, NIM ID = slot 2 real rack ID=3, NIM ID=slot 3 Fake

Table 8

In an embodiment, the alert may include a recommendation to reconfigure the VFL 120 to another NIM 152 before resetting the NIM 152 that would cause the virtual rack to split.

In another embodiment, resetting the port interface 240 of the active member port of the VFL 120 may result in a split of the virtual chassis. For example, resetting of a VFL member port includes shutting down, rebooting, resetting, powering down, out of service, blocking mode, or otherwise rendering the port interface inoperable in response to an administrative action. For example, a virtual rack split may result in response to an administrative action that puts a port interface into blocking mode, resets a port interface, reboots a port interface, or places the port interface in a shutdown or non-service state or otherwise renders the port inoperable. operate. In an embodiment, to prevent virtual rack splitting, a VFL member port reset list is generated that includes a list of port interfaces 240 hosting VFL links and whether an alarm should be issued when the corresponding port interface 240 is reset to avoid Indicator of a virtual rack split. Table 9 below shows an exemplary VFL member port reset list for an embodiment of virtual chassis system 100 in FIG. 16 . A port interface is identified by the rack ID of its network node 110, the slot number of its NIM 152, and the port ID.

resetport(rack_id, slot, port_id) Indicators for virtual rack splits Rack ID＝1, NIM ID＝Slot 2, Port ID＝1 Fake Rack ID＝1, NIM ID＝Slot 3, Port ID＝1 Fake Rack ID=2, NIM ID=Slot 1, Port ID=2 real Rack ID＝2, NIM ID＝Slot 3, Port ID＝1 Fake Rack ID＝2, NIM ID＝Slot 3, Port ID＝2 Fake Rack ID=2, NIM ID=Slot 3, Port ID=1,2 real Rack ID＝3, NIM ID＝Slot 2, Port ID＝1 real

Table 9

In an embodiment, the alert may include a recommendation to reconfigure a member port interface of the VFL 120 to another port interface 240 before resetting the port interface that would cause the virtual chassis to split.

FIG. 18 shows a logic flow diagram of an embodiment of a method 800 for generating a network interface module reset list and/or a VFL member port reset list in the virtual chassis system 100 . The analysis is performed for the NIM 152 (identified by the slot ID) of the network node 110 of the plurality of network nodes 110 in the virtual chassis system 100. In step 802, a first NIM 152 of one of the network nodes 110 of the plurality of network nodes 110 (eg, the source network node) is selected for analysis. In step 804, the topology information 144 in the topology database is accessed to determine whether a VFL member port is included on the selected NIM. In step 804, when there is no VFL member port on the NIM, in step 808, for reset ID=rack ID, slot ID of NIM, the alarm status of virtual rack split is false. In step 804, when there are VFL member ports on the NIM, the topology information in the topology database 144 is accessed to determine whether the NIM hosts all of the VFL member ports of the VFL (e.g., is another NIM on the source network node also VFL member port hosting the VFL). If not, in step 808, for reset ID=rack ID, slot ID of NIM, the alarm status of virtual rack split is false. In step 806, if the NIM hosts all member ports of the VFL, then in step 810 the topology information in the topology database 144 is accessed to determine the number of paths (e.g., VFLs) between the source network node and the destination node . In step 812, when other paths or VFLs connect the source and destination nodes, then in step 808, for reset ID=rack ID, slot ID of NIM, the alarm status of virtual rack split is false. In step 812, when a NIM hosts a member port of a VFL that is the only path or connection between a source network node and a destination network node, in step 814 topology information in the topology database 144 is accessed to determine whether the VFL is The next hop in the path to the destination network node. If not, then in step 808, for reset ID=rack ID, slot ID of NIM, the alarm status of virtual rack split is false. In step 814, if the NIM hosts the only member port of the VFL that is the next hop in the path to the destination network node, then in step 816, for reset ID = rack ID, slot ID of the NIM, the virtual rack The alert state of the split is true.

In step 818, the analysis continues to generate a VFL member port reset list. For each VFL member port of the NIM, an analysis is performed at step 818 . In step 818, the topology information in the topology database 144 is accessed to determine whether the member port of the VFL on the NIM is the only member port of the VFL. If not, then in step 820, for reset ID=rack ID, slot ID, port ID of VFL member port, the alarm indicator of virtual rack split is false. In step 818, when the member port of VFL on the NIM is the only member port of VFL, then in step 822, for the port ID of reset ID=frame ID, slot ID, VFL member port, virtual frame A split alert indicator is true. The analysis in FIG. 18 is performed to generate a reset list of network interface modules and/or a reset list of VFL member ports in the virtual chassis system 100 .

16 and 18 illustrate an example process for generating a reset list for the example topology described herein. Similarly, additional or alternative processes or analyzes may be performed to determine reset lists for these or other topologies.

FIG. 19 illustrates a logic flow diagram of an embodiment of a method 850 in virtual rack system 100 for handling management actions to help prevent virtual rack splits. In an embodiment, a management action is received in step 852 . Management actions include management commands and identifiers of the network node 110, NIM 152 or port interface 240. In response to an administrative action, one or more of the reset lists are accessed in step 854 . For example, during the processing of an administrative action, such as reloading Or reset network node 110, reload or reset NIM 152, disable NIM 152, shut down network node 110, execute ISSU, disable port interface 240, disable VFL 120, etc. management commands. For example, a network node reset list, a NIM reset list, and/or a VFL member port interface reset list is accessed. Other or additional lists may also be accessed to help determine whether to issue an alert regarding a virtual rack split. In step 856, it is determined whether to issue a virtual rack split alert in response to an administrative action.

When it is determined not to issue an alert, eg, reset one or more of the indications in the list that the management action will not cause the virtual rack to split, then the processing of the management action proceeds to step 858 . However, when it is determined to issue an alarm, for example, resetting the list indicates that the management action may cause the split of the virtual rack, the alarm is issued and transmitted to the user equipment for display. The alert includes, for example, an indication that a virtual rack split may occur in response to an administrative action. The alert may also include one or more recommendations to avoid virtual rack splits, eg, reset the desired device with one or more other devices specified in the reset list (such as reset one or more other network nodes). The alert may also include a recommendation to reconfigure the VFL member port interface 240 to one or more other NIMs 152 prior to performing administrative actions.

In an embodiment, the alert is displayed by the unit manager module in a graphical user interface, such as a command line interface (CLI), Webview, or an alternative management application. In an embodiment, one or more options are provided, such as aborting the administrative action, continuing the administrative action regardless of the alert, and using the alert to suggest continuing the administrative action, such as rebooting the desired device plus a suggested reset in the list other equipment. In another embodiment, processing management actions are prohibited. An alert or another message is issued including a notification that an administrative action is not to be performed.

The reset list facilitates alerting of virtual rack splits in response to administrative actions in the virtual rack system. This prevention reduces unwanted events such as duplicate MAC addresses, duplicate configurable resources (e.g., IP interfaces), connectivity loss, loss of management access, instability due to multiple switch reset events, etc.

20 illustrates a logic flow diagram of an embodiment of a method 900 in virtual rack system 100 for handling configuration management actions of one or more parameters to help prevent virtual rack splits. For example, management actions that may trigger virtual rack splits include inconsistent parameter configurations on network nodes 110, such as a) configuring different control VLANs on different network nodes 110 within the virtual rack topology; Configure different intervals of health monitoring messages (such as hello or keep-alive messages) on different network nodes 110 in the virtual rack topology; c) configure different rack groups (virtual rack system identifiers) on different network nodes 110 in the virtual rack topology ). For example, when the network nodes 110 in the virtual rack system are configured with different virtual rack system identifiers, the network node 110 may initiate virtual rack splitting to become different virtual rack systems. Additionally, configuring different control VLANs for control packets may cause control packets to be dropped and unprocessed and result in virtual chassis fragmentation. Also, different hello intervals configured for health monitoring may lead to incorrect conclusions about failures of nodes or node modules. Misconfiguration of other parameters not disclosed herein may also cause failures or loss of module functionality that would result in virtual rack splits.

In step 902 , a management action is received to configure one or more parameters on one or more network nodes 110 . In step 904, the configuration is analyzed to determine whether the one or more parameters conflict among network nodes 110 in the virtual chassis system or would otherwise cause failure or result in a virtual chassis split. In step 906, if the configuration may cause a failure, then in step 910 an alert is issued for the management action. The alerts include, for example, indications of parameter conflicts between network nodes and/or indications that the configuration may lead to failures or fragmentation of virtual racks. An alert may also include one or more recommendations to avoid failure or virtual rack fragmentation, eg, different configuration parameters. In another embodiment, the management action is prevented from being processed. An alert or another message is issued including a notification that an administrative action is not to be performed.

When it is determined in step 906 that the configuration of the parameters will not lead to failure or splitting of the virtual rack, the processing of the management action proceeds to step 908 .

As used herein, the terms "operably coupled to", "coupled to", and/or "coupled" include direct coupling between items and/or between items via intermediate items (e.g., items include but are not limited to components, units, circuits, and/or modules), where for indirect coupling, the intermediate item does not modify the signal's information but may adjust its current level, voltage level, and/or power level. Also used herein, inferred coupling (that is, one unit is inferred to be coupled to another unit) includes both direct and indirect coupling between two items in the same manner as "coupled to".

As used further herein, the term "operable for" or "operably coupled to" means an item comprising one or more electrical connections, input(s), output(s), etc., which when activated performs a or more of its corresponding functionality, and may also include an inferential coupling to one or more other items. As may further be used herein, the term "associated with" includes direct and/or indirect coupling of separate items and/or one item being embedded within another item or one item being configured for use by or by another item. The term "favorably compares", as may be used herein, indicates that a comparison between two or more items, signals, etc. provides a desired relationship. For example, when the desired relationship is that signal 1 has a greater magnitude than signal 2, a favorable comparison can be made when signal 1 has a greater magnitude than signal 2 or when signal 2 has a smaller magnitude than signal 1.

The terms "processing module", "processing circuit" and/or "processing unit" as may also be used herein may be a single processing device or a plurality of processing devices. Such processing devices may be microprocessors, microcontrollers, digital signal processors, microcomputers, central processing units, field programmable gate arrays, programmable logic devices, state machines, logic circuits, analog circuits, digital circuits, and and/or any device that manipulates signals (analog and/or digital) based on hard-coded circuitry and/or operational instructions. The processing module, module, processing circuit and/or processing unit may be or may further include memory and/or an integrated memory unit, which may be a single storage device, multiple memory devices, and/or another processing module, module, processing circuits, and/or embedded circuits of processing units. Such a storage device may be a read-only memory, random access memory, volatile memory, non-volatile memory, static memory, dynamic memory, flash memory, cache memory, and/or any device that stores digital information. Note that if a processing module, module, processing circuit, and/or processing unit comprises more than one processing device, the processing devices may be centrally located (e.g., directly coupled together via a wired and/or wireless bus structure) or may be Set up in a distributed manner (for example, via local area network and/or wide area network through indirect coupled cloud computing). It is further noted that if the processing module, module, processing circuit, and/or processing unit implements one or more of its functions via a state machine, analog circuit, digital circuit, and/or logic circuit, the memory storing the corresponding operation instruction and And/or memory cells may be embedded inside or outside of circuits including state machines, analog circuits, digital circuits, and/or logic circuits. It should be further noted that the memory unit may store, and the processing module, module, processing circuit, and/or processing unit execute, corresponding to at least some of the steps and/or functions shown in one or more drawings and/or hardcoded and/or or operating instructions. Such a memory device or memory cell may be included within an article of manufacture.

The invention has been described above with the aid of method steps illustrating the performance of specified functions and relationships thereof. The boundaries and sequence of these functional building blocks and method steps have been arbitrarily defined herein for the convenience of the description. Alternate boundaries and sequences can be defined so long as the specified functions and relationships are appropriately performed. Any such alternate boundaries or sequences are within the scope and spirit of the claimed invention. Furthermore, the boundaries of these functional building blocks have been arbitrarily defined for the convenience of the description. Alternate boundaries can be defined so long as the certain significant functions are appropriately performed. Similarly, flowchart blocks have been arbitrarily defined herein to illustrate the certain significant functionality. For purposes of expansion, the boundaries and order of the flowchart blocks could have been defined otherwise and still perform the certain significant functions. Alternative definitions of such functional building blocks and flowchart blocks and sequences thus remain within the scope and spirit of the claimed invention. Those skilled in the art will also recognize that the functional schematic block diagrams, and other illustrative blocks, modules, and components herein, may be implemented as illustrated or combined or separated into discrete components, application specific integrated circuits, processors executing appropriate software, etc. or any combination thereof.

The invention has been described, at least in part, in terms of one or more embodiments herein. Embodiments are described herein to illustrate the invention, one of its aspects, one of its features, one of its concepts, and/or one of its examples. A physical embodiment of an apparatus, article of manufacture, machine and/or process embodying the invention may include one or more of the aspects, features, concepts, examples, etc. discussed herein and described with reference to one or more embodiments. In addition, between the figures, the embodiments may contain the same or similarly named functions, steps, modules, etc., they may use the same or different reference numerals, and such functions, steps, modules, etc. may be the same Or similar functions, steps, modules, etc., or different functions, steps, modules, etc.

Unless otherwise stated, signals to, from, and/or between elements in the figures presented herein may be analog or digital, continuous time or discrete time, and single-ended or differential. For example, if a signal path is shown as a single-ended path, it also represents a differential signal path. Similarly, if a signal path is shown as a differential path, it also represents a single-ended signal path. Although one or more specific architectures are described herein, other architectures are equally possible using one or more data buses not explicitly shown, direct connectivity between elements, and/or indirect coupling between other elements.

The term "module" is used in the description of various embodiments of the present invention. Modules include processing modules (as described above), functional blocks, hardware and/or software stored in memory operable to perform one or more functions as described herein. Note that if a module is implemented via hardware, the hardware may operate independently and/or in conjunction with software and/or firmware. When a module is implemented as software stored in memory, the module is operable to use a processing module or other hardware to execute the software stored in the memory of the module to perform the functions described herein. The modules described herein may include one or more sub-modules, each of which may be one or more modules, be contained within or include one or more other modules.

Although certain combinations of various functions and features of the present invention have been expressly described herein, other combinations of such features and functions are also possible. The embodiments described herein are not limited to the specific embodiments described and may include other combinations and embodiments.

Claims (10)

1. an exercisable network node in virtual machine frame system, comprising:

One or more Network Interface Module, is operationally coupled to multiple Virtual Organization link (VFL), and wherein said VFL is operationally coupled to the multiple network nodes in described virtual machine frame system;

At least one administration module, can be used to:

Receive the first management activities, wherein said first management activities comprises the frame identifier of at least one in the multiple network nodes in described virtual machine frame system;

Access one or more replacement list, wherein said one or more replacement list comprises the one or more frame identifier in the multiple network nodes in described virtual machine frame system and resets the respective indicator whether triggering the division of virtual frame; And

The alarm of the virtual frame division of release management action triggers is determined whether from described one or more replacement list and described first management activities.

2. network node as claimed in claim 1, at least one administration module wherein said can operate further and be used for:

When the alarm of the virtual frame division of described one or more replacement list instruction release management action triggers, determine whether the frame identifier that can be reset other network nodes one or more avoiding virtual frame to divide is put into from described one or more replacement list.

3. network node as claimed in claim 2, wherein said management activities comprise following at least one:

For resetting by the administration order of at least one in described multiple network node of described frame identifier mark;

For restarting by the administration order of at least one in described multiple network node of described frame identifier mark;

For the administration order of at least one power-off in described multiple network node that will be identified by described frame identifier;

For arranging by the administration order of the closed condition of at least one in described multiple network node of described frame identifier mark; With

For arranging by the administration order of the non-serving state of at least one in described multiple network node of described frame identifier mark.

4. network node as claimed in claim 1, at least one administration module wherein said can operate further and be used for:

The topological database of the topology information of accesses virtual machine frame system, wherein said topology information comprises the frame identifier of described multiple network node and described Network Interface Module and is coupled to the mark of VFL member port interface of multiple Virtual Organization link (VFL) in described network node; With

Generate described one or more replacement list based on described topological database, wherein said one or more replacement list comprise following in one or more:

Whether the one or more frame identifier in multiple network node described in described virtual machine frame system and the replacement of frame identifier trigger the respective indicator of virtual frame division;

Whether the NIM identifier of one or more one or more Network Interface Module NIM in multiple network node described in described virtual machine frame system and the replacement of one or more NIM identifier trigger the respective indicator of virtual frame division; With

Whether the one or more VFL member port identifier in multiple network node described in described virtual machine frame system and the replacement of VFL member port trigger the respective indicator of virtual frame division.

5. can a method in running node in virtual machine frame system, described virtual machine frame system comprises multiple Virtual Organization link (VFL) of being operationally coupled to multiple network node, and described method comprises:

Receive the first management activities, wherein said first management activities comprises the frame identifier of at least one in the multiple network nodes in described virtual machine frame system;

Access one or more replacement list, wherein said one or more replacement list comprises the respective indicator whether one or more frame identifier in described virtual machine frame system in multiple network node and the one or more replacement in described multiple network node trigger the division of virtual frame; And

The alarm of the virtual frame division of release management action triggers is determined whether from described one or more replacement list and described first management activities.

6. method as claimed in claim 5, comprises further:

When the alarm of the virtual frame division of described one or more replacement list instruction release management action triggers, determine whether the frame identifier that can be reset other network nodes one or more avoiding virtual frame to divide is put into from described one or more replacement list.

7. method as claimed in claim 6, wherein said management activities comprise following at least one:

For resetting by the administration order of at least one in described multiple network node of described frame identifier mark;

For restarting by the administration order of at least one in described multiple network node of described frame identifier mark;

For the administration order of at least one power-off in described multiple network node that will be identified by described frame identifier;

For arranging by the administration order of the closed condition of at least one in described multiple network node of described frame identifier mark; With

For arranging by the administration order of the non-serving state of at least one in described multiple network node of described frame identifier mark.

8. method as claimed in claim 7, comprises further:

The topological database of the topology information of accesses virtual machine frame system, wherein said topology information comprises the frame identifier of described multiple network node and described Network Interface Module and is coupled to the mark of VFL member port interface of multiple Virtual Organization link (VFL) in described network node; With

Generate described one or more replacement list based on described topological database, wherein said one or more replacement list comprise following in one or more:

Whether the one or more frame identifier in multiple network node described in described virtual machine frame system and the replacement of frame identifier trigger the respective indicator of virtual frame division;

Whether the NIM identifier of one or more one or more Network Interface Module NIM in multiple network node described in described virtual machine frame system and the replacement of one or more NIM identifier trigger the respective indicator of virtual frame division; With

Whether the one or more VFL member port identifier in multiple network node described in described virtual machine frame system and the replacement of VFL member port trigger the respective indicator of virtual frame division.

9. method as claimed in claim 8, comprises further:

Receive the second management activities, wherein said second management activities comprises a NIM identifier of one of Network Interface Module (NIM) in one of described multiple network node; With

Access one or more replacement list to determine whether the alarm of the virtual frame division of release management action triggers.

10. method as claimed in claim 9, comprises further:

Receive the 3rd management activities, wherein said 3rd management activities comprises a VFL member port interface identifier; With

Access one or more replacement list to determine whether the alarm of the virtual frame division of release management action triggers.