Misconnection of EFI Board on OSN6800 Leads To Faulty Subrac

Problem Description

During commissioning of a station OSN6800, a laptop computer cable is connected to the NM_ETH1 of the main subrack 0 of one of the Huawei OSN 6800. The NE has five subracks, where 0, 1, and 2 are in the same subrack, 3 , 4, 5 In another cabinet, log in with the navigator and execute the command ":cfg-get-physhelf". You can see only 0 subracks and no other subracks.

Process

Initially check the connection of the network cable. The ETH2 of the 0 subrack is serially connected to ETH1 of the 1 subrack, the ETH2 of the 1 subrack is connected to the ETH1 of the 2 subracks, and so on. All of them are correct. Suspected may be a network cable problem, temporarily replace a few network cable, the situation is still there. Execute ":alm-get-curdata-ext:0,0,0" to see the report SUBRACK_LOOP, pull out all the rest of the network cable on AUX, leaving only one to access the computer, the alarm disappears, but through ":cfg-get-physhelf" However, you can view subrack 1, unscrew the bezel screws on the EFI board, and remove the bezel, and see that ETH3 of subrack 0 is connected to ETH3 of EFI on subrack 1. This is a construction error. The network cable should be an alarm. For string wiring, ALMO2 of subrack 0 should be connected to ALMO1 of subrack 1. After adjustment, normal viewing is performed.

Root cause

1. The network element uses the master-slave subrack tree connection mode. The 0-subrack is the main subrack and the rest is the subrack. The NM_ETH port of the 0 subrack is connected to the network management switch, and the ETH2 is cascaded to the ETH1 of the subrack 1. By analogy in turn, it is suspected that the level networking between subrack 0 and subrack 1 is not good, resulting in no search for other subracks.

2. Suppose that there is more than one network cable cascaded somewhere between the subracks, causing loopbacks that cause abnormal communication between the subracks so that no other subracks can be searched.