Chinese
English
Problem Description
Scenario 1: Veneer offline:
The line board SLQ4 in slot 5 of the OSN3500 in the current network suddenly goes offline, and when you open the network element panel on the T2000 network administrator, it shows that the problematic veneer is grayed out, but there is no alarm reported, and at the same time, you can't query the physical veneer in slot 5 by using the command line :cfg-get-phybd; you can't query the physical veneer in slot 5 anymore, and you confirm with the customer about the business impact situation, and you find that the business is normal.
Scenario 2: COMMUN_FAIL alarm:
A newly installed OSN3500 device, the single boards in slots 5, 7, and 8 report COMMU_FAIL alarms at the same time, and two COMMUN_FAIL alarms are reported on each single board at the same time, and by checking the alarm parameter, it is found that the alarm parameter is indicated as the single board's 485_A serial port bus and 485_B serial port bus. The alarms are reported at the same time, it is possible that both buses are bad.
The line board SLQ4 in slot 5 of the OSN3500 in the current network suddenly goes offline, and when you open the network element panel on the T2000 network administrator, it shows that the problematic veneer is grayed out, but there is no alarm reported, and at the same time, you can't query the physical veneer in slot 5 by using the command line :cfg-get-phybd; you can't query the physical veneer in slot 5 anymore, and you confirm with the customer about the business impact situation, and you find that the business is normal.
Scenario 2: COMMUN_FAIL alarm:
A newly installed OSN3500 device, the single boards in slots 5, 7, and 8 report COMMU_FAIL alarms at the same time, and two COMMUN_FAIL alarms are reported on each single board at the same time, and by checking the alarm parameter, it is found that the alarm parameter is indicated as the single board's 485_A serial port bus and 485_B serial port bus. The alarms are reported at the same time, it is possible that both buses are bad.
Alarm InformationScenario 1: The single board is offline:
There is no alarm, but when you check the device panel on the T2000 network management, you can see that the single board is grayed out, and at the same time, you can't query the physical single board on slot 5 with the command line:cfg-get-phybd; you can't query the physical single board on slot 5, and you confirm with the customer about the business impact, and you find that the business is normal.
Scenario 2: COMMUN_FAIL alarm:
The single boards in slots 5, 7, and 8 report COMMU_FAIL alarms at the same time, and two COMMUN_FAIL alarms are reported on each single board at the same time. By checking the alarm parameter, it is found that the alarm parameter indicates that the alarms are reported on the 485_A and 485_B serial buses of the single boards at the same time.
There is no alarm, but when you check the device panel on the T2000 network management, you can see that the single board is grayed out, and at the same time, you can't query the physical single board on slot 5 with the command line:cfg-get-phybd; you can't query the physical single board on slot 5, and you confirm with the customer about the business impact, and you find that the business is normal.
Scenario 2: COMMUN_FAIL alarm:
The single boards in slots 5, 7, and 8 report COMMU_FAIL alarms at the same time, and two COMMUN_FAIL alarms are reported on each single board at the same time. By checking the alarm parameter, it is found that the alarm parameter indicates that the alarms are reported on the 485_A and 485_B serial buses of the single boards at the same time.
ProcessingScenario 1: The single board is offline:
Since the business is normal, you cannot do a single board reset or unplug the single board again, and you can only try to check it with the command line:
:optp:9,0,96,1,30,06,5,1,8,0,0,0,50,0,f; //test the communication of 485_A from the business board of the 5 board position to the cross board of the 9 board position
The test result is that the communication of 485_A is normal;
:optp:9 ,0,96,1,30,06,5,2,8,0,0,0,50,0,f; //Test 485_B communication from 5 board position business board to 9 board position cross board
Test result 485_B communication is normal;
:cfg-get-phybd;
Query result there is no physical board in the slot where faulty veneer board is located;
:cfg-get-bdverinfo:5
Query can't findAny information, suggesting that the single board is not in position;
Judge that the 485_A,485_B bus is normal and the LAN SWITCH bus is faulty;
Scenario 2: COMMUN_FAIL alarm:
Pull out the single boards with alarms one by one and check whether the mother boards are backward pinned;
After pulling out and plugging in a certain single board, you find that the alarms of the other single boards disappear at the same time;
Plug the other single boards back in, and there is no alarm reported;
Judge the faulty single boards; Put the faulty single board in the slot where it is located; Judge the faulty single boards
Plug the faulty board into other slots, and find that the COMMUN_FAIL alarm is reported, and after a period of time, the other slots report this alarm;
Command line query 485 bus:
:optp:9,0,96,1,30,06,5,1,8,0,0,0,50,0,f; //Test the communication of the faulty board to the 485_A of the crossover
:optp:9,0,96,1, 30 ,06,5,1,8,0,0,0,0,f; //test 485_A communication of the faulty board to the crossover board. ,0,96,1,30,06,5,2,8,0,0,0,50,0,f; //test the faulty board to the cross board 485_B communication
test results: faulty single board 485_A,485_B can not be reached;
affected by the report of the alarm on the other single board 485_A,485_B communication is normal, it is judged to be a false alarm;
finally determined to be a single board on the 485 bus damage.
Since the business is normal, you cannot do a single board reset or unplug the single board again, and you can only try to check it with the command line:
:optp:9,0,96,1,30,06,5,1,8,0,0,0,50,0,f; //test the communication of 485_A from the business board of the 5 board position to the cross board of the 9 board position
The test result is that the communication of 485_A is normal;
:optp:9 ,0,96,1,30,06,5,2,8,0,0,0,50,0,f; //Test 485_B communication from 5 board position business board to 9 board position cross board
Test result 485_B communication is normal;
:cfg-get-phybd;
Query result there is no physical board in the slot where faulty veneer board is located;
:cfg-get-bdverinfo:5
Query can't findAny information, suggesting that the single board is not in position;
Judge that the 485_A,485_B bus is normal and the LAN SWITCH bus is faulty;
Scenario 2: COMMUN_FAIL alarm:
Pull out the single boards with alarms one by one and check whether the mother boards are backward pinned;
After pulling out and plugging in a certain single board, you find that the alarms of the other single boards disappear at the same time;
Plug the other single boards back in, and there is no alarm reported;
Judge the faulty single boards; Put the faulty single board in the slot where it is located; Judge the faulty single boards
Plug the faulty board into other slots, and find that the COMMUN_FAIL alarm is reported, and after a period of time, the other slots report this alarm;
Command line query 485 bus:
:optp:9,0,96,1,30,06,5,1,8,0,0,0,50,0,f; //Test the communication of the faulty board to the 485_A of the crossover
:optp:9,0,96,1, 30 ,06,5,1,8,0,0,0,0,f; //test 485_A communication of the faulty board to the crossover board. ,0,96,1,30,06,5,2,8,0,0,0,50,0,f; //test the faulty board to the cross board 485_B communication
test results: faulty single board 485_A,485_B can not be reached;
affected by the report of the alarm on the other single board 485_A,485_B communication is normal, it is judged to be a false alarm;
finally determined to be a single board on the 485 bus damage.
Root CauseScenario 1: The single board is offline:
Analyze the operation of the equipment, and presume that the service bus connecting the cross board is normal, so there is no interruption of the service, and the single board is offline, which means that the communication between the master control and the single board has been interrupted, but then there is no report of the BD_STATUS alarm? It is inferred that only the LAN SWITCH communication is interrupted, and the other communications are normal, and the veneer operation status is not stable.
Try to find out the reason through the following operations:
1. Query whether the physical board is online (cfg-get-phybd to query the physical board position)
2. Check the business impact (to check the impact of the customer's business)
3. Query the communication status of the boards from the command line (to query the communication of the 485 bus and the communication of the LAN SWITCH)
Scenario 2: COMMUN_FAIL alarms:
There are more than one The single board is reported at the same time, it is not possible for multiple single boards to be damaged at the same time, so it is suspected that a single board is damaged and affects other single boards, or there are problems with the mother board, such as inverted pins. Check the alarm parameters to determine the channels affected by the alarm. 485_A and 485_B in the problem have reported COMMUN_FAIL alarms.
Try to identify the cause through the following operations:
1. Query whether the physical board is online (cfg-get-phybd to query the physical board position).
2. Check the business impact (to check the impact of the customer's business).
3. Query the communication status of the boards from the command line (to query the 485 bus communication status). (query 485 bus communication and LAN SWITCH communication)
4, check whether the motherboard is upside down (pull out the faulty veneer and cross boards to check the motherboard pinout)
5, the problem veneer replacement slot test (replace the veneer with alarms to other slots and observe the alarms)
Analyze the operation of the equipment, and presume that the service bus connecting the cross board is normal, so there is no interruption of the service, and the single board is offline, which means that the communication between the master control and the single board has been interrupted, but then there is no report of the BD_STATUS alarm? It is inferred that only the LAN SWITCH communication is interrupted, and the other communications are normal, and the veneer operation status is not stable.
Try to find out the reason through the following operations:
1. Query whether the physical board is online (cfg-get-phybd to query the physical board position)
2. Check the business impact (to check the impact of the customer's business)
3. Query the communication status of the boards from the command line (to query the communication of the 485 bus and the communication of the LAN SWITCH)
Scenario 2: COMMUN_FAIL alarms:
There are more than one The single board is reported at the same time, it is not possible for multiple single boards to be damaged at the same time, so it is suspected that a single board is damaged and affects other single boards, or there are problems with the mother board, such as inverted pins. Check the alarm parameters to determine the channels affected by the alarm. 485_A and 485_B in the problem have reported COMMUN_FAIL alarms.
Try to identify the cause through the following operations:
1. Query whether the physical board is online (cfg-get-phybd to query the physical board position).
2. Check the business impact (to check the impact of the customer's business).
3. Query the communication status of the boards from the command line (to query the 485 bus communication status). (query 485 bus communication and LAN SWITCH communication)
4, check whether the motherboard is upside down (pull out the faulty veneer and cross boards to check the motherboard pinout)
5, the problem veneer replacement slot test (replace the veneer with alarms to other slots and observe the alarms)
Suggestions and SummaryWhen there are alarms in batch, check the actual status of the single board through the command line to determine whether it is a false alarm;
Locate the fault without resetting, unplugging or inserting the single board, and without affecting the service;
Familiarize yourself with the principle of inter-board communication.
Keywords:
Inter-board communication: OSN 7500/3500/2500/1500 inter-board communication has two ways:
1) 2 HDLC channels between single boards, following the HDLC protocol, the interface electrical specification is RS485,
2) 1 LAN SWITCH channel;
485 bus: mainly realizes the functions related to multiplexing segments, SNCP, and TPS, and the rate is4Mbits/s;
LAN SWITCH bus: Ethernet communication between the main control board (or CXL board) and the veneer board and users;
Motherboard inverted pins: the veneer board is inserted in the wrong position resulting in the motherboard pins being tipped over or broken off, which may cause a short-circuit;
OPTP commands: test data packets are sent from the source board bit to the host board bit, and the host board bit sends a test response packet when it receives the test packet, and then the source board bit receives theAfter the test response packet is received by the source board bit, the test response packet is verified to determine whether the test passes;
COMMUN_FAIL alarm: according to the principle that the 485 bus can be self-sending and self-receiving, each veneer board sends a frame of the test packet to itself every 20 S (and the test packet sent by each veneer board can be received by the board only), and the alarm for communication failure is reported if the test packet of the board is not received for 7 consecutive frames;
veneer board not in the
Locate the fault without resetting, unplugging or inserting the single board, and without affecting the service;
Familiarize yourself with the principle of inter-board communication.
Keywords:
Inter-board communication: OSN 7500/3500/2500/1500 inter-board communication has two ways:
1) 2 HDLC channels between single boards, following the HDLC protocol, the interface electrical specification is RS485,
2) 1 LAN SWITCH channel;
485 bus: mainly realizes the functions related to multiplexing segments, SNCP, and TPS, and the rate is4Mbits/s;
LAN SWITCH bus: Ethernet communication between the main control board (or CXL board) and the veneer board and users;
Motherboard inverted pins: the veneer board is inserted in the wrong position resulting in the motherboard pins being tipped over or broken off, which may cause a short-circuit;
OPTP commands: test data packets are sent from the source board bit to the host board bit, and the host board bit sends a test response packet when it receives the test packet, and then the source board bit receives theAfter the test response packet is received by the source board bit, the test response packet is verified to determine whether the test passes;
COMMUN_FAIL alarm: according to the principle that the 485 bus can be self-sending and self-receiving, each veneer board sends a frame of the test packet to itself every 20 S (and the test packet sent by each veneer board can be received by the board only), and the alarm for communication failure is reported if the test packet of the board is not received for 7 consecutive frames;
veneer board not in the
Sell Huawei OSN3500_Product Quotation_Sales Manufacturer_Product Features_Product Description_Huawei SDH Transmission Equipment Sales
Supply Huawei OSN3500_Troubleshooting_Installation_Tuning_Technical Specifications_Technical Parameters_Huawei SDH Transmission Equipment Sales
