KR101689096B1 - Network node and method in a node operable in a virtual chassis system wherein it is determined whether to issue a warning that an administrative action triggers a virtual chassis split - Google Patents

Abstract

The virtual chassis system includes a plurality of network nodes configured with a master virtual chassis address. The network node is connected by a virtual fabric link (VFL) that provides a connection for exchanging packets between network nodes. The virtual chassis system is operable to provide an alert in response to the management action to help prevent the virtual chassis split event. The virtual chassis system topology 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 is requested that may lead directly or indirectly to the virtual chassis split.

Description

METHOD AND METHOD IN NODE OPERABLE IN A VIRTUAL CHASSIS SYSTEM WHEREIN IT IS DETERMINED WHETHER THAT IS DETERMINED THAT WHICH IS TO RESULTS A WARNING THAT THE NETWORK NODES AND MANAGEMENT ACTIONS TRAVEL THE VIRTUAL CHASSIS SPLIT TO ISSUE A WARNING THAT AN ADMINISTRATIVE ACTION TRIGGERS A VIRTUAL CHASSIS SPLIT}

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

A data network includes various computing devices, e.g., personal computers, IP telephone devices or servers that communicate with each other and / or with various other network elements or remote servers attached to the network. For example, the data network may include, but is not limited to, metro Ethernet or enterprise Ethernet supporting a number of applications including, for example, voice-over-IP (VoIP) It is possible. Such networks typically include interconnected nodes, commonly known as switches or routers, for routing traffic over a network.

One of the major challenges faced by data networks is the need for the ability to maintain high availability despite network resiliency, i.e., final component failure, link failure, etc., which provides satisfactory network performance It is important to. Network resiliency is achieved in part by providing topological redundancy, i. E., By providing multiple physical paths between nodes to prevent failures of a single point and redundant nodes (and redundant components within a node) L2 < / RTI > / L3 protocol that uses redundancy to converge on an alternate path to switch / route the traffic flow through the L2 / L3 protocol. As can be seen, the detection and convergence times in the network must occur quickly (advantageously less than one second) in order to achieve seamless switching to alternative paths. In order to provide redundancy between network elements, various types of network topologies, such as ring networks, partial mesh networks, full mesh networks, hub networks, etc., are implemented within a network. The redundancy between network elements and the convergence time often vary with the type of network topology implemented in the network.

The architecture of the network element also changes and affects network resiliency. For example, the various node architectures include a single switching element, a stackable switching element, a multi-slot chassis based network element, and the like. In general, depending on cost and network requirements, one of these types of node architectures is selected and implemented as one of the types of network topologies. However, once implemented, it is sometimes difficult to upgrade or switch from one type of network topology to another type of network topology. It is also difficult to switch from one type of node architecture to another type of node architecture within a network topology, or to integrate various types of node architectures within a network.

Accordingly, a need exists for a system and method for providing resiliency between nodes having one or more different types of node architectures in one or more different types of network topologies.

Figures 1A-1C show schematic block diagrams of an embodiment of a virtual chassis system according to the present invention.
Figure 2 shows a logic flow diagram of an embodiment of a network topology discovery process in a virtual chassis system in accordance with the present invention.
3 shows a schematic block diagram of one embodiment of a topology database of network nodes in a virtual chassis system according to the present invention.
4 shows a schematic block diagram of an embodiment of a network node in a virtual chassis system according to the present invention.
Figure 5 shows a schematic block diagram of an embodiment of a network interface module of a network node in a virtual chassis system according to the present invention.
Figure 6 shows a schematic block diagram of one embodiment of a pre-pended header of a packet in a virtual chassis system according to the present invention.
Figure 7 shows a schematic block diagram of one embodiment of packet flow over a network node in a virtual chassis system in accordance with the present invention.
Figure 8 shows a schematic block diagram of one embodiment of a virtual Chassis Manager application in accordance with the present invention.
Figure 9 shows a schematic block diagram of one embodiment of master address maintenance in a virtual chassis system in accordance with the present invention.
Figure 10 shows a schematic block diagram of one embodiment of a master address release in a virtual chassis system in accordance with the present invention.
Figure 11 shows a schematic block diagram of one embodiment of a master network node failure in a virtual chassis system according to the present invention.
Figure 12 shows a schematic block diagram of one embodiment of a VFL failure in a virtual chassis system in accordance with the present invention.
13 shows a logic flow diagram of an embodiment of a method for recovering from a failure of a master network node in a virtual chassis 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 chassis system according to the present invention.
15 shows a schematic block diagram of an embodiment of the generation of a reset list in a virtual chassis system according to the present invention.
Figure 16 shows a logic flow diagram of an embodiment of a method for generating a network node reset list in a virtual chassis system according to the present invention.
17 shows a schematic block diagram of another embodiment of the generation of a reset list in a virtual chassis 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 chassis system according to the present invention.
19 shows a logic flow diagram of an embodiment of a method for processing administrative actions to help prevent virtual chassis splitting in a virtual chassis system according to the present invention.
Figure 20 shows a logic flow diagram of an embodiment of a method for processing management actions for configuring one or more parameters to help prevent virtual chassis splitting in a virtual chassis system in accordance with the present invention.

The following standards are incorporated herein by reference and are incorporated herein by reference: 1) Previously, the IEEE 802.3ad Task Force was the 43th edition of the IEEE 802.3 standard, which was added in March 2000, Link Aggregation Control Protocol (LACP) as integrated in IEEE 802.1AX-2008 of March 3; And 2) IEEE Std. 802.1Q, Virtual Bridged Local Area Networks.

Figure la illustrates a plurality of network nodes 110 operatively coupled by a dedicated link aggregate group for communicating control and addressing information, referred to as virtual fabric links (VFL) 120, FIG. 2 illustrates an embodiment of a virtual chassis system 100 that includes a microprocessor. VFL 120 and their 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 LINK AGGREGATION, The application is incorporated herein by reference and becomes part of this U.S. patent application for all purposes. The VFL 120 may be configured to perform various functions such as traffic forwarding, MAC addressing, multicast flow, address resolution protocol (ARP) tables, layer 2 control protocols (e.g., spanning tree, (E.g., RIP, OSPF, BGP), and information related to the status of external links with network nodes.

In one embodiment, the plurality of network nodes 110 operate as a single virtual network node with integrated management capabilities. A master network node such as network node 110a is selected and the local MAC address of the master network node 110 is adopted by the other network node 110 as the master MAC address for the virtual chassis system 100. [ The master MAC address is utilized by the external node 112 to address the network node 110 in the virtual chassis system 100. As such, network node 110 operates transparently to external node 112 and is treated as a single logical device by external node 112.

The external node 112 may use a single trunk or link, a link aggregate group (LAG) 116, or a virtual-chassis link aggregate group (VC-LAG) Is operable to connect to one or more network nodes (110) of the chassis system (100). In order to provide increased resilience and to eliminate single point or even two point faults, VC-LAG 114 may be used to connect an external node to two or more network nodes 110 of virtual chassis system 100 It is operable. The external node may use a load balancing technique to distribute traffic across the available links of the VC-LAG 114. For example, a load balancing algorithm (generally accompanied by a hash function that operates on source and destination Internet Protocol (IP) or Media Access Control (MAC) address information) for more efficient use of bandwidth One of the physical links of the VC-LAG 114 is selected by the external node to transmit the packet based on the physical link.

During normal operation, the network node 110 in the virtual chassis system shares the master MAC address for system identification by a wide variety of Layer 2 and Layer 3 protocols. For example, the spanning tree protocol and the LACP protocol use the master MAC address as an identifier for the virtual chassis system 110. Internet Protocol (IP) routing also utilizes a master MAC address to identify the virtual chassis system 100 to an external network element of the network. For example, the peer uses the master MAC address as the Ethernet destination address for packets destined for the virtual chassis system 100. As such, the network node 110 of the virtual chassis system 100 is viewed as a single logical node by the external network node 112. In addition, the network node 110 in the virtual chassis system 100 is managed as a single node with an integrated management, operation, and maintenance management system.

Since the network node 110 in the virtual chassis system 100 is treated as a single logical device by the external node 112, the external node 112 is able to transmit traffic on all links of the VC-LAG 114, Lt; RTI ID = 0.0 > actively < / RTI > This feature is advantageous in that it does not require a spanning tree protocol between an external node and a network node, while simultaneously allowing convergence time for network node 110 failure as well as carrier class detection and edge uplink failure, 0.0 > 110 < / RTI > Another advantage of the active forwarding mode of all VC-LAG 114 uplinks to the virtual chassis system 100 is the increased efficiency of the bandwidth of the VC-LAG 114 link.

Within virtual chassis system 100, network node 110 is assigned a globally unique identifier, referred to as a chassis identifier or chassis ID. The network node 110 allocates an internal VFL identifier (VFID) for each of its configured VFLs 120 in the virtual chassis system 100. Because the VFID for the VFL is utilized for internal identification and configuration of the VFL 120, the network node 110 may assign the VFL 120 the same or a different VFID as that assigned by the other network node 110 have. The VFL 120 may include traffic forwarding, forwarding, forwarding, forwarding, forwarding, forwarding, forwarding, forwarding, forwarding, forwarding and forwarding, as described in more detail in U.S. Patent Application Serial No. 13 / 010,168, entitled SYSTEM AND METHOD FOR MULTI-CHASSIS LINK AGGREGATION, filed January 20, (Eg, spanning tree, Ethernet ring protection, logical link detection protocol), routing protocols (eg, RIP, OSPF, BGP), MAC addressing, multicast flow, Lt; RTI ID = 0.0 > 110 < / RTI > In one embodiment, the synchronization of a layer 2 address table, e.g., a medium access control (MAC) address table, between the network nodes 110 is performed by a Layer 2 packet flow through the VFL 120 as well as a periodic keep- alive mechanism, whereby the network node 110 possessing the given MAC address floods a particular packet with this MAC address as the source address. The synchronization mechanism also needs to implement a standard MAC flushing mechanism to handle when the network node 110 or some of its components fails. MAC address source learning is enabled across VFL 120 through flooding of an unknown destination MAC address. During source learning, the network node 110 sends a packet with a prepended header containing the source MAC address and associated hardware device information, such as source chassis ID, source network interface identifier, and source port identifier information, to the VFL 120 . Network node 110 uses this information to maintain a synchronized MAC address table with minimal messaging based MAC table synchronization. Using the synchronized MAC address table, the network node 110 is operable to process and forward packets between the network nodes 110 of the virtual chassis system 100.

Figure 1A illustrates that network node 110 is connected in a partial mesh network topology. However, the network node 110 of the virtual chassis system 100 may be connected from any of a plurality of types of network topologies without affecting the operation of the virtual chassis system 100. FIG. 1B illustrates a virtual chassis system 100 in which a plurality of network nodes 110 are configured with a ring network topology connected by a VFL 120. FIG. 1C illustrates a virtual chassis system 100 in which a plurality of network nodes 110 are configured in a hub and spoke or star network topology. Other network topologies that are not depicted, such as linear, tree, full mesh, hybrid, etc., are also supported by the virtual chassis system 100. To support a plurality of different types of network topologies, the network node 110 of the virtual chassis system 100 is operable to perform a network topology discovery process.

FIG. 2 illustrates a logic flow diagram of one embodiment of a network topology discovery process 130 in a virtual chassis system 100. FIG. The process is performed by the active network node 110 of the virtual chassis system 100 at start-up, at reboot, at the time of display of the state change in the network, or at a predetermined time. At 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 a virtual chassis operation mode. The network node 110 detects that the parameter is indicative of a virtual chassis mode operation (e.g., not a stand alone mode or multiple chassis modes). The network node 110 then performs one or more control protocols at step 134 to discover other network nodes 110 in the virtual chassis system 100 and exchange topology and configuration information. The network node 110 builds a topology database of the virtual chassis system 100 using the information. The topology database includes: a network interface (not shown) that hosts identification information (e.g., a local MAC address, chassis identifier) for the other network node 110, an active VFL 120 (or other active inter- Identification information for the VFL 120 and their associated member ports on the network node 110. Thus, the network node 110 learns the active connection between the network node 110 and the configuration information of the other network node 110 of the virtual chassis system 100. Following Table 1 below is an example of a topology database for network node 110a with chassis ID = 1 in this example, following the discovery step. Table 1 includes exemplary information that is stored in the topology database, but other information and data not illustrated may also be included in the topology database. In addition, the topology database may be stored in a separate database or table, or may be 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 for the virtual chassis system 100. The local MAC address of the master network node is then adopted by the other network node 110. Table 2 below is an example of a topology database for an elected master network node 110 with chassis ID = 1. As can be seen in Table 2, a network node with chassis ID = 1 is represented as having a master role and another node is represented as having a slave role in the topology database.

Table 2

The selection of the master network node 110 is based on a prioritized list of parameters including chassis priority, up time, chassis ID and chassis MAC address. The parameter of uptime gives priority to the network node 110 that is operating for a longer period of time. The parameter of the chassis priority is a priority set by the user who defines the user preference of the master network node 110 regardless of the chassis ID or the operation time. The use of various parameters adds flexibility to the selection of the master network node 110. The chassis group parameter shown in the topology database identifies the virtual chassis system 100. One or more additional virtual chassis systems 100 having different chassis group identifications may also be operable in the network. The topology database also identifies the chassis type of the active or primary control manager module (CMM) and network node 110 at network node 110.

At step 138 of the network topology discovery process 130, the network node 110 performs one or more protocols to monitor the state or status of the network node 110 and the connection of the virtual chassis system 100 do. The current state of the network node 110 is maintained in the topology database. The detected state change at the network node 110 of the virtual chassis system 100 may initiate a change in routing, a change at the master node, and so on. Through the topology self-discovery and monitoring of the network node 110, the virtual chassis system 100 is operable to support a plurality of different types of network topologies with minimal pre-configuration and interference.

FIG. 3 illustrates an example of a topology database 144 at a network node 110 of a virtual chassis system 100 after selection of a master network node 110. In this example, network node 110a is adopted as a master network node and network nodes 110b and 110c are adopted as slave nodes. The local MAC address (e.g., master MAC address = A) of network node 110a is adopted by network nodes 110a-110c as the virtual chassis MAC address. Also, the master 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 a network node 110 having one or more different types of node architectures, such as a single module, a stackable, or a multi-slot chassis-based architecture. 4 illustrates a schematic block diagram of one embodiment of a network node 110 in a virtual chassis system 100 having different types of node architectures. In this example, network node 110a has a multi-slot chassis-based architecture with a plurality of network interface modules 152a-152n. In general, a multi-slot chassis-based architecture shares one enclosure, a control manager module (CMM) 150a-150n, and a common power source with one or more network interface modules (NIMs) 152a-152n. The network interface module 152n includes a queuing module 212 and a switching module 210 and is connected by a fabric switch 214 integrated into the backplane of the chassis.

In this example, the network node 110b has a stackable node architecture and includes a plurality of network elements 140a-140n coupled by backside connections 142. [ Each network element 140a-140n is operable as a standalone node and includes its own enclosure, a control manager module (CMM) 150, a switching module 210, a queuing module 212 and a power source. In some stacked architectures, one network element (network element 140 in this example) is designated as the main or master unit of the stack for management purposes.

The network node 110c may have a single module node architecture such as a single stackable element 140 or alternatively a multiple slot chassis based architecture with a single network interface module 152. [

The network nodes 110a-110c correspond to one or more of the network elements 110 of the virtual chassis system 100 in Figures 1A-1C. For example, the virtual chassis system 100 may include a network node 110 having only a multi-slot chassis-based node architecture, or a network node 110 having only a stackable node architecture, or a multi-slot chassis- A network node 110 having two or more types of node architectures such as a stackable node architecture and a single module node architecture. Although not shown, the virtual chassis system 100 may also include a network node 110 configured with other types of node architectures and configurations.

Network node 110a and the network node are operatively connected by VFL 120a. Network nodes 110a and 110b designate VFL 120a as an internal VFL identifier (VFID), such as VFID = 3 for network node 110a and network node 110b VFID = 0 is designated. Network node 110a and network node 110c are operatively connected by VFL 120b. Network nodes 110a and 110c designate VFL 120b as an internal VFL identifier (VFID), such as VFID = 2 for network node 110a and network node 110c VFID = 1. In addition, the network nodes 110a-110c are also operable to be connected by additional VFLs 120s for one or more other network nodes 110, as shown in Figures 1A-1C. The VFL 120a between the nodes 110a and 110c is described below as a generalization of the operation and configuration of the VFL 120 between the various network nodes 110 of the virtual chassis system 100. [

VFL 120a between network node 110a and network node 110b is operatively coupled to one or more VFL member ports of one or more switching modules 210. [ For redundancy in the event of failure of one or more ports, links, or modules, VFL 120a may use a plurality of aggregations generated using LACP or similar aggregation protocols between different switching modules 210 of network nodes 110a and 110b Link. 4, VFL 120a includes a first subset A of physical links between NIM 152a of network node 110a and a stackable network element 140a of network node 110b, Includes a second subset B of physical links between the NIM 152b of the network node 110a and the stackable element 140b of the network node 110b.

The network node 110 is assigned a unique chassis identifier in the virtual chassis system 100. The chassis ID for each network node 110 is unique and global and through topology discovery, the network node 110 recognizes the chassis ID of its peer network node 110 in the virtual chassis system 100 . In addition, various hardware components, such as a port interface of the network node 110 and a unique hardware device identifier or module identifier (MID) for the switching module 210 are created to allow management of local and remote objects. In one embodiment, the hardware device identifier (MID) for the switching module 210 has a global meaning within the virtual chassis system, but other components, such as the MID for the queuing module 212, may have only local meaning . For example, the hardware device identifier assigned to the switching module 210 is known to the other network node 110, but the hardware device identifier for the other device is limited to the local network node 110 and to the other network node 110 It does not make sense. For example, the port interface of the switching module 210 is assigned a globally unique hardware device identifier including a chassis ID, a switching module ID, and a port interface ID. In one embodiment, the network node 110 of the virtual chassis system operates in a prepended header mode to exchange data and control packets via the VFL 120. [

5 is a schematic block diagram of one embodiment of a network interface module (NIM) 152 operating in a prepped header mode. Although network interface module 152 is illustrated, stackable network element 140 or a single module network element may be operated to perform a similar function for operation in a prepended header mode. The switching module 210 includes a plurality of external ports 240 that are connected to the external node 112 from the virtual chassis system 100. One or more of the external ports 240 may include member ports for VC-LAG 114, LAG 116, a single trunk or other trunk group, a fixed link, and so on. The external port 240 may have the same type of physical interface, such as a copper port (CAT-5E / CAT-6), a multimode fiber port (SX), or a single mode fiber port (LX). In other embodiments, the external port 240 may have one or more different physical interface types.

The external port 240 is assigned a device port value such as an external port interface identifier (port ID) associated with the switching module 210, e.g., gport and dport values. In one embodiment, the chassis ID of the network node 110, the MID of the switching module 210, and the external port interface identifier (port ID) Is used as a globally unique identifier of the mobile terminal (240). In another embodiment, a globally unique module identifier (MID) is assigned to the switching module 210 of the network node in the virtual chassis system based on the chassis identifier. For example, the switching MID (0-31) is assigned to chassis ID = 1, and the switching MID (32-63) is assigned to chassis ID = 2. In this case, globally unique switching MIDs and external port identifiers (port IDs) are used as globally unique identifiers of the physical external port interface 240 at the network node 110 of the virtual chassis system 100.

When a packet is received on the external port 240, the switching module 210 receives the pre-pended packet header interface (which modifies the packet header in a different manner) (PPHI) 246 to include the destination MAC address of the packet and / or the hardware device information (HDI) associated with the source. In one embodiment, the prepended header may include other information such as packet priority and load balancing identifier. In order to obtain HDI information associated with the MAC address of the packet, the PPHI performs a lookup process in the MAC / HDI forwarding table 250. 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, the switching module 210 and / or the port interface 240 for routing packets. The hardware device information includes, for example, the chassis ID, the port interface ID of the port associated with the MID of the switching module 210, and / or the destination MAC address. The MAC / HDI forwarding table 250 may include one or more tables, such as a source trunk map, a trunk bitmap table, a trunk group table, a VLAN mapping table, and the like. In one embodiment, the MAC / HDI forwarding table 250, or portions thereof, may also be located in a queuing module or other module of the NIM 152.

Based on the topology database 144, a VFL routing configuration table 254 is generated at the network node 110 to determine the routing of the unicast traffic. The VFL routing configuration table 254 includes the chassis ID and the associated VFL ID (VFID). The VFID associated with the chassis ID identifies the VFL 120 of the virtual chassis system 100 for routing the packet to the network node 110 identified by the destination chassis ID. In another embodiment, if a globally unique module identifier (MID) is assigned to the switching module 210 of the network node 110 of the virtual chassis system 100, the VFL routing configuration table 254 is globally unique Includes one MID and associated VFL ID (VFID). In one embodiment, the VFL routing configuration table 254 is generated using a shortest path algorithm, a traffic based algorithm, or other type of routing algorithm. One example of a VFL routing configuration table 254 for the virtual chassis system 100 shown in FIG. 1A is illustrated in Table 3 below.

Table 3

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

In one embodiment, the hardware device information HDI in the prepend header of the packet includes an outgoing VFID for the VFL port 252 associated with the destination chassis ID, as shown in Table 3 . The prepended header also includes hardware device information (HDI) associated with the source port that receives the packet, such as the port interface ID, the MID of the switching module 210, and the chassis ID. In one embodiment, additional information such as VLAN ID, packet type (multicast, unicast, broadcast), packet priority, and load balance identifier is also added to the prepended header.

The packet with the prepended header is then transmitted to the queuing module 212 for routing through the fabric switch 214. Based on the VFL routing configuration table 254, the queuing module 212 routes the packet with the prepended header to the switching module 210 connected to the egress VFL 120.

The queuing module 212 includes a packet buffer 260, queue management 262 for providing traffic and buffer management, and a global HDI address table 264. The global HDI address table 264 maps the outgoing VFL ID to the appropriate queues of the queuing module 212 of one or more of the other NIMs 152. For example, the queuing module 212 switches to an appropriate egress queue for one or more of the VFL port interfaces 252 for transmission via the egress VFL 120. In one embodiment, the determination of a discharge queue corresponding to a particular VFL port interface is operably based on a load balance identifier in a prepended header.

Although the switching module 210 and the queuing module 212 are illustrated as separate integrated circuits or modules, one or more functions or components of the module may be included on other modules, or may be combined into alternative modules, But may be implemented in other ways in the circuit.

FIG. 6 illustrates a schematic block diagram of one embodiment of a prepped header of a packet in a virtual chassis system 100. FIG. The prepended header 300 includes fields for the source HDI 302, the destination HDI 304, the VLAN ID 306, the packet type 308, the source MAC address 310 and the destination MAC address 312 . In one embodiment, the prepended header may also include a load balance identifier 314 and a packet priority 316. The destination HDI 304 may include a chassis ID, a port identifier (either a device port (dport) and / or a global port value (GPV)) of the destination network node 110 associated with the destination MAC address, and / Or the MID of the switching module 210. The source HDI 302 may include, for example, a chassis ID, a port identifier (either a device port (dport) and / or a global port value (GPV)) of the source network node associated with the source MAC address and / Lt; RTI ID = 0.0 > 210 < / RTI > The load balance identifier 314 is utilized by the queuing module 212 to determine a VFL member port for transmission of a packet via the egress VFL 120. The packet priority 316 is utilized by the queuing module 212 to determine a particular priority queue.

FIG. 7 illustrates a schematic block diagram of one embodiment of packet flow through network node 110a to another network node 110b of virtual chassis system 100. In FIG. In this example, the device 300 outside the virtual chassis system 100 having the source MAC address "MAC1" transmits a packet having the destination MAC address "MAC2 ". In this example, the network node 110a with chassis ID = 1 receives the packet on the switching module 210n with MID = 31, for example, on the external port interface with port ID = 2. The switching module 210n extracts the destination MAC address MAC2 and performs an address table lookup in the MAC / HDI forwarding table 250 to determine hardware device information HDI associated with the destination MAC address MACW. The destination HDI may include, for example, a port identifier associated with the destination MAC address, a destination chassis ID, and a device module identifier (MID). The destination HDI may also include an identifier of one or more other network codes or hardware modules in the path to the destination device associated with the destination MAC address. If the destination MAC address is associated with another network node, for example, if the destination chassis ID is not the local chassis ID, then the switching module 210 determines the leaving VFL ID associated with the destination chassis ID. The outgoing VFL ID may be added to the destination HDI in the prepended header. For the example of FIG. 5, the VFL routing table 254 indicates that the destination chassis ID = 2 is associated with the VFL 120 with VFID = 3.

The switching module 210n also includes source hardware device information (HDI) associated with the originating external port interface in the prepended header. The source HDI may include one or more hardware device identifiers, such as the MID of the switching switching module 210, the source port identifier, the MID for the source NIM 152, the source chassis ID, and so on. Further, in one embodiment, the prepended header includes a load balance identifier and packet priority determined based on parameters (source MAC address, destination MAC address, source IP address, destination IP address) taken from the original packet do.

The packet with the prepended header is sent to the queuing module 212n and the queuing module then determines the NIM 152 on the network node 110 for sending the packet based on the destination HDI. If the destination HDI represents a local external port interface on the network node (e.g., based on the destination MID included in the prepended header), then the queuing module may send the local external port interface to the corresponding NIM 152 The packet is placed in the discharge queue. In another example illustrated in FIG. 5, if the destination HDI indicates that a packet needs to be transmitted via the VFL 120 to another network node 110 of the virtual chassis system 100, the queuing module may send the packet The flow NIM 152 is determined from the VFL ID. In this example, the queuing module transmits a packet with a VFID = 3 to the NIM 152a operatively connected to the NIM 152a and having a prepended header to the NIM 152a via the fabric switch 214. When multiple switching modules 210 are operatively coupled to the egress VFL 120, the traffic to be transmitted may be distributed among the multiple switching modules 210 in a load balancing manner. In addition, the selection of VFL member ports (high priority queue, low priority, etc.) on the switching module 210 is operably based on the load balance identifier parameter carried in the prepended header. The queuing module 212a on the NIM 152a receives the packet with the prepended header and queues the packet for transmission via the VFL 120 with VFID = 3. The switching module 210a then sends the packet with the prepended header including the source and / or destination HDI to the network node 110b with chassis ID = 2 via the VFL 120 with VFID = 3 .

In one embodiment, the switching module 210a may modify the prepended header prior to transmission via the VFL 120. [ For example, the switching module 210a may convert a destination HDI (e.g., a gport value or a local hardware device identifier MID) having a local meaning to an HDI having globally meaningfulness, You can also delete the VFID.

In one embodiment, the MAC / HDI forwarding table 25 in the NIM 152 is populated and updated in response to a Layer 2 packet through the virtual chassis system 100. Because the prepended header includes the source MAC address and the source HDI information, the NIM 152 may provide the MAC / HDI forwarding table 250 with this information (e.g., Lt; / RTI > The switching module 210 is operable to communicate between the network modules 110 of the virtual chassis system 100 by operating in a prepped header mode to exchange Layer 2 packets with the source MAC address and the source HDI via the VFL 120. [ The MAC / HDI forwarding table 250 can be synchronized. Although the MAC / HDI forwarding table 250 and the VFL routing table 254 are described as being located within the switching module 210, the table may alternatively or additionally be used by the queuing module 212n or another May be included in the module. In another embodiment, the CMM 150 (primary and secondary) may also include a MAC / HDI forwarding table 250 and a VFL routing table 254.

FIG. 8 illustrates a schematic block diagram of an embodiment of a virtual chassis manager application or module 400 operable at a network node 110 of the virtual chassis system 100. In one embodiment of a network node 110 having a multi-slot based node architecture, the virtual chassis manager module 400 includes a central management module (CMM) 150 (VCM-CMM 402) and a designated network interface module (NIM) 152 (referred to as VCM-NIM 404) of the network node. In a stackable node architecture, a designated or master stackable network element 140 operates the VCM-NIM 404. The use of the designated NIM 152 or the stackable element 140 prevents the function of the VCM module 400 from concentrating on the CMM 150 alone. An example of the distribution of the functionality of the virtual chassis manager module 400 is shown in Table 4.

Table 4

In one embodiment, the VCM-CMM 402 includes a VCM module 400 operable on the network node 110 as well as interfaces between the virtual chassis manager module 400 and the element and / or network manager module 406, Lt; RTI ID = 0.0 > 408 < / RTI > Virtual chassis manager module 400 notifies registered application 408 when it should operate in virtual chassis mode. More generally, the virtual chassis manager module 400 notifies the interested application of the status of the virtual chassis system in the context of both the local node of the virtual chassis system 100 and the other network node 110 To provide a very wide range of notifications. While some of the status information is driven by the management configuration, other status information may be provided by the network nodes 110 in the virtual chassis system, in the context of control data exchange, negotiation and agreement, Lt; / RTI > The virtual chassis manager module 400 also includes a VLAN manager application module 410, a spanning tree protocol (STP) application module 412, a source learning application module 414, a link aggregation application module 416, Module 418, and for requesting services from these system components. For example, the VCM 400 may instruct the VLAN manager to configure the VFL member port as a member of the control VLAN to allow setup of the interprocess communication channel between the network nodes 110 of the virtual chassis system 100 You can also request it.

The VCM-NIM 404 performs the module identification configuration (e.g., MID) of the hardware module. In addition, the VCM-NIM 404 interfaces with the queue management 262 of the queuing module 212 to perform hardware device / queue mapping functions and inter-chassis loop prevention functions. In addition, the VCM-NIM 404 includes a virtual chassis state functionality for controlling and managing the VFL 120. Virtual Fabric Link Control manages and controls the VFL 120 and interfaces with the port manager application module 418 to monitor and / or control the status of the VFL 120 and their corresponding member ports . It also tracks and updates the state of the VFL 120. The VCM-NIM 404 keeps track of the status of each VFL member port, along with the status of the link at the physical level, using a standard LACP protocol, or other similar protocol. In addition to the LACP protocol, the virtual chassis state protocol performs a periodic keepalive check (hello protocol) to check the status and / or operability of components running on the designated NIM of both virtual-to-chassis switches. To avoid false / premature failure detection, all virtual chassis protocol packets must be assigned a high priority, since detection of such an early failure may have a very destructive impact on the system. By executing the virtual chassis state protocol on the primary designated NIM 152, the backup designated NIM module can take control of state protocol processing in case of failure.

The VCM-CMM 402 and VCM-NIM 404 register with the port manager application module 418 to receive port status and link status events for the member ports and links of the VFL 120. In another embodiment, the virtual chassis manager module 400 may include a port manager application module for monitoring 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, i.e., a generated / deleted / up / down set. The port manager application module 418 provides link state notification to both the VCM-CMM 402 and the VCM-NIM 404.

In one embodiment, a transport control protocol is implemented in the virtual chassis system 100 to transfer control protocol packets between the designated NIM 152 of the network node 110 or the stackable network element 140. The transmission control protocol is operable at the network node 110 with a different node architecture. For a multi-slot based node architecture, a designated NIM 152 with a designated processing module 266 operates a transmission control protocol, e.g., as part of the VCM-NIM 404. In a stackable node architecture, a designated or master stackable network element 140 operates a transmission control protocol.

The chassis supervisor module 420 provides an interface to the hardware of the network node 110 and controls monitoring and bootup or restart of various application modules and software reloading and software upgrading in-service software upgrade (ISSU), provides a command line interface (CLI) for the element manager module 406, accesses the state of the system of the network node 110, . During virtual chassis mode, the chassis supervisor module 420 provides an interface for controlling the boot sequence, controlling software reloading and ISSU, and accessing virtual chassis parameters.

A 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 from a standalone mode to a virtual chassis mode. In addition, the configuration manager module is operable to configure the virtual chassis manager module 400 and the multiple chassis manager module 424. The operation of the configuration manager module 422 and the operation of the state of the network node 110 are described in further detail below.

The network node 110 of the virtual chassis system 100 may operate in a plurality of operation modes including virtual chassis mode, independent mode, and multiple chassis (MC-LAG) mode. Various parameters and configurations are modified according to the operation mode. Table 5 illustrates the assignment of the chassis ID to the network node 110 according to the mode of operation.

Table 5

In stand-alone mode, the network node 110 operates as a single node and utilizes its configured local MAC address instead of the global virtual chassis MAC address. In multi-chassis mode, the two network nodes are configured as virtual nodes whose MAC forwarding tables and ARP tables are synchronized, but the name of the invention as filed on January 20, 2011 is "SYSTEM AND METHOD FOR MULTI-CHASSIS LINK AGGREGATION &Quot;, they still operate as separate bridges and routers, each of which uses their own local chassis MAC address, as described in U. S. Patent Application Serial No. < RTI ID = 0.0 > 13 / 010,168. In the virtual chassis mode as described herein, a plurality (N) of network nodes are configured as virtual chassis nodes of the virtual chassis system 100. A globally unique chassis ID from 1 to N is assigned to each of a plurality of network nodes of the virtual chassis system 100. [

If the network node 110 operates in stand-alone mode, the port identifier and configuration conforms to the following format: 0 / < slot > / < port >, where the chassis ID is equal to "0 & Element 140 or each network interface module (NIM) 152 of a multi-slot architecture, and the port is a port interface identifier. When the network node 110 operates in multiple chassis mode, the port configuration follows the following format: <chassis> / <slot> / <port>, where the chassis ID is equal to 1 or 2 and is active / current / Indicates the chassis ID. When the network node 110 operates in virtual chassis mode, the port configuration follows the following format: <chassis> / <slot> / <port>, where the chassis ID is 1, 2 ... N and represents the current / running / running chassis ID.

In the virtual chassis system 100, when a failure that is indicated as a loss of communication with the master network node 110 is detected, split or rupture occurs in the virtual chassis system 100. The topology of the virtual chassis system 100, and thus the services it provides, can be severely impacted if the network node 110 of the virtual chassis system is split into two or more subsets. This state is referred to as virtual chassis split or rupture. The virtual chassis system 100 may be configured with a redundant MAC address, a dual configurable resource (e.g., IP interface), connectivity loss, loss of management access, And range starting from instability due to multiple node reset events.

Virtual chassis splits can be triggered by failures in one or more of the network nodes 110, such as power failures, hardware / software malfunctions, software upgrades during service, and the like. In addition, the virtual chassis split can be configured to allow one or more of the VFLs 120 connecting the network node 110 to become inoperable, for example, the VFL 120 is physically disconnected, Or may be triggered by being down due to a hardware / software malfunction related to the module or link itself hosting the link. In one embodiment, upon occurrence of a virtual chassis split between two subsets of virtual chassis network 100, a first subset of network nodes 110 can no longer communicate with a second subset of master network nodes. The remaining active network nodes of the first subset elect a new master network node. In one embodiment, the remaining active network node retains the master MAC address of the failed master network node. In another embodiment, the remaining active network nodes adopt the local MAC address of the newly elected master network node as the new virtual chassis MAC address of the virtual chassis system 100.

FIG. 9 illustrates a schematic block diagram of one embodiment of master address maintenance in virtual chassis system 100. FIG. The master network node 110a can not communicate with the remaining nodes 110b and 110c of the virtual chassis system 100 due to a malfunction or a scheduled power down maintenance or inoperable VFL 120 link or other failure. The remaining network nodes 110b and 110c elect a new master network node, in this example, the network node 110b. In this embodiment, the remaining network nodes 110b and 110c maintain the MAC address of the previous master network node 110a as the virtual chassis MAC address for the virtual chassis system 100. [ The previous master network node 110a is removed from the MAC matrix of the topology database 144 and the remaining active network nodes 110b and 110c. This embodiment is referred to as master MAC hold because it maintains the previous master MAC address as the virtual chassis MAC address by the remaining active network node 110.

10 illustrates a schematic block diagram of one embodiment of a master address release in a virtual chassis system 100. In FIG. The master network node 110a can not communicate with the remaining nodes of the virtual chassis system 100 due to a malfunction or a scheduled power down maintenance or inoperable VFL 120 link or other failure. The remaining network nodes 110b and 110c elect a new master network node, in this example, the network node 110b. In this embodiment, the remaining network nodes 110b and 110c release the MAC address of the previous master network node 110a as a virtual chassis MAC address. The remaining active network nodes 110b and 110c adopt the local MAC address of the newly elected master network node 110b as the virtual chassis MAC address for the virtual chassis system 100. [ The previous master network node 110a is removed from the MAC matrix of the topology database and the remaining active network nodes 110b and 110c. This embodiment is referred to as the master MAC release because it releases the previous inactive master MAC address as the virtual chassis MAC address.

The remaining network node 110 determines whether to maintain 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 hold function is administratively enabled. Other factors may include whether the change in the state of the master network node causes a virtual chassis split in the system, e.g., using the MAC address of the master network node and / or the previous master network node where one or more other nodes failed Whether or not the apparatus is continuously operated. To determine whether a split has occurred in the virtual chassis system, a discovery or monitoring protocol or other type of control protocol is used to determine the topology before and after the failure of the master network node. If a split occurs in the virtual chassis system, for example, if the newly elected master network node determines that the previous master network node and / or one or more other nodes are still running, As the virtual chassis MAC address. The newly elected master network node may also switch the user port to a blocked state to prevent double operation as a virtual chassis MAC address of two MAC addresses.

FIG. 11 illustrates a schematic block diagram of one embodiment of a master network node failure in virtual chassis system 100. FIG. In this example, the master network node 110a fails and becomes inoperable. The newly elected master network node 110b may attempt to determine the status of the previous master network node 110a by performing one or more protocols (hello protocol, ping, etc.) And may request a status update of the node 110a. The newly elected master network node 110b attempts to distinguish between a failure of the VFL link 120a or a failure of the previous master network node 110a. If the newly elected master network node 110b determines that a failure has occurred in the previous master network node 110a, for example, that it is no longer operable, 9, the MAC address of the previous master network node 110a is maintained as the virtual chassis MAC address. If the previous master network node 110a is removed from the active topology database 144 and the newly elected master network node 110b maintains the MAC address of the previous master, the chassis supervision module 420 initiates a MAC hold timer do. The MAC hold timer is configurable and sets a predetermined time period during which the previous master network node 110a is reset and active. At the expiration of a predetermined period, if the previous master network node 110a is unable to continue to operate, a warning message is generated by the newly elected master network node 110b. The virtual chassis system manager issues a command to the user to release the held MAC address and adopts the local MAC address of the newly elected master network node 110b as the virtual chassis MAC address for the virtual chassis system 100 You can decide.

12 illustrates a schematic block diagram of an embodiment of a VFL failure in the virtual chassis system 100. As shown in FIG. In this example, the VFL 120a connected to the master network node 110a fails but the previous master network node 110a remains operational. The newly elected master network node 110b may attempt to determine the status of the previous master network node 110a by performing one or more protocols (hello protocol, ping, etc.) And may request a status update of the node 110a. The newly elected master network node 110b attempts to distinguish between a failure of the VFL link 120a or a failure of the previous master network node 110a. When the newly elected master network node 110b determines that the failure of the VFL 120a has occurred but the previous master network node 110a is operable, Releases the MAC address of the previous master network node 110a. The remaining active network nodes 110b and 110c adopt the local MAC address of the newly elected master network node 110b as the virtual chassis MAC address for the virtual chassis system 100. [ In addition, the newly selected master network node 110b switches the user port to the blocking state in order to prevent double operation as the virtual chassis MAC address of the two MAC addresses. The release of the MAC address of the previous master network node 110a also affects other Layer 2 and Layer 3 services as well. For example, the Spanning Tree Protocol and LACP may need to be reconfigured and / or restarted, while a Layer 3 packet may need to be transmitted to a neighboring node in response to a MAC address change.

FIG. 13 illustrates a logic flow diagram of an embodiment of a method 600 for recovering from a failure of a master network node in a virtual chassis system 100. In step 602, communication failure with the master network node of virtual chassis system 100 is detected due to malfunction or scheduled power down maintenance or inoperable VFL 120 link or other failure. The remaining network nodes of the virtual chassis system select a new master network node at step 604. In step 606, the newly elected master network node determines whether the MAC hold function is enabled. If so, then in step 608, the newly elected master network node determines whether the failure causes a split in the virtual chassis system, e.g., whether the master network node and / or one or more other nodes are inoperable, It is determined whether the MAC address is still being operated using the MAC address. If the virtual chassis split has not occurred, then in step 610, the remaining network node maintains the MAC address of the previous master network node 110a as the virtual chassis MAC address for the virtual chassis system 100. At step 612, a MAC hold timer is started to time a predetermined period of time. At step 614, at the expiration of the predetermined period, if the previous master network node 110a is still unable to operate, a warning message is generated by the newly elected master network node.

If the newly elected master network node determines in step 608 that a virtual chassis split has occurred, e.g., that the previous master network node is still running, or, in step 606, the MAC hold function is disabled, The newly elected master network node releases the MAC address of the previous master network node in step 616 as the virtual chassis MAC address. At step 618, the remaining active network nodes adopt the local MAC address of the newly elected master network node as the virtual chassis MAC address for the virtual chassis system 100.

The topology of the virtual chassis system, and thereby the service it provides to the end user, can be severely impacted if a virtual chassis split occurs. When the virtual chassis rollroot is split, the system begins with a dual MAC address, dual configurable resources (e.g., an IP interface), loss of access, loss of management access, and instability due to multiple switch reset events The problem of scope is faced. The virtual chassis split can typically be triggered by a failure in one or more of the network nodes 110, such as power failure, hardware / software malfunction, software upgrades during service, and the like. In addition, the virtual chassis split can be configured to allow one or more of the VFLs 120 to become inoperable, for example, if the VFL 120 is physically disconnected, removed, Or due to a hardware / software failure associated with the module or link itself. One reason for the virtual chassis split is to include an administrative action, such as an issuance of an administrative command that appears as a split of the topology by resetting or shutting down a portion of the virtual chassis system. Other management actions that may trigger a virtual chassis split include: a) configuring a different control VLAN on a separate network node in the virtual chassis topology; b) configuring a different hello interval on a separate network node in the virtual chassis topology; c) Inconsistent configuration of parameters, such as configuring different chassis groups on separate network nodes in the virtual chassis topology. Since the virtual chassis system 100 supports multiple network topologies and the network nodes may be geographically dropped, it may be difficult to predict the impact of the management action.

In one embodiment, the method and apparatus at network node 110 provide an alert to help prevent a virtual chassis split event that results, directly or indirectly, from a management action at virtual chassis system 100. For example, administrative actions that may appear directly or indirectly in a virtual chassis split include, among other things, resetting the network node, resetting the network interface module 152 hosting one or more VFLs 120 , Shutting down the VFL 120, setting the network node 110 in a shutdown / out-of-service state, and configuring mismatched parameters for the different network nodes 110 . In addition, other indirect events resulting from management actions that may appear directly or indirectly in a virtual chassis split include, among other things, that the switch is reset in response to ISSU (Software Upgrades During Service) The network interface module (NIM) 152 hosting one or more VFLs 120 may be down while performing operations. In one 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, an alert is generated when a management action is requested that may lead directly or indirectly to the virtual chassis split.

FIG. 14 illustrates a logic flow diagram of one embodiment of a method 700 for generating one or more reset lists in a virtual chassis system 100. FIG. At step 702, one or more control protocols are used by the network nodes to discover other network nodes 110 in the virtual chassis system 100 and exchange topology and configuration information. The network node 110 builds the topology database 144 of the virtual chassis system 100 using the topology information, as described herein. The topology database includes, for example, topology information of the following types: identification information (e.g., local MAC address, chassis identifier) for another network node 110, VFL 120 (or other active Identification information for the network interface module (NIM) 152 that hosts the network interface module (NIM) 152, and the associated member ports on the VFL 120 and the NIM 152 for hosting. The topology database 144 may also be replicated to the element manager module 406 that is maintained in the CMM 150 of the network node 110 and is operatively connected to the network node 110 of the virtual chassis system 100. [ This description of the topology database 144 includes example information, but other information and data not described herein may also be included in the topology database. The topology database 144 may also be stored in a separate database or table or may be combined with other tables or databases in the network node 110. [

In step 704, the topology information is analyzed to determine one or more reset lists or structures that indicate the impact of one or more management actions on the virtual chassis system 100. For example, a network node reset list that includes a list of network nodes 110 triggering a virtual chassis split is generated by itself when reset. It may also include a list of network nodes that need to be reset at the same time to prevent virtual chassis splitting in the system. A list of network interface modules 152 hosting the active VFL 120 and a list of network interface module resets containing a status indicating whether resetting the network interface module 152 will cause a virtual chassis split do. Other reset lists and structures not described herein that show the effect of one or more management actions on the virtual chassis system 100 may also be generated.

In one embodiment, the reset list is accessed in response to one or more management actions to provide information about the possible impact of the management action. For example, to reload or reset the network node 110, to reload or reset the network interface module (NIM) 152, to disable the network interface module 152, to shut down the network node During the processing of management actions, such as to perform an ISSU, to disable a port interface, to disable a VFL 120, and the like, a device (network node, NIM Or port interface).

If the reset list indicates that the management action will not result in a virtual chassis split, the processing of the management action continues. However, if the reset list indicates that the management action may cause a virtual chassis split, a warning is displayed. The warning includes, for example, an indication that a virtual chassis split may occur in response to a management action. The warning may also include one or more suggestions for preventing a virtual chassis split, such as an intended device (e.g., a network node, NIM or port interface) to one or more other devices (e.g., a network node, NIM, &Lt; / RTI &gt; In another embodiment, the processing of the management action is blocked. Other messages or warnings are issued that contain a notification of nonperformance of the management action.

FIG. 15 illustrates a schematic block diagram of one embodiment of the generation of a reset list in the virtual chassis system 100. FIG. In this embodiment, a list of network node resets providing a corresponding indicator of whether a list of chassis identifiers of the network nodes and a reset of the network nodes may cause a virtual chassis split in the virtual chassis system is generated. Resetting a network node includes shutdown, reboot, reset, power-off, outage, or inactivity that is otherwise created in response to a management action. For example, the management action may include an administrative command for resetting the network node, for rebooting the network node, for shutting down the power of the network node, or for setting the state of the network node 110 to shutdown or out of service Or other management action where the network node becomes inoperable. The topology information of the topology database 144 includes the available paths between the network nodes 110 of the virtual chassis system 100. In the example of FIG. 15 having a linear topology of network nodes 110a, 110b and 110c, the topology database 144 is configured to map the available paths between network nodes 110a, 110b and 110c, Information.

Table 6

In this example of topology information in virtual chassis system 100 of FIG. 15, a reset of network node 110a (with chassis ID = 1) will not cause a virtual chassis split in the system. Likewise, resetting network node 110c (with chassis ID = 3) will not cause a virtual chassis split in the system. However, resetting network node 110b (with chassis ID = 2) will cause a virtual chassis split in the system because the first subset of nodes (network node 110a) 2 &lt; / RTI &gt; (network node 110c). &Lt; RTI ID = 0.0 &gt; In this exemplary embodiment, to prevent virtual chassis splitting, the network node reset list indicates that the combination of network nodes 110b and 110c must be reset simultaneously to prevent virtual chassis splitting. Table 7 below illustrates an exemplary network node reset list for this embodiment of the virtual chassis system 100.

Table 7

The reset list is stored in the reset list table 710 in the CMM 150 of one or more network nodes 110 of the virtual chassis system 100 and / or in the element manager module 406 operatively connected to the virtual chassis system 100. [ / RTI &gt; In one embodiment, the reset list 710 is generated or stored by the element manager module 406. Once the management action is entered into the element manager module, the element manager module 406 performs an analysis of the reset list 710 and determines whether to issue a warning to the management action. The element manager module 406 includes devices or remote devices that are locally connected to one or more of the network nodes 110. In another embodiment, CMM 150 of one or more network nodes 110 of virtual chassis system 100 generates or stores a reset list 710. When a management action is received by the CMM 150 of the network node 110, the CMM 150 accesses the reset list 710 and determines whether to issue a warning for the management action.

FIG. 16 illustrates a logic flow diagram of an embodiment of a method 750 for generating a network node reset list in a virtual chassis system 100. FIG. Analysis is performed for a plurality of network nodes 110 of the virtual chassis system 100. At step 752, one of the network nodes 110 (e.g., the source network node) of the plurality of network nodes 110 is selected for analysis. In step 754, topology information in the topology database 144 is accessed to determine a first destination node from the source network node. The number of paths between the source node and the destination node is determined from the topology information in the topology database 144 at step 756. At step 758, if the number of paths is greater than one, at step 762, for a reset ID = destination network node, the warning state for the virtual chassis split is false. Resetting the destination node will not split or disconnect the source network node from the virtual chassis system 100 because there are multiple paths. In step 758, if the number of paths is equal to 1, and in step 760, if the destination node is the last hop along the path, then in step 762, for the reset ID = destination network node, the alert state for the virtual chassis split is It is false. At step 758, if the number of paths equals one and at step 760 the destination node is not the last hop along the path, then at step 764 reset ID = for the destination network node, a warning state for the virtual chassis split Is true. In step 766, the analysis determines another node on the path between the source network node and the destination network node. The destination network node and other network nodes are listed as a proposal to simultaneously reset on the network node reset list to prevent virtual chassis splitting. In step 768, it is determined whether another destination node needs to be analyzed. If yes, the process continues at step 754. If no additional destination node needs to be analyzed, at step 770, a network node reset list for the source network node is stored.

FIG. 17 illustrates a schematic block diagram of another embodiment of the generation of a reset list in the virtual chassis system 100. FIG. If one or more NIMs 152 hosting VFL 120 are reset, a virtual chassis split may be caused. The reset of NIM 152 includes shutdown, reboot, reset, power shutdown, service outage, or inability to operate in other ways in response to a management action. For example, at network node 110b, NIM 152c hosts VFL 120a operatively connecting network nodes 110a and 110b. If the NIM 152 is reset in response to the management action, the VFL 120a will become inoperable and cause a virtual chassis split to the system. The first subset of nodes (network node 110a) will be split and will not be able to communicate, for example, with the second subset of nodes of the system (network nodes 110b and 110c). In one embodiment, to prevent virtual chassis splitting, a network interface module reset list is generated that includes a list of NIMs that should not be disabled in response to management actions to prevent virtual chassis splits. The following Table 8 illustrates an exemplary network interface module reset list for one embodiment of the virtual chassis system 100 of FIG. The network interface module is identified by its chassis ID and slot number.

Table 8

In one embodiment, a warning may include suggestions for reconfiguring VFL 120 to another NIM 152 prior to resetting NIM 152 to cause a virtual chassis split.

In another embodiment, resetting port interface 240, which is the active member port of VFL 120, may cause a virtual chassis split. For example, resetting a VFL member port includes disabling the port interface in a different manner in response to a shutdown, reboot, reset, power down, outage, shutdown mode, or management action. For example, a virtual chassis split may appear in response to a management action and the response may be to leave the port interface in blocked mode, reset the port interface, reboot the port interface, shut down the port interface, , Or otherwise disable the port. In one embodiment, to prevent virtual chassis splitting, an indicator of whether a warning should be issued to prevent virtual chassis splitting when the corresponding port interface 240 should be reset, and an indication of whether a port interface The VFL member port reset list including the list of the VFL member ports 240 is generated. The following Table 9 illustrates an exemplary VFL member port reset list for an embodiment of the virtual chassis system 100 of FIG. The port interface is identified by the chassis ID of its network node 110, the slot number of its NIM 152, and the port ID.

Table 9

In one embodiment, the alert may include suggestions for reconfiguring the member port interface of the VFL 120 to another port interface 240 prior to resetting the port interface to cause a virtual chassis split.

FIG. 18 illustrates 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 a virtual chassis system 100. An analysis is performed on the NIM 152 (identified by the slot ID) for one network node 110 of the plurality of network nodes 110 of the virtual chassis system 100. In step 802, a first NIM 152 of one of the network nodes 110 (e.g., the source network node) of the plurality of network nodes 110 is selected for analysis. In step 804, topology information in the topology database 144 is accessed to determine whether the selected NIM includes a VFL member port. At step 804, if there is no VFL member port on the NIM, then at step 808, for the chassis ID, slot ID for reset ID = NIM, the warning state for the virtual chassis split is false. In step 804, if there is a VFL member port on the NIM, the topology information in the topology database 144 is accessed to determine whether the NIM is hosting all VFL member ports for the VFL (e.g., The other NIM on the VFL also hosts the VFL member port for the VFL). If not, at step 808, for the reset ID = NIM, for the chassis ID, slot ID, the warning state for the virtual chassis split is false. At step 806, if the NIM hosts all the member ports for the VFL, then at step 810, topology information in the topology database 144 is accessed and a number of paths (e.g., VFLs) between the source network node and the destination node, . At step 812, if another path or VFL connects the source and destination nodes, at step 808, for the chassis ID, slot ID for reset ID = NIM, the warning state for the virtual chassis split is false. In step 812, if the NIM is hosting a member port of a VFL that is the only path or connection between the source network node and the destination network node, then topology information in the topology database 144 is accessed in step 814, And determines whether the VFL in the path is the next hop. If not, at step 808, for the reset ID = NIM, for the chassis ID, slot ID, the warning state for the virtual chassis split is false. In step 814, if the NIM hosts the only member port for the next hop VFL in the path to the destination network node, then in step 816, for the chassis ID, slot ID for reset ID = NIM, the alert state for the virtual chassis 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 in 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 for the VFL. Otherwise, in step 820, for the chassis ID, slot ID, and port ID for the reset ID = VFL member port, the warning indicator for the virtual chassis split is false. In step 818, if the member port of the VFL on the NIM is the only member port for the VFL, then in step 822, for the chassis ID, slot ID, port ID for the reset ID = VFL member port, It is true. This analysis of FIG. 18 is performed to generate a network interface module reset list and / or a VFL member port reset list of the virtual chassis system 100.

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

19 illustrates a logic flow diagram of an embodiment of a method 850 for processing a management action that aids in preventing virtual chassis splitting in virtual chassis system 100. FIG. In one embodiment, a management action is received at step 852. [ Management actions include the identifiers and management commands of network node 110, NIM 152 or port interface 240. In response to the management action, at step 854, one or more of the reset list is accessed. For example, to reload or reset network node 110, to reload or reset NIM 152, to disable NIM 152, to shut down network node 110, During the processing of a management action, such as to disable the port interface 240, to disable the VFL 120, to perform a management action, to perform a management action , NIM, or port interface), one or more of the reset list is accessed. For example, a network node reset list, a NIM reset list, and / or a VFL member port interface reset list are accessed. Other or additional lists may also be accessed to determine whether to issue alerts regarding the virtual chassis split. In step 856, it is determined whether to issue a warning of the virtual chassis split in response to the management action.

If it is determined not to issue a warning, for example, if one or more of the reset list indicates that the management action will not cause a virtual chassis split, then processing of the management action continues at step 858. However, if it is determined to issue a warning, for example, if the reset list indicates that the management action may result in a virtual chassis split, a warning is issued and sent to the user device for display. The warning includes, for example, an indication that a virtual chassis split may occur in response to a management action. The warning may also include one or more suggestions for preventing virtual chassis splitting, e.g., resetting the intended device with one or more other devices specified in the reset list (e.g., resetting one or more other network nodes) have. The warning may also include suggestions for reconfiguring the VFL member port interface 240 to one or more other NIMs 152 before performing the management action.

In one embodiment, the alert is displayed by an element manager module of a graphical user interface, such as a command line interface (CLI), WebView, or an alternative management application. In one embodiment, a management action is performed in accordance with an alert proposal, such as canceling a management action, continuing the management action despite the warning, and rebooting the intended device (s) and other devices in the proposed reset list One or more options are provided, such as continuing with the &lt; / RTI &gt; In another embodiment, the processing of the management action is blocked. Other notifications or warnings are issued that contain notifications of undeclared management actions.

The reset list aids in alerting the virtual chassis split in response to management actions in the virtual chassis system. This prevention may be based on a risky event caused by a virtual chassis split, such as a duplicate MAC address, a dual configurable resource (e.g., IP interface), loss of access, loss of management access, Resulting in a more stable and robust system.

FIG. 20 illustrates a logic flow diagram of an embodiment of a method 900 for processing management actions for configuring one or more parameters to help prevent virtual chassis splitting in virtual chassis system 100. FIG. For example, a management action that may trigger a virtual chassis split may include, for example: a) configuring a different control VLAN on a separate network node 100 in the virtual chassis topology; b) configuring different intervals for health monitoring messages (e.g., Hello or Keep Alive messages) on a separate network node 100 in the virtual chassis topology; c) configuring the parameter mismatch for the network node 110, such as configuring different chassis groups (virtual chassis system identifiers) on separate network nodes 100 in the virtual chassis topology. For example, if the network node 110 of the virtual chassis system is configured with a different virtual chassis system identifier, the network node 110 may transfer the virtual chassis split to a different virtual chassis system. In addition, configuring different control VLANs for control packets may lead to virtual chassis splits, with control packets being dropped and not processed. In addition, configuring different hello intervals for health monitoring may result in erroneous conclusions that a node or module of a node has failed. Other misconfiguration of parameters not disclosed herein may also lead to failures or module malfunctions leading to a virtual chassis split.

At step 902, a management action is received to configure one or more parameters on one or more network nodes 110. At step 904, the configuration is analyzed to determine if one or more parameters are colliding among the network nodes 110 of the virtual chassis system, or will lead to failure in another manner or lead to a virtual chassis split. If, at step 906, the configuration may lead to a failure, at step 910, a warning is issued for the management action. The warning includes, for example, an indication that the conflict parameters and / or configuration between network nodes may lead to a failure or virtual chassis split. The warning may also include one or more suggestions for preventing a failure or virtual chassis split, such as different configuration parameters. In another embodiment, the processing of the management action is blocked. Other notifications or warnings are issued that contain notifications of undeclared management actions.

If it is determined in step 906 that the configuration of the parameter does not lead to a failure or a virtual chassis split, processing of the management action continues in step 908.

As used herein, "operably linked", "connected to", and / or "connecting" to the term (s) And indirect connection between items, wherein the intermediate item does not modify the information of the signal but has its current level, voltage level, And / or adjust the power level. As may be further used herein, an inferred connection (i.e., when one element is connected by reasoning to another) includes direct and indirect connections between two items in the same manner as "connected to".

As may further be used herein, the term " operable to " or "operable to be connected to" means that the item, upon activation, has a power connection, input (s) (S), etc., and may further include inferred connections to one or more other items. As may still further be used herein, the term "associated with" is intended to encompass items that are embedded in separate items and / or other items, or items of one item / Includes indirect connections. As may be used herein, the term "preferably compare" indicates that a comparison between two or more items, signals, etc. provides a desired relationship. For example, if signal 1 is greater than signal 2 A preferred comparison may be achieved when the magnitude of signal 1 is greater than the magnitude of signal 2 or when the magnitude of signal 2 is less than the magnitude of signal 1. [

The terms "processing module "," processing circuit ", and / or "processing unit ", as may be used herein, may be a single processing device or a plurality of processing devices. Such a processing device may be a microprocessor, microcontroller, digital signal processor, microcomputer, central processing unit, field programmable gate array, programmable logic device, state machine, logic circuitry, analog circuitry, digital circuitry, and / Or any device that manipulates signals (analog and / or digital) based on hardcoding of the circuitry. The processing module, module, processing circuitry, and / or processing unit may be or may further comprise memory and / or integrated memory elements, which may be a single memory device, a plurality of memory devices, and / Module, processing circuit, and / or embedded circuit portion of the processing unit. Such memory devices may be 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. If a processing module, module, processing circuit, and / or processing unit includes more than one processing device, the processing device may be centrally located (e.g., directly via a wired and / (E.g., cloud computing via an indirect connection via a local area network and / or a wide area network). A processing module, a module, a processing circuit, and / or a processing unit may be implemented as a processor, processor, and / or device that implements one or more of its functions, via a state machine, analog circuitry, digital circuitry, and / And / or memory elements may be embedded within or outside the state machine, analog circuitry, digital circuitry, and / or logic circuitry. The memory elements may store hard-coded and / or operational functions corresponding to at least some of the steps and / or functions illustrated in one or more of the figures, and the processing modules, modules, processing circuitry, and / It is also noted that it may be implemented. Such a memory device or memory element may be included within the article of manufacture.

The invention has been described above with the aid of method steps illustrating the performance of particular functions and their associated functions. The boundaries and sequences of these functional building blocks and method steps have been arbitrarily defined herein for convenience of explanation. Alternate boundaries and sequences may be defined as long as the particular function and associated function are performed properly. Accordingly, any such alternate boundary or sequence is within the scope and spirit of the claimed invention. In addition, the boundaries of these functional building blocks have been arbitrarily defined for convenience of explanation. As long as certain important functions are performed properly, alternative boundaries may be defined. Likewise, a flowchart block is also arbitrarily defined herein to illustrate certain important functionality. Within the scope of use, the flowchart block boundary and sequence will be defined in a different manner and will continue to perform some important functionality. Accordingly, such alternative definitions of functional building blocks and flowchart blocks are within the scope and spirit of the claimed invention. Those skilled in the art will appreciate that the functional blocks and other illustrative blocks, modules, and components described herein may be implemented or combined as illustrated or may be implemented as separate components, on-demand semiconductors, &Lt; / RTI &gt;

The invention is herein described, at least in part, by one or more embodiments. DESCRIPTION OF THE PREFERRED EMBODIMENTS One embodiment will be described to illustrate the present invention, its aspects, its characteristics, its concept, and / or its examples. Physical embodiments of a device, article of manufacture, machine, and / or process embodying the invention may include one or more of the aspects, features, concepts, and / or the like described with reference to one or more of the embodiments discussed herein It is possible. Also, throughout the drawings, the embodiments may incorporate the same or similarly named functions, steps, modules, etc. that may use the same or different reference numerals, and thus the functions, steps, modules, Functions, steps, modules, etc., or may be different.

Unless specifically stated otherwise, signals between elements, elements, and / or elements in the figures provided herein may be analog or digital and may be continuous or discontinuous, Type or differential type. For example, when the signal path is shown as a single ended path, it also represents a differential signal path. Similarly, when the signal path is shown as a differential path, it also represents a single ended type signal path. Although one or more specific architectures are described herein, other architectures that use one or more data buses, direct connections between elements, and / or indirect connections between other elements may also be implemented that are not explicitly shown.

The term "module" is used in the description of various embodiments of the present invention. A module includes a processing module (as described above), a functional block, hardware, and / or software stored on a memory operable to perform one or more functions as described herein. Note that if a module is implemented in hardware, the hardware may operate independently and / or operate 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 hardware for executing software stored in the memory of the module to perform the functions as described herein. The modules described herein may include one or more sub-modules, each of which may be one or more modules, integrated into one or more other modules, or may include one or more other modules.

Although specific combinations of various features and features of the invention are set forth herein, other combinations of these features and functions are equally possible. The embodiments described herein are not limited by the specific examples described and may include other combinations and embodiments.

Claims (10)

A network node operable in a virtual chassis system,
One or more network interface modules operable to couple to a plurality of virtual fabric links (VFLs), the VFL being operatively connected to a plurality of network nodes in the virtual chassis system,
Comprising at least one management module,
The at least one management module
Access to a topology database of topology information, said topology information comprising a chassis identifier of said plurality of network nodes, and a VFL member port interface coupled to said plurality of virtual fabric links (VFL) - &lt; / RTI &gt;
Generate one or more reset lists based on the topology database, the one or more reset lists
A chassis identifier of one or more of the plurality of network nodes of the virtual chassis system and a corresponding indicator of whether the reset of the chassis identifier triggers a virtual chassis split,
A NIM identifier for one or more network interface modules (NIMs) at one or more of the plurality of network nodes of the virtual chassis system, and whether a reset of the one or more NIM identifiers triggers a virtual chassis split &Lt; / RTI &gt;
A VFL member port identifier for one or more of the plurality of network nodes of the virtual chassis system and a corresponding indicator of whether a reset of the VFL member port triggers a virtual chassis split
- &lt; / RTI &gt;
The method comprising: receiving a first administrative action, the first management action including a chassis identifier of at least one of the plurality of network nodes in the virtual chassis system;
Accessing one or more reset lists, wherein the one or more reset lists include a chassis identifier of one or more of the plurality of network nodes of the virtual chassis system, and a corresponding indicator of whether the reset triggers a virtual chassis split - &lt; / RTI &gt;
Determining from the one or more reset lists and the first management action whether the first management action will issue an alert that triggers a virtual chassis split,
Issuing a warning for the first management action when the first management action triggers a virtual chassis split, the alert blocking the first management action, and performing a nonperformance of the first management action, Including a notification of
Network node.
The method according to claim 1,
The at least one management module
Wherein the at least one reset list indicates to issue from the one or more reset lists if the first management action indicates issuing the alert that triggers the virtual chassis split, Further operable to determine whether the node &apos; s chassis identifier is listed &lt; RTI ID = 0.0 &gt;
Network node.
3. The method of claim 2,
The first management action
An administrative command for resetting said at least one of said plurality of network nodes identified by said chassis identifier;
An administrative command for rebooting said at least one of said plurality of network nodes identified by said chassis identifier;
An administrative command for interrupting the at least one power out of the plurality of network nodes identified by the chassis identifier;
An administrative command for setting the at least one shutdown state among the plurality of network nodes identified by the chassis identifier;
And a management command for setting the at least one out-of-service state among the plurality of network nodes identified by the chassis identifier
Lt; RTI ID = 0.0 &gt;
Network node.
delete A method in a network node operable in a virtual chassis system comprising a plurality of virtual fabric links (VFL) operatively connected to a plurality of network nodes,
Accessing a topology database of topology information for the virtual chassis system, the topology information including a chassis identifier of the plurality of network nodes, and a VFL member port interface coupled to the plurality of virtual fabric links (VFL) And an identification of the network interface module,
Generating one or more reset lists based on the topology database, the one or more reset lists
A corresponding indicator of whether the reset of the one or more chassis identifiers and the chassis identifiers of the plurality of network nodes of the virtual chassis system triggers a virtual chassis split,
A NIM identifier for one or more network interface modules (NIMs) at one or more of the plurality of network nodes of the virtual chassis system, and whether a reset of the one or more NIM identifiers triggers a virtual chassis split &Lt; / RTI &gt;
A VFL member port identifier for one or more of the plurality of network nodes of the virtual chassis system and a corresponding indicator of whether a reset of the VFL member port triggers a virtual chassis split
- at least one of &lt; RTI ID = 0.0 &gt;
Receiving a first management action, wherein the first management action includes a chassis identifier of at least one of the plurality of network nodes of the virtual chassis system;
Accessing one or more reset lists, wherein the one or more reset lists include a chassis identifier of one or more of the plurality of network nodes of the virtual chassis system, and a reset of the one or more network nodes of the plurality of network nodes, Comprising a corresponding indicator of whether to trigger a chassis split,
Determining from the one or more reset lists and the first management action whether to issue a warning that the first management action triggers a virtual chassis split;
Issuing a warning for the first management action when the first management action triggers a virtual chassis split, the alert interrupting the first management action and including a notification of undecomplete execution of the first management action box-
Containing
A method at a network node operable in a virtual chassis system.
6. The method of claim 5,
Wherein the at least one reset list indicates that the first management action is to issue the alert that triggers the virtual chassis split from the at least one reset list, Further comprising determining whether the node &apos; s chassis identifier is listed
A method at a network node operable in a virtual chassis system.
The method according to claim 6,
Wherein the first management action comprises:
An administrative command for resetting said at least one of said plurality of network nodes identified by said chassis identifier;
An administrative command for rebooting said at least one of said plurality of network nodes identified by said chassis identifier;
An administrative command for interrupting the at least one power out of the plurality of network nodes identified by the chassis identifier;
An administrative command for setting the at least one shutdown state among the plurality of network nodes identified by the chassis identifier;
An administrative command for setting the at least one service out of the plurality of network nodes identified by the chassis identifier
Lt; RTI ID = 0.0 &gt;
A method at a network node operable in a virtual chassis system.
delete 6. The method of claim 5,
Receiving a second management action, the second management action comprising a first network interface module (NIM) identifier for one of the NIMs at one of the plurality of network nodes;
Accessing one or more reset lists to determine whether to issue the alert that the second management action triggers a virtual chassis split, the alert blocking the second management action, Further comprising a notification of non-performance
A method at a network node operable in a virtual chassis system.
10. The method of claim 9,
Receiving a third management action, the third management action including a first VFL member port interface identifier;
Accessing one or more reset lists to determine whether the third management action will issue the alert that triggers a virtual chassis split, the alert blocking the third management action, Further comprising a notification of non-performance
A method at a network node operable in a virtual chassis system.

Images