JP6017383B2 - COMMUNICATION DEVICE AND COMMUNICATION DEVICE CONTROL METHOD - Google Patents

Description

  The present invention relates to a communication apparatus and a control method for the communication apparatus.

  For example, in Patent Documents 1 and 2, as a board in a communication device, a device control unit (hereinafter also referred to as BCU) that controls the entire communication device and a network interface board (hereinafter also referred to as NIF) that controls a network interface. And a board for transferring packets between NIFs. Patent Documents 1 and 2 disclose a configuration in which a board for transferring a packet between a BCU and an NIF is separated. In Patent Document 1, Switch Controller 6 corresponds to a BCU, and Switch Sections 31 and 32 correspond to a board that transfers packets between NIFs.

  In Patent Document 2, Controller Cards 145 and 210 correspond to BCUs, and Switch Cards 125 and 130 and Switch Fabric 220 correspond to boards that transfer packets between NIFs.

  Patent Document 3 discloses a configuration in which a board for transferring a packet between a BCU and an NIF is integrated. In Patent Document 3, RM 60 corresponds to a BCU, and Crossbar Switch 20 corresponds to a board that transfers packets between NIFs.

  Patent Document 4 discloses a board that transfers packets between NIFs, including a destination search function and a filtering function. The destination search function searches from which interface (network port) the packet should be transmitted after receiving the packet from the network interface (network port). The control board 10 corresponds to a BCU, and the relay processing board 100 corresponds to a board that transfers packets between NIFs. The relay processing board 100 has a destination search function and a filtering function.

  Patent Document 5 monitors the abnormality of the in-device signal, and the board failure position on the transmission path of the in-device signal based on the number of boards for each group that has transmitted the in-device signal in which the abnormality is detected and the mounting position information. Is disclosed. The technique disclosed in Patent Document 5 is not a technique related to an interface failure between boards.

US Patent No. 7756013 US Patent No. 7778469 JP 2000-244570 A JP 2007-228490 A JP 2010-213074 A

  When a fault is detected on an interface with another boat on a board in a communication device disclosed in the background art, the communication device indicates that the fault is due to a failure of the board that sent the signal, or Without determining whether or not the failure occurred in the board that received the signal, the operator determined that one of the boards failed and replaced the board.

  As a method for determining a board that has failed, for example, a vertical relationship is determined between the types of boards, and it is determined that the lower-level board has failed. For example, in a certain determination method, a board close to a line in a communication device is defined as a lower level, and a board that performs common processing in the communication device is defined as a higher level. Thereby, the range which communication stops can be localized.

  However, if a failure is detected at the interface between the boards, if it is determined that the lower board has failed, it is actually necessary to replace the wrong board if the upper board has failed. Become.

  One embodiment of the present invention is a communication device including first and second group boards that transfer received data and a controller. Each of the first group of boards is communicably connected to the second group of boards. The controller detects a first interface failure between the first board in the first group and the second board in the second group. The controller specifies the number of interfaces in which a failure is detected between the first board and the second group of boards. The controller specifies the number of interfaces in which a failure is detected between the second board and the first group of boards. The controller determines whether the cause of the first interface failure is a failure of the first board based on a failure detection result on the first board and a failure detection result on the second board. . For example, the controller is configured such that the number of interfaces detected in the first board is greater than 1 based on a failure detection result in the first board and a failure detection result in the second board, and the second board When the number of interfaces in which a failure is detected is 1, it is determined that the cause of the first interface failure is a failure of the first board.

  According to one embodiment of the present invention, when a failure is detected between boards of a communication device, the possibility of replacing an incorrect board can be reduced.

It is a block diagram which shows typically the structural example of a communication apparatus. A relationship between a board in which a failure has occurred and a board in which a failure has been detected in one interface between the SFU and the PPU is shown. The structural example of a SFU connection relation table is shown. The structural example of a PPU connection relation table is shown. The structural example of the PPU redundant structure table 1026 is shown. The structural example of a SFU state management table is shown. The structural example of a PPU state management table is shown. The structural example of a failure determination interface table is shown. The structural example of a failure information management table is shown. The structural example of a SFU interface failure detection counter table is shown. The structural example of a PPU interface failure detection counter table is shown. It is a flowchart which shows the whole flow of operation | movement of BCU10. It is a flowchart which shows the detail of step 6101 in the flowchart of FIG. The structural example of the OBP / CLK part which is a detector which detects the failure in a board is shown. It is a flowchart which shows the example of an interface failure check (6002) in the flowchart of FIG. It is a flowchart which shows the example of a redundancy state check (6003) in the flowchart of FIG. It is a flowchart which shows the example of the operation / standby state check (6004) in the flowchart of FIG. An example of determining an SFU as a failure in step 6006 (determining that a board that has detected a failure in a plurality of interfaces as a failure) in the flowchart of FIG. 13 is shown. An example of determining an SFU as a failure in step 6006 (determining that a board that has detected a failure in a plurality of interfaces as a failure) in the flowchart of FIG. 13 is shown. FIG. 13 shows an example in which the PPU is determined to be faulty in step 6006 (determining that a board having detected faults at a plurality of interfaces is faulty) in the flowchart of FIG. An example of step 6007 in the flowchart of FIG. 13 (determining that the redundant board is faulty) is shown. An example of step 6007 in the flowchart of FIG. 13 (determining that the redundant board is faulty) is shown. FIG. 13 shows an example of step 6008 (determined that the board in the standby state is faulty) in the flowchart of FIG. FIG. 13 shows an example of step 6008 (determined that the board in the standby state is faulty) in the flowchart of FIG.

  Embodiments of the present invention will be described below with reference to the accompanying drawings. It should be noted that this embodiment is merely an example for realizing the present invention, and does not limit the technical scope of the present invention. In each figure, the same reference numerals are given to common configurations.

  When a failure is detected in an interface between boards in the communication device, the communication device according to the present embodiment determines which board on the interface is caused by the failure. The communication device includes a plurality of boards in a first group and a plurality of boards in a second group, and each board is connected to a plurality of boards in the other group so that data communication is possible.

  In one example, when a communication apparatus according to the present embodiment detects a failure in one interface between boards, the communication apparatus identifies the number of interfaces in which the failure is detected in each board of the interface. When a failure on multiple interfaces is detected on one board and a failure on only one interface (failure on a single interface) is detected on the other board, the communication device is a board on which a failure is detected on multiple interfaces. Is determined to be a failure.

  In one example, the communication apparatus according to the present embodiment determines step by step which board has failed in the interface where the failure is detected. According to the stepwise determination of the present embodiment, the possibility of failure can be determined as a board failure, and further, the influence on communication due to replacement of the failure board can be reduced.

  In the first stage, when a failure is detected by a failure detector in the board, it is determined that the board is in failure. A faulty board can be correctly determined when there is clear evidence to determine that the board is faulty.

  If the failed board cannot be identified in the first stage, the second stage determines the failed board based on the number of interface faults detected in each board. If a plurality of interface failures are detected on one board and a failure is detected on a single interface on the other board, it is determined that the board on which the plurality of interface failures are detected is a failure. Thereby, it is possible to determine that the board having the higher possibility of failure is a failure.

  Hardware failures generally occur independently, and the possibility that multiple independent failures occur simultaneously is small. When a failure is detected at the same time on an interface between a board and a plurality of boards, it is appropriate to determine that an interface failure has occurred due to the failure of this one board. By determining that the board is faulty, it is possible to prevent a plurality of boards on the opposite side from being simultaneously judged to be faulty and the communication stop range from being widened.

  If the failed board cannot be identified in the second stage, the communication device executes the third stage. When one board is made redundant and the other board is not made redundant, the communication apparatus determines that the redundant board has failed. Thereby, it is possible to guarantee the continuation of communication using another board having a redundant configuration.

  If the failed board cannot be identified in the third stage, the communication device executes the fourth stage. When one board is in the operating state and the other board is in the standby state, the communication apparatus determines that the board in the standby state has failed. Thereby, switching of the redundant state can be prevented, and instantaneous interruption due to switching of the redundant state can be prevented.

  If the failed board cannot be identified in the fourth stage, the communication device executes the fifth stage. The communication apparatus determines that a board in a predetermined group is faulty. As a result, it is always possible to decide which of the boards is determined to be a failure.

  Some of the above four steps may be omitted. For example, the communication device may execute only the second stage, or may execute only the first and second stages or only the second and third stages.

  Hereinafter, the communication apparatus according to the present embodiment will be specifically described. FIG. 1 is a block diagram schematically illustrating a configuration example of a communication apparatus according to the present embodiment. The communication device includes duplexed device control units (hereinafter also referred to as BCUs) 10 and 11, and network interface boards (hereinafter also referred to as NIFs) 40 to 47. The communication apparatus further includes packet processing units (hereinafter also referred to as PPU) 30 to 33 and switch fabric units (hereinafter also referred to as SFU) 20 to 23 that transfer packets between the PPUs.

  Each of the NIFs 40 to 47 controls one or a plurality of network interfaces (network ports). The PPUs 30 to 33 accommodate the NIFs 40 to 47, respectively, and perform packet destination search, filtering to discard illegal packets, and packet transfer. The SFUs 20 to 23 transfer packets between the PPUs 30 to 33.

  Each of the BCUs 10 and 11 can control the entire communication apparatus. The BCU 10 is an active system, and the BCU 1011 is a standby system. The active BCU 10 controls the entire apparatus and other boards, and the standby BCU 11 is in a standby state without performing a control operation. When a failure occurs in the active BCU 10, the standby BCU 11 takes over control of the communication device. The communication device may have only one BCU.

  The BCUs 10 and 11 have the same configuration, and the configuration of the BCU 10 will be described below. The BCU 10 includes a processor 101 and a memory 102 that is a main storage device. The processor 101 implements a predetermined function by executing a program stored in the memory 102. The memory 102 stores a program executed by the processor 101 and data necessary for executing the program.

  The program is executed by the processor 101 to perform a predetermined process. Therefore, the description with the program as the subject in the present embodiment may be an explanation with the processor 101 as the subject. Or the process which a program performs is a process which BCU and the communication apparatus with which the program operate | moves perform.

  The memory 102 stores a program for performing a control operation by the BCU 10 and information used by them. FIG. 1 shows only programs and information related to the operation of this embodiment, and the memory 102 may store other programs and information not shown. In the present embodiment, information used by the BCU 10 is represented by a table, but the information may be represented by a data structure different from that of the table.

  For convenience of explanation, data (including programs and tables) used by the processor 101 is shown in the memory 102, but typically the data is loaded into the memory 102 from a secondary storage device. The secondary storage device is a storage device including a non-volatile non-transitory storage medium that stores programs and data necessary for realizing a predetermined function.

  The memory 102 stores a device state management program 1020, a failure detection program 1021, a failure board isolation program 1022, and a failure recovery program 1023. Further, the memory 102 stores information used by the programs 1020 to 1023.

  The memory 102 stores an SFU connection relation table 1024, a PPU connection relation table 1025, a PPU redundancy configuration table 1026, and an SFU state management table 1027. The memory 102 further stores a PPU state management table 1028, a failure determination interface table 1029, a failure information management table 10210, an SFU interface failure detection counter table 10211, and a PPU interface failure detection counter table 10212. Details of these tables and programs will be described later.

  The BCU 10 and all the SFUs 20 to 23 and all the PPUs 30 to 33 can communicate with each other via the control network 70. The BCU 10 can receive an interrupt from the board that has detected the interface failure via the control network 70. The BCU 10 can check the states of the SFUs 20 to 23 and the PPUs 30 to 33 via the control network 70.

  In the present embodiment, the BCU 10 can periodically check whether there is a failure in the SFUs 20 to 23 and the PPUs 30 to 33. The BCU 10 can check whether or not there is a failure in the SFUs 20 to 23 and the PPUs 30 to 33 in the failure recovery process after the interruption is raised.

  The BCU 11, all the SFUs 20 to 23, and all the PPUs 30 to 33 can communicate with each other via the control network 71. The BCU 11 performs the same operation as the BCU 10 after changing to the operation state.

  Each of the SFUs 20 to 23 includes a crossbar switch (CSW) 200 that is an LSI that performs data transfer between PPUs, and an OBP / CLK unit 201 that supplies a power source and a clock for operating the CSW 200.

  Each of the PPUs 30 to 33 includes a search transfer unit 300 and an OBP / CLK unit 301. The search and transfer unit 300 is an LSI that performs packet destination search, filtering to discard illegal packets, and data transfer. The OBP / CLK unit 301 supplies power and a clock for operating the search and transfer unit 300.

  All the SFUs 20 to 23 and all the PPUs 30 to 33 are interconnected by inter-board interfaces 800 to 833. Each of the inter-board interfaces 800 to 833 transfers packets in both directions. That is, the inter-board interfaces 800 to 803, 810 to 813, 820 to 823, and 830 to 833 each transfer a packet from the SFU to the PPU, and further transfer a packet from the PPU to the SFU.

  A board (SFU or PPU) that transmits data transmits the data to the inter-board interface after encoding for detecting an error in the data. The board (PPU or SFU) that has received the data decodes the code, performs error detection, and simultaneously restores the data.

  If the board receiving the data detects an error by decoding, there are two possible causes of the error. One is that the failure of the board that sent the data may have caused a data error when sending the data. Another possibility is that a failure of the board that received the data caused a data error when receiving the data.

  FIG. 2 pays attention to one interface between the SFU and the PPU, and shows the relationship between the board in which the failure has occurred and the board in which the failure has been detected. The first row 221 in FIG. 2 corresponds to the case where a failure occurs in the SFU, and the second row 222 corresponds to the case where a failure occurs in the PPU. Each first row 223 corresponds to a case where a failure is detected by SFU, and second row 224 corresponds to a case where a failure is detected by PPU. The BCU 10 treats an SFU or PPU equally as a failure of the interface even if an error is detected in the data received from the inter-board interface.

  FIG. 2 focuses on one board-to-board interface and shows one SFU and one PPU. However, actually, as shown in FIG. 1, a plurality of SFUs 20 to 23 and a plurality of PPUs 30 to 33 are connected by a mesh. It is necessary to manage the connection relationship between the SFUs 20 to 23 and the PPUs 30 to 33 and the interface that connects them.

  The SFU connection relation table 1024 and the PPU connection relation table 1025 manage these pieces of information. 3 and 4 show configuration examples of the SFU connection relation table 1024 and the PPU connection relation table 1025, respectively. The device state management program 1020 updates and manages these.

  The SFU connection relation table 1024 indicates the facing parts of the SFUs 20 to 23 that have detected a failure. The PPU connection relation table 1025 indicates the facing parts of the PPUs 30 to 33 that have detected a failure.

  In FIG. 3, the SFU connection relation table 1024 specifies a failure detection site by the SFU number and the port number. The SFU number uniquely identifies the SFU within the communication device, and the port number uniquely identifies the port within the SFU.

  The opposite part of each failure detection part is specified by the PPU number and the port number. The PPU number uniquely identifies the PPU within the communication device, and the port number uniquely identifies the port within the PPU. The interface between boards connecting the two parts is specified by the interface number. The interface number uniquely identifies the inter-board interface in the communication device.

  In FIG. 4, the PPU connection relation table 1025 specifies a failure detection part by the PPU number and the port number. The opposite part of each failure detection part is specified by the SFU number and the port number. The interface between boards connecting the two parts is specified by the interface number. The BCU 10 can specify an interface to be treated as a failure by referring to the tables 1024 and 1025 when a failure is detected on either side of the interface.

  When the SFU detects an interface failure, the BCU 10 can specify the opposite PPU of the interface with reference to the SFU connection relation table 1024. Similarly, when the PPU detects an interface failure, the BCU 10 can specify the opposite SFU of the interface with reference to the PPU connection relation table 1025. The BCU 10 may have only one of the tables 1024 and 1025. The counter board of SFU and PPU can be specified only by any table.

  When the BCU 10 detects a failure in the interface between the boards, the BCU 10 determines that one of the boards has failed. The BCU 10 attempts to recover from the failure by performing failure recovery processing for the board determined to be faulty.

  One method of board failure recovery processing is, for example, reinitialization after closing the board. In the failure recovery process, the BCU 10 may notify the operator of the failure in the board failure recovery process. For example, the BCU 10 displays a failure message on a display device (not shown), turns on a lamp of a predetermined color on the device, or outputs a MIB (Management Information Base) trap. Combinations of these can also be used.

  The BCU 10 automatically performs the failure recovery process when an interface failure between boards is detected. The BCU 10 automatically determines which board has a failure. When the BCU 10 detects a failure at the interface between the boards, the connection relationship between the boards, the redundancy of each board, and the operating state of each board are held in advance in order to determine which board has failed. .

  The device state management program 1020 manages the board configuration and board state in the communication device. The device state management program 1020 is arranged in accordance with the board configuration and board state in the communication device, and includes an SFU connection relationship table 1024, a PPU connection relationship table 1025, a PPU redundant configuration table 1026, an SFU state management table 1027, a PPU state management table 1028, The failure determination interface table 1029 is created and updated. The device state management program 1020 prepares these tables 1024 to 1029 in advance before a failure occurs at an interface between boards.

  As described above, the connection relationship between the boards is held in the SFU connection relationship table 1024 and the PPU connection relationship table 1025. Information on the redundant configuration of the PPUs 30 to 33 is held in the PPU redundant configuration table 1026.

  FIG. 5 shows a configuration example of the PPU redundancy configuration table 1026 indicating the redundancy configuration of the PPU. The PPU redundancy configuration table 1026 indicates information indicating whether each of the PPUs 30 to 33 identified by the PPU number configures redundancy with another PPU that configures redundancy and another PPU.

  As an example of a method for realizing redundancy of PPU, a set of redundancy is formed by a plurality of PPUs, and line redundancy such as link aggregation is set between ports under each PPU in the set. Even if any of a plurality of PPUs constituting redundancy is blocked, user communication is continued by the line redundancy function. The BCU 10 can determine whether the PPU is redundant by referring to the PPU redundancy configuration table 1026.

As an example of a method for determining whether or not there is redundancy in SFU, as shown in Equation 1 below, if the total number of SFUs in the operation state SFU and the standby state is larger than the necessary number for satisfying the performance required for communication within the communication device It is determined that there is redundancy.
(Formula 1)
SFU redundancy = (number of operating SFUs + number of standby SFUs> required number)

  For example, when the number of mountable sheets is four and the required number of sheets is three, the BCU 10 determines that there is redundancy when the number of mounted sheets is 4, and determines that there is no redundancy when the number of mounted sheets is three or less. The required number of sheets is preset in the BCU 10. When the number of mounted sheets is larger than the required number, the required number is satisfied even when the BCU 10 determines any SFU as a failure and performs failure recovery processing.

  Information on the operation state of each board of the SFUs 20 to 23 and the PPUs 30 to 33 is held in the SFU state management table 1027 and the PPU state management table 1028. 6 and 7 show configuration examples of the SFU state management table 1027 and the PPU state management table 1028, respectively.

  The operating state is a state in which the board is operating, and an interface between the boards is also used. In the standby state, the board is not used for operation, and is waiting for power saving, for example. The board-to-board interface of the board is in a usable state so that the board can be changed to a usable state immediately when a board in another operational state that forms redundancy with the board fails. Therefore, the board may detect a failure at the interface.

  The blocked state is a state in which no communication operation is performed, such as non-installation (including power-off), failure state, and recovery processing. In the interface between the board in this state and the opposing board, both the board and the opposing board should be masked so as to be ignored even if a new failure is detected or not newly detected. The state shown here is an example, and other states can be provided.

  As will be described later, when the BCU 10 detects a failure in one interface between the SFUs 20 to 23 and the PPUs 30 to 33, the BCU 10 also investigates whether there is a failure in the interface between the other SFUs and the PPUs and identifies the failed board. To do. The interface to be determined as a failed board is not all interfaces, but excludes the interface of a board in a blocked state.

  The failure determination interface table 1029 holds information on interfaces used and excluded interfaces in failure determination. FIG. 8 shows a configuration example of the failure determination interface table 1029.

  The failure determination interface table 1029 indicates whether an interface between each SFU and PPU is used or excluded in the matrix of SFUs 20 to 23 and PPUs 30 to 33. When a board is excluded, all of the board's interfaces are excluded. The device state management program 1020 creates a failure determination interface table 1029 from the SFU state management table 1027 and the PPU state management table 1028. When a board is in a closed state, the board is excluded.

  The above tables 1024 to 1029 are prepared in advance before interface failure detection. On the other hand, the failure information management table 10210, the SFU interface failure detection counter table 10211, and the PPU interface failure detection counter table 10212 are created and updated after the interface failure is detected.

  FIG. 9 shows a configuration example of the failure information management table 10210. The failure information management table 10210 holds information on the presence / absence of failures in all interfaces. In FIG. 9, the failure information management table 10210 indicates whether a failure is detected in the interface between each SFU and PPU in the matrix of SFUs 20 to 23 and PPUs 30 to 33. It should be noted that no fault is detected in the blocked board.

  As will be described later, when a board detects a failure in one interface between the SFU and the PPU, the BCU 10 detects the failure of the interface by an interruption from the detected board or a periodic check of each board from the BCU 10. Is detected. Based on this, the BCU 10 investigates the presence or absence of an interface failure between other SFUs and PPUs. Information obtained by the investigation is stored in the failure information management table 10210.

  FIG. 10 shows a configuration example of the SFU interface failure detection counter table 10211. The SFU interface failure detection counter table 10211 indicates the number of failure detection interfaces of each SFU. Specifically, for each SFU, the interface between all the PPUs 30 to 33 indicates the number of interfaces in which the failure determination interface table 1029 indicates “used” and the failure information management table 10210 indicates “failure detected”. .

  FIG. 11 shows a configuration example of the PPU interface failure detection counter table 10212. The PPU interface failure detection counter table 10212 indicates the number of failure detection interfaces of each PPU. Specifically, for each PPU, the interface between all SFUs 20 to 23 indicates the number of interfaces in which the failure determination interface table 1029 indicates the “used” state and the failure information management table 10210 indicates “failure detection”. .

  Using the table, the program in the BCU 10 shown in FIG. 1 detects an interface failure between boards, determines which board in the interface is faulty, and performs failure recovery processing.

  The failure detection program 1021 detects interface failure between boards. When one of the interfaces (SFU or PPU) detects a failure in the interface, it stores information indicating the occurrence of the failure in a register. The board may further notify the failure detection program 1021 of the occurrence of an interface failure by an interrupt.

  The failure detection program 1021 can detect the occurrence of a failure by an interrupt from a board that has detected a failure or by periodically referring to the registers of the SFUs 20 to 23 and the PPUs 30 to 33 (periodic check).

  The fault board isolation program 1022 is called after the fault detection program 1021 detects an interface fault between boards. The fault board isolation program 1022 investigates the presence / absence of an interface failure between other SFUs and PPUs, and stores information on the presence / absence of failure in all interfaces in the failure information management table 10210.

  The failure board isolation program 1022 is in the “use” state in the failure determination interface table 1029 and is in the “failure detection” state in the table 10210 for each SFU, and is an interface between all the PPUs 30 to 33. The number of interfaces is stored in the SFU interface failure detection counter table 10211.

  The fault board isolation program 1022 is an interface between all the SFUs 20 to 23 for each PPU, is in the “use” state in the fault determination interface table 1029, and is in the “failure detection” state in the fault information management table 10210. The number of configured interfaces is stored in the PPU interface failure detection counter table 10212.

  The fault board isolation program 1022 uses the fault information management table 10210, the SFU interface fault detection counter table 10211, and the PPU interface fault detection counter table 10212 to determine that one board of the fault detected interface is faulty.

  The failure recovery program 1023 is called after the failed board isolation program 1022 identifies the failed board. The failure recovery program 1023 reinitializes the identified failure board and / or displays a message indicating information about the failure and / or failure recovery.

Hereinafter, the operation of the BCU 10 will be specifically described. The faulty board isolation program 1022 determines a faulty board in the interface where the fault is detected. This determination method follows the following determination criteria.
First criterion: A board having a high possibility of failure is determined as a failure.
Second criterion: Suppressing the impact on communication.

  FIG. 12 is a flowchart showing the overall flow of the operation of the BCU 10. When the failure detection program 1021 detects a failure at the inter-board interface (61), the BCU 10 executes Step 6101. Specifically, the fault board isolation program 1022 identifies a fault board according to a flowchart described later with reference to FIG. 13, and the fault recovery program 1023 performs fault recovery processing for the board.

  Thereafter, the failure detection program 1021 investigates whether there is a board-to-board interface in which a failure has occurred (6102). The failure detection program 1021 refers to the registers of the SFUs 20 to 23 and the PPUs 30 to 33 to determine whether there is a board-to-board interface in which a failure has occurred.

  If a failure has occurred in any interface (6102: Present), the BCU 10 returns to Step 6101. The BCU 10 repeats steps 6101 and 6102 until there is no inter-board interface failure. When there is no inter-board interface failure (6102: none), the BCU 10 ends the inter-board interface failure recovery processing.

  In the above flow, one board to be determined as a failure is determined for each loop, and failure recovery processing is performed. When one loop recovers all interface failures, the flow ends with one loop.

  When a plurality of boards are determined to be faulty, it cannot be assumed that failures of independent factors occur simultaneously on the plurality of boards. For example, it is assumed to be caused by a failure factor that commonly affects a plurality of boards, such as an external power supply abnormality, an apparatus temperature abnormality, and external noise. Since it is assumed that the failure factor is other than each board determined to be a failure, the BCU 10 may notify that the failure is to be recovered by the operator.

  FIG. 13 is a flowchart showing details of step 6101. As described with reference to FIG. 12, the failure detection program 1021 detects a failure at the inter-board interface (61). The failure detection program 1021 detects a failure in one interface identified by the interface number by an interrupt from a board that detects a failure in one interface between the SFU and the PPU, or by a periodic check of each board.

  The failure board isolation program 1022 checks whether or not a failure is detected in all the SFUs 20 to 23 and the PPUs 30 to 33, and holds the result in the memory 102 (6001). Each board includes a detector that detects faults in the board. The detector can detect a failure that causes an interface failure between boards. In one example, the detector detects an on-board power supply failure in the board and a clock failure in the board.

  FIG. 14 shows a configuration example of the OBP / CLK unit 201 which is a detector for detecting a failure in the board. The OBP / CLK unit 201 is mounted on each of the SFUs 20 to 23 and the PPUs 30 to 33. The OBP / CLK unit 201 supplies power and a clock for operating the CSW 200 / search transfer unit 300.

  The OBP / CLK unit 201 includes a clock 2010, a clock monitor 2011, an on-board power supply (OBP1) 2012, an on-board power supply (OBP2) 2013, and a voltage monitor 2014. The clock monitor 2011 detects an abnormality in the clock 2010. An onboard power supply (OBP1) 2012 supplies power to the CSW 200 / search transfer unit 300. An onboard power supply (OBP2) 2013 supplies power to the clock 2010. The voltage monitor 2014 detects a voltage abnormality in the OBP1 2012 and the OBP2 2013.

  The clock monitor 2011 and the voltage monitor 2014 each detect a failure in the board. When the clock monitor 2011 or the voltage monitor 2014 detects a failure, the failure detection program 1021 or the failure board isolation program 1022 can receive an interrupt from the clock monitor 2011 or the voltage monitor 2014 and detect the failure of the board.

  Further, the failure detection program 1021 or the failure board isolation program 1022 refers to a register in the board and checks whether or not a failure is detected by the clock monitor 2011 and the voltage monitor 2014, thereby knowing whether or not there is a failure in the board. You can also. The detection of the in-board failure may or may not be included in the detection of the interface failure.

  Returning to FIG. 13, the failure detection program 1021 determines whether any of the boards that are not blocked in all the SFUs 20 to 23 and all the PPUs 30 to 33 have detected a failure (6001). When any board detects a failure in the board instead of being in the blocked state (6001: “failure in the board is detected”), the failure board isolation program 1022 sets the board in which the failure is detected as a failure. Determine (6005). The board does not necessarily match the interface board that triggered the start of this flow.

  The failure recovery program 1023 performs failure recovery processing for the board (6010). In this example, the failure recovery program 1023 changes the state of the board to a closed state. The failure recovery program 1023 updates the relevant information of the board in the SFU state management table 1027 and the PPU state management table 1028.

  The failure recovery program 1023 further displays that the board has been determined to have a failure. Note that the faulty board isolation program 1022 may determine that all boards in which a fault has been detected are faulty. The failure recovery program 1023 may initialize a board determined to have a failure in failure recovery.

  When none of the boards detects a failure (6001: “no failure within the board has been detected”), the failure board isolation program 1022 determines whether a failure has been detected at a plurality of inter-board interfaces on each board. Is checked (6002).

  FIG. 15 is a flowchart illustrating an example of an interface failure check (6002). The failure board isolation program 1022 investigates whether a failure has been detected for the interfaces between all the SFUs 20 to 23 and all the PPUs 30 to 33, and stores the result in the failure information management table 10210 (60021). The failure board isolation program 1022 can investigate whether an interface failure has occurred, for example, by referring to the registers of the SFUs 20 to 23 and the PPUs 30 to 33.

  In the interface between each SFU and all the PPUs 30 to 33, the failure board isolation program 1022 is the number of interfaces that are “used” in the failure determination interface table 1029 and “failure detection” in the failure information management table 10210. To decide. The fault board isolation program 1022 stores the number determined for each SFU in the SFU interface fault detection counter table 10211 (60022).

  In the interface between each PPU and all the SFUs 20 to 23, the failure board isolation program 1022 is the number of interfaces that are “used” in the failure determination interface table 1029 and “failure detection” in the failure information management table 10210. To decide. The fault board isolation program 1022 stores the number determined for each PPU in the PPU interface fault detection counter table 10212.

  The fault board isolation program 1022 obtains the maximum number of fault detection interfaces stored in the SFU interface fault detection counter table 10211 and the PPU interface fault detection counter table 10212 (60024).

  The fault board isolation program 1022 proceeds to a different step depending on the maximum number of fault detection interfaces (60025). If the maximum number of failure detection interfaces is 0 (60025: 0), the failure board isolation program 1022 determines that no interface failure has been detected (60026), and proceeds to step 6010 in the flowchart of FIG.

  The failure board isolation program 1022 starts the flow of FIG. 13 triggered by the detection of an interface failure. When the flow of FIG. 13 is executed for the first time, there is always an interface failure. However, the BCU 10 repeats steps 6101 and 6102 in the flowchart of FIG. 12 until it finishes processing all interface failures. In the last loop, the maximum number of failure detection interfaces is zero.

  When the maximum value of the number of failure detection interfaces is 2 or more (60025: 2 or more), the failure board isolation program 1022 selects a board that indicates the maximum value of the number of failure detection interfaces, and between the board and the plurality of boards. It is determined that a failure has been detected at the interface (60027). The faulty board isolation program 1022 determines that the board in which a fault has been detected in a plurality of interfaces is faulty in the flowchart of FIG. 13 (6006).

  When a failure is detected at a plurality of inter-board interfaces in one board, there is a high possibility that the board is in failure. Therefore, this determination method can appropriately identify the failed board.

  As shown in the example of the failure information management table 10210 in FIG. 9, when there are a plurality of boards having interface failures with a plurality of boards, even if one of them is determined to be a failure, Interface failure may remain. The BCU 10 determines, in order, that a board having an interface failure with a plurality of boards is a failure according to the flowchart of FIG.

  When the maximum value of the number of failure detection interfaces is 1 (60025: 1), the failure board isolation program 1022 determines that a failure is detected only at one inter-board interface in each board where an interface failure is detected. (60022). The fault board isolation program 1022 proceeds to the redundancy status check (6003) in the flowchart of FIG.

  FIG. 16 is a flowchart illustrating an example of the redundancy status check (6003). Whether or not SFU is redundant is determined using Equation 1 (60031). The fault board isolation program 1022 obtains the number of operation status SFUs and standby status SFUs from the SFU status management table 1027.

  The fault board isolation program 1022 selects one interface in which a fault has been detected, and obtains the presence / absence of redundancy of the PPU connected to the interface from the PPU redundancy configuration table 1026 (60032).

  The fault board isolation program 1022 proceeds to different steps depending on whether or not SFU is redundant and PPU is redundant (6003, 60034, 60035).

  When the SFU is not made redundant and the PPU is made redundant (6003: None, 60034: Present), or when the SFU is made redundant and the PPU is not made redundant (6003: Present, 60035: None), the faulty board isolation program 1022 determines that only one board is redundant (60036).

  The faulty board isolation program 1022 proceeds to step 6007 in the flowchart of FIG. 13 and determines that the redundant board is faulty. By determining a redundant board as a failure and performing a failure recovery process, the influence of the recovery process on communication can be suppressed.

  When SFU and PPU are made redundant (60033: Yes, 60035: Yes), or when SFU and PPU are not made redundant (60033: No, 60034: No), fault board isolation program 1022 is: It is determined that both the boards on both sides, the boards on both sides are not redundant, or the boards on both sides are redundant (60037). The fault board isolation program 1022 proceeds to the operation / standby state check (6004) in the flowchart of FIG.

  FIG. 17 is a flowchart illustrating an example of the operation / standby state check (6004). The fault board isolation program 1022 obtains the operation / standby state of the SFU connected to the interface that has detected the failure from the SFU state management table 1027 (60041). In addition, the operation / standby state of the PPU connected to the interface that has detected the failure is obtained from the PPU state management table 1028 (60042).

  The fault board isolation program 1022 proceeds to different steps depending on the operation / standby state of the SFU and the operation / standby state of the PPU (60043, 60044, 60045).

  When SFU is in standby state and PPU is in operation state (60043: Standby state, 60044: Operation state), or when SFU is in operation state and PPU is in standby state (60043: Operation state, 60045: Standby state), failure The board cutting program 1022 determines that only one board is in a standby state (60046). The faulty board isolation program 1022 determines that the standby board is faulty in the flowchart of FIG. 13 (6008). By determining the standby board as a failure, it is possible to suppress the influence of failure recovery on the communication.

  When the SFU and PPU are in a standby state (60043: standby state, 60044: standby state), or when the SFU and PPU are in an operational state (60043: operational state, 60045: operational state), the fault board isolation program 1022 is It is determined that the boards on both sides are in the standby state or the boards on both sides are in the operating state (60047). The fault board isolation program 1022 proceeds to step 6009 in the flowchart of FIG.

  In step 6009, the faulty board isolation program 1022 determines that the lower board in the vertical relation is faulty. The vertical relationship is determined in advance. For example, in the case of an interface failure between the SFU and the PPU, the PPU is determined to be lower, and the failure board isolation program 1022 determines that the PPU has failed.

  When paying attention to a set of SFU and PPU, the determination of the faulty board sequentially executes the determinations of step 6001 to step 6004 in the flowchart of FIG. That is, the BCU 10 performs failure board determination in a set of SFUs and PPUs in the order of failure detection by an in-board failure detector, the number of failed interfaces, a redundant configuration, a standby / operation state, and an SFU / PPU type.

  In the following, an example is shown in which the determination result by the fault board isolation program 1022 becomes the determination result indicated by each of steps 6006, 6007, and 6008 in the flowchart of FIG.

  FIGS. 18 and 19 show an example in which the SFU is determined to be a failure in step 6006 (determined that a board having detected a failure in a plurality of interfaces is a failure) in the flowchart of FIG. 13. FIG. 20 shows an example in which a PPU is determined to be faulty. In these examples, it is assumed that no fault in the board is detected (6001: no fault in the board has been detected), and the fault board isolation program 1022 proceeds to step 6002 (interface fault check).

  FIG. 19 shows a failure information management table 10210 created in step 60021 in the flowchart of FIG. 15 in the example of FIG. In FIG. 18, a failure is detected at the interface between the SFU 21 and the plurality of PPUs 30 and 32. In this case, the faulty board isolation program 1022 proceeds to step 60027 (detects faults with a plurality of inter-board interfaces) in the flowchart of FIG. 15, and determines that the SFU 21 is faulty in step 6006 of the flowchart of FIG.

  FIG. 20 shows another example of the failure information management table 10210 created in step 60021 in the flowchart of FIG. In FIG. 20, a failure is detected at the interface between the PPU 32 and the plurality of SFUs, and the fault board isolation program 1022 proceeds to step 60027 (detects a failure at the plurality of inter-board interfaces) in FIG. In step 6006, PPU2 is determined to be faulty.

  Next, FIGS. 21 and 22 show an example of step 6007 in FIG. 13 (determining the redundant board as a failure). Also in these examples, in these examples, an in-board failure is not detected (6001: an in-board failure is not detected), and the failed board isolation program 1022 proceeds to step 6002 (interface failure check). To do.

  In the examples of FIGS. 21 and 22, a failure is detected only at the interface between the SFU 21 and the PPU 32. In step 6002 (interface failure check) in FIG. 13, the failed board isolation program 1022 proceeds to step 6003 (redundancy state check) from the branch of the failure detection only at one board interface.

  In the example of FIG. 21, since the SFU 21 is made redundant and the PPU 32 is not made redundant (in FIG. 16, 60033: present, 60035: absent), the fault board isolation program 1022 is executed in step 60036 (one board In step 6007 of FIG. 13, the redundant SFU 21 is determined as a failure.

  In the example of FIG. 22, since the SFU 21 is not made redundant and the PPU 32 is made redundant (in FIG. 16, 60033: None, 60034: Presence), the failure board isolation program 1022 executes step 60036 (one board In step 6007 in FIG. 13, the redundant PPU 32 is determined as a failure.

  Next, FIG. 23 and FIG. 24 show an example of step 6008 in FIG. 13 (determining that the board in the standby state is faulty). In the examples of FIGS. 21 and 22, a failure is detected at the interface between the SFU 21 and the PPU 32. In step 6002 (interface failure check) in FIG. 13, the failed board isolation program 1022 proceeds from the failure detection branch only to one board interface to step 6003 (redundancy state check).

  The fault board isolation program 1022 determines in step 6003 (redundancy state check) in FIG. 13 that both the SFU 21 and the PPU 32 are redundant, and proceeds to step 6004 (operation / standby state check).

  In the example of FIG. 23, since the SFU 21 is in a standby state and the PPU 32 is in an operational state (in FIG. 17, 60043: standby state, 60044: operational state), the fault board isolation program 1022 is executed in step 60046 of FIG. In step 6008 of FIG. 13, the standby SFU 21 is determined as a failure.

  In the example of FIG. 24, since the SFU 1 is in the operation state and the PPU 32 is in the standby state (in FIG. 17, 60043: operation state, 60045: standby state), the fault board isolation program 1022 is executed in step 60046 of FIG. In step 6008 of FIG. 13, the standby PPU 32 is determined to be faulty.

  When the failure recovery program 1023 detects a failure at the interface between the boards, the failure recovery program 1023 may display a failure message on the management terminal of the communication device, or store the failure message in the device as a log message. .

  If a different message is displayed for each determination result of steps 6005, 6006, 6007, 6008, and 6009 in the flowchart of FIG. 13, the operator can know the determination result from the message. The message may indicate the board determined to be faulty and the reason for the determination.

  The reason for determination is, for example, that an internal fault is detected in the board (6005), a fault between a plurality of interfaces is detected in the board (6006), the board has a redundant configuration, and the opposing board Does not have a redundant configuration (6007).

  In the flowchart of FIG. 12, the failure recovery program 1023 displays one failure message every time it makes a loop. When a plurality of failure messages are displayed, the operator knows that the loop shown in FIG. 12 has been executed a plurality of times. In this case, since the failure factor is assumed to be other than each board determined to be a failure, the operator can determine that the failure should be restored by manual intervention.

  As described above, according to the present embodiment, when a failure is detected between boards of a communication device, it is possible to reduce the possibility that an incorrect board is replaced. In addition, the influence of the replacement of the board on the communication can be reduced.

  In addition, this invention is not limited to the said example, Various modifications are included. The present invention is not limited to the functional configuration of the board in the communication device. In the above example, the failure board is determined in the interface failure between the SFU of the lower board and the PPU of the upper board. The present invention is not limited to this example, and can be applied to an interface failure between other types of boards. In the present invention, when a failure is detected at an interface between boards in different groups, regardless of how the function is mounted on each board, it is possible to determine which side of the interface is caused by the failure of the board. .

  In a configuration in which a BCU function and a function for transferring packets between NIFs are accommodated in one board, if the board is determined to be faulty, the BCU function is connected to another board that is redundant with the board. It is necessary to take over the management information in the device realized as Therefore, when a failure is detected in the interface, it may be determined that the other board of the interface is always out of order.

  The above example of failure board determination in the case of an interface failure includes a plurality of steps (6001 to 6009 in the flowchart of FIG. 13), but some of them may be omitted. In the above example, the BCU 10 as the controller determines the failed board, but a board different from this may make the determination.

  The above example has been described in detail for easy understanding of the present invention, and is not necessarily limited to the one having all the configurations described. In addition, a part of the configuration of an example can be replaced with the configuration of another example, and the configuration of another example can be added to the configuration of an example. In addition, it is possible to add, delete, and replace other configurations for a part of the configuration of each example.

  Each of the above-described configurations, functions, processing units, and the like may be realized by hardware by designing a part or all of them, for example, with an integrated circuit. Each of the above-described configurations, functions, and the like may be realized by software by interpreting and executing a program that realizes each function by the processor. Information such as programs, tables, and files for realizing each function can be stored in a memory, a hard disk, a recording device such as an SSD (Solid State Drive), or a non-temporary recording medium such as an IC card or an SD card. .

10, 11 BCU, 101 processor, 102 memory, 20-23 SFU, 30-33 PPU, 40-47 NIF, 200 CSW, 201 SFU OBP / CLK unit, 300 search transfer unit, 800-803, 810-813, 820-823, 830-833 inter-board interface, 2010 timing supply clock, 2011 clock monitor, on-board power supply supplying power to 2012 CSW / search transfer unit, on-board power supply supplying power to clock in 2013 SFU, 2014 SFU Internal voltage monitor

Claims (12)

First and second groups of boards for transferring received data;
A communication device including a controller,
Each of the first group of boards is communicatively connected to the second group of boards,
The controller is
Detecting a first interface failure between the first board in the first group and the second board in the second group;
Identifying the number of interfaces in which a failure is detected between the first board and the second group of boards;
Identify the number of interfaces in which a failure is detected between the second board and the first group of boards,
Based on the failure detection result on the first board and the failure detection result on the second board, it is determined whether the cause of the first interface failure is a failure of the first board, and the determination result is The communication device that outputs. The communication device according to claim 1,
When the number of interfaces in which failure is detected in the first board is greater than 1 and the number of interfaces in which failure is detected in the second board is 1, the cause of the first interface failure is failure of the first board A communication device that determines that The communication device according to claim 1 or 2,
Each of the first and second groups of boards includes a detector that detects an in-board fault causing an interface fault;
The controller, when an in-board failure is detected in one of the first board and the second board, without specifying the number of fault interfaces of the first board and the second board, The communication device that determines that the cause of the first interface failure is a failure of the one board. The communication device according to any one of claims 1 to 3,
When the number of interfaces in which a failure is detected in the first board is 1 and the number of interfaces in which a failure is detected in the second board is 1, the controller is configured so that each of the first board and the second board The presence or absence of redundancy,
When one of the first board and the second board is made redundant and the other is not made redundant, the controller causes the failure of the redundant board to cause the first interface failure. A communication device that determines that there is a communication device. The communication device according to claim 4,
When both the first and second boards are made redundant or not redundant, the controller determines the state of the first and second boards;
When one of the first and second boards is in a standby state and the other is in an operating state, the controller determines that the cause of the first interface failure is a failure of one board in the standby state A communication device. The communication device according to claim 5,
A communication in which, when both the first and second boards are in a standby state or an operating state, the controller determines that the cause of the first interface failure is a failure of a board in a preset group; apparatus.
A control method for a communication device, including first and second group boards for transferring received data, wherein each of the first group boards is communicably connected to all the second group boards Because
Detecting a first interface failure between the first board in the first group and the second board in the second group;
Identifying the number of interfaces in which a failure is detected between the first board and the second group of boards;
Identify the number of interfaces in which a failure is detected between the second board and the first group of boards,
Based on the failure detection result on the first board and the failure detection result on the second board, it is determined whether the cause of the first interface failure is a failure of the first board, and the determination result is A communication device control method for outputting. A communication device control method according to claim 7,
When the number of interfaces in which failure is detected in the first board is greater than 1 and the number of interfaces in which failure is detected in the second board is 1, the cause of the first interface failure is failure of the first board A communication device control method for determining that A method for controlling a communication device according to claim 7 or 8,
Each of the first and second groups of boards includes a detector that detects an in-board fault causing an interface fault;
When a failure in the board is detected in one of the first board and the second board, without specifying the number of failed interface of said first board and said second board, said first interface A control method for a communication apparatus, wherein the cause of the failure is determined to be a failure of the one board. A communication device control method according to any one of claims 7 to 9,
Whether the first board and the second board have redundancy when the number of interfaces detected in the first board is 1 and the number of interfaces detected in the second board is 1 Determine
When one of the first board and the second board is made redundant and the other is not made redundant, it is determined that the cause of the first interface failure is a failure of the one redundant board And control method of communication apparatus. A communication device control method according to claim 10, comprising:
If both the first and second boards are redundant or not redundant, determine the state of the first and second boards;
A communication device that determines that the cause of the first interface failure is a failure of one board in the standby state when one of the first and second boards is in a standby state and the other is in an operating state Control method. A communication device control method according to claim 10, comprising:
If both the first and second board is in the standby state or the operation state before Symbol cause the first interface failure, determines that failure of a group that has been set in advance board, control of the communication device Method.

Images