ONU version information, FTP, synchronization failure
When an NMS synchronizes with ONUs from an OLT through the FTP, the character string length of the version information (such as the equipment ID, ONT model, ONU hardware version, ONU primary software version, ONU secondary software version) reported by some ONUs exceeds the maximum length defined in the protocol, and the reported character string does not contain any string tokenizer. As a result, the NMS fails to synchronize with the ONUs, and customers cannot manage the newly-deployed ONUs or deploy new services.
- The U2000 is earlier than V100R006C02CP3207 and the OLT is the MA5680T V800R011 earlier than V800R011C00SPC107 or MA5680T V800R012 earlier than V800R012C00SPC103.
- The NMS synchronizes with ONUs through the FTP.
- The character string length of the version information reported by some ONUs exceeds the maximum length defined in the protocol, and the reported character string does not contain any string tokenizer. (As defined in the protocol, the maximum length of the equipment ID or ONT model is 20 bytes and that of ONU hardware version, primary software version, and secondary software version is 16 bytes.)
When the above conditions are met, the NMS fails to synchronize with the ONUs.
The following describes the possible symptoms:
- The ONUs cannot be displayed on the NMS network topology.
- ONU information, such as the ONU SN (GPON), LOID (EPON), and equipment ID, cannot be displayed on the NMS interface.
- ONU information cannot be found on the OLT.
If the above symptoms occur, use the following methods to determine whether they are caused by the problem in this precaution.
If both the NMS and the OLT are in the version ranges mentioned above, proceed to the next step.
- On the NMS:
Synchronize with the ONUs on the NMS, and reproduce the synchronization failure. View the NMS synchronization log, U2000\server\var\logs\Develop\BmsAccess_9961\BmsAccess_*_*.log or U2000\server\var\logs\Develop\BmsAccess_1\BmsAccess_*_*.log (* indicates the date and time), and check whether the following error message is displayed:
Call Function return Error:DoUpdate(pTableDesc, pSrcTable, pOutPutTable)
If not, the problem described in this precaution does not occur. The synchronization failure is caused by other causes.
If yes, the character string length exceeds the maximum length when the NMS parses the POD file. Therefore, the information cannot be written into the NMS database. The problem can be solved by using the suggested solutions in this precaution (see “Measures and Solutions”).
- On the OLT:
Query all ONT version information on the faulty OLT. The command output of the GPON or EPON ONT version information is as follows:
In the command output, if the type name, software version, or hardware version of a certain ONU exceeds the maximum length listed in the following table, the character string reported by the ONU does not contain any string tokenizer, which results in the problem described in this precaution. The problem can be solved by using the suggested solutions in this precaution (see “Measures and Solutions”).
|GPON ONU||EPON ONU|
|Information||Maximum Length||Information||Maximum Length|
|Equipment-ID||20 bytes||ONT model||20 bytes|
|ONT Version||16 bytes||ONT hardware version||16 bytes|
|Main Software Version||16 bytes||ONT software version||16 bytes|
|Standby Software Version||16 bytes||–||–|
Use the following method to confirm the character string: Copy the ONT model or software version information to the UltraEdit, and choose View > Display Ruler from the main menu.
The version information reported by the ONU does not contain a string tokenizer.
The following uses the ONU software version as an example.
Different ONUs use different methods to report the ONU software version. Generally, an ONU adds a string tokenizer \0 at the end of the reported character string. In this way, the upper-layer device detects how many bytes the software version reported by the ONU contains.
If an ONU reports a 16-byte character string to the OLT but does not add a string tokenizer at the end of the character string, the OLT cannot determine how many bytes this character string contains. Therefore, the character string length of the ONU software version reported by the OLT to the NMS is uncertain, and may exceed the maximum length supported by the NMS. In addition, the NMS does not support this abnormal behavior and considers that the character string length of the ONU software version exceeds the maximum length. The NMS fails to parse the ONU software version. Consequently, the NMS fails to synchronize with the ONU.
[Impact and Risk]
If the character string length of the reported ONU software version exceeds the maximum length defined in the protocol and reported ONU software version does not contain a string tokenizer, the NMS fails to synchronize with the ONU through the FTP. As a result, customers cannot manage the newly-deployed ONUs or deploy new services.
[Measures and Solutions]
The NMS synchronizes with ONUs through the SNMP instead of the FTP, but the synchronization efficiency will be reduced by about 80%.
If you need to use this solution, contact Huawei R&D engineers for confirmation in advance to prevent NMS performance from being affected. The specific methods for synchronizing with ONUs through the SNMP are as follows:
- Back up theU2000\server\nemgr\nemgr_access\dcp\platform\v100\feature\gdm\mxu_conf_dev_feature.xml file.
- Copy the backup file and edit it. Find <feature name=”PollOptimize” support=”1″>in the file as follows:
- The <dev type> structure in the file indicates an NE type and its version range information, among which the dev typefield uniquely identifies the NE type. Delete the corresponding <dev type> structure based on the faulty equipment type on the live network.
Use the MA5600T and MA5680T as examples. In the dev type=”41″ and dev type=”45″ fields, 41 indicates the MA5600T, and 45 indicates the MA5680T. Delete the corresponding structures (the following two lines in the given XML file) for the NMS to synchronize with these two types of NEs through SNMP:
<dev type=”41″ area=”[MA5600V800R006C03B000,MA5600V800R006C03BZ);[MA5600V800R006C32B010,MA5600V800R006C33BZ);[MA5600V800R006C72B010,MA5600V800R006C72BZ);[MA5600V800R007C00,MA5600V800RZ)”/>
<dev type=”45″ area=”[MA5600V800R006C32B010,MA5600V800R006C32BZ);[MA5600V800R006C72B010,MA5600V800R006C72BZ);[MA5600V800R007C00,MA5600V800R007CZ);[MA5680V800R007,MA5680V800R099CZ);[MA5683V800R007,MA5683V800R099CZ)”/>
The values of Dev type and the specific NE types are mapped as follows.
|Dev type||Equipment Type|
- Restart the following processes: profile, BmsAccess, BmsCommon, TL1NbiDm, inTL1NbiDm, BmsTimingTask, BmsTest, BmsAtur, and BmsHGMPDm. For processes that cannot be found, ignore them.
A patch for the NMS is released to resolve this issue. Patch version: U2000 V100R006C02SPC303 (to be released on September 30, 2013)
A patch for the OLT is released to resolve this issue. Patch version: MA5600T V800R011C00SPC109 (to be released on September 15, 2013)
Patch version: MA5600T V800R012C00SPC103 (to be released on August 20, 3013)
The problem can be resolved by loading the NMS patch or the OLT patch.