Hello, everyone. I'd like to share with you a case of UA5000.
Problem :
Synchronize the service port module of the UA5000 (IPMB) on the NMS, but the system prompts a synchronization failure
Analysis:
Invalid PVC data exists on the UA5000 (IPMB), and CXC data in the service port data synchronized by the NMS is incomplete. After the UA5000 (IPMB) data is parsed, the calculated port index of partial data is 0. As a result, there is a failure of saving the data to the database due to a primary key conflict.
1.Analyze the BmsAccess log of the NMS.
At first, find the entrance of the service port synchronization log of the UA5000 (IPMB), and search the UltraEdit or Nopad++ software according to a keyword [FLOW][TASK_START]CMD=24892. The third line in the searched information lines is the synchronized NE information.
[T1178802496][FLOW][TASK_START]CMD=24892,SPID=30,SM=109,SCH=34,SPH=205,RPID=30,RM=104,RCH=32,RPH=205,RTHREAD=1178802496,TKADDR=0x0x2aaaaac38540
[T1178802496][FLOW][PVC_POLL][START]:CMD=24892,SPID=30,SM=109,SCH=34,SPH=205,RPID=30,RM=104,RCH=32,RPH=205
[T1178802496][FLOW][PVC_POLL]DevInfo[DID=7345341,DIP=10.202.133.6,TYPE=43,VER=UA5000IPMBV100R019C01B038,NAME=M104-00-410_BMAN9
Then, extract all information of the current thread according to the thread ID [T1178802496]. The UltraEdit software makes it convenient to perform search and is recommended.
Finally, search for the following error information in the extracted thread information (the command word 24892 is required to delete other useless information because the thread ID is reusable).
[15:34:30.486],Trace,[T1178802496],==> [PrivateExcBulkInsert|bms_db_manager.cpp|1855]
[15:34:30.581],Warn,[T1178802496],[ExecSQL Failed]: status.Message: [SERVERMESSAGE] Command has been aborted.
status.errorCode: 6 vendor msg1: DBSVR vendor msg2: ZZZZZ vendor code1 = 3621 vendor code2 = 10 [PrivateExcBulkInsert|bms_db_manager.cpp|1938]
[15:34:30.581],Error,[T1178802496],ErrorCode: 0x60000003, oper error. [PrivateExcBulkInsert|bms_db_manager.cpp|1948]
[15:34:30.581],Trace,[T1178802496],<==[94ms] [PrivateExcBulkInsert|bms_db_manager.cpp|1855]
[15:34:30.581],Error,[T1178802496],ErrorCode: 0x60000003, Call Function return Error:PrivateExcBulkInsert(strTableName, oDBDatabase, vBuffer, iExcCount) [ExcBulkInsertEx|bms_db_manager.cpp|2035]
[15:34:30.581],Trace,[T1178802496],==> [ReleaseBulkInsertToKen|bms_db_manager.cpp|1837]
[15:34:30.638],Trace,[T1178802496],<==[57ms] [ReleaseBulkInsertToKen|bms_db_manager.cpp|1837]
[15:34:30.638],Error,[T1178802496],ErrorCode: 0x62400358, update uaipmb_pvc_SrvPortTab table failed! [UpdateDB|bms_pvc_poll_task.cpp|4487]
[15:34:30.639],Trace,[T1178802496],<==[482ms] [UpdateDB|bms_pvc_poll_task.cpp|4407]
The preceding information shows that the error code is vendor code1 = 3261, indicating that the SQL transaction is discarded. Generally, such an error is reported when the primary keys conflict, that is, repeated data exists. In addition, the unsuccessfully operated data table uaipmb_pvc_SrvPortTab is printed in the log. This table is a main service data table of storing service flows of the UA5000 (IPMB).
Up to now, according to the log, it can be determined that the service port data that is synchronized from the UA5000 (IPMB) and that is processed by the background of the NMS failed to be saved to the database due to repeated data, and as a result, the entire synchronization operation failed.
2. When this problem occurs, SNMP synchronization is adopted to synchronize customer data. Next, analyze the captured packet.
At first, as shown in the following figure, for the node 1.3.6.1.2.1.37.1.7.1, the CxC connection ID corresponding to the port index 201408640 is 676.
In the data (theatmVcCrossConnectTable) of the node 1.3.6.1.2.1.37.1.11.1, however, the maximum value of the CxC connection ID is 673. Therefore, all the subsequent CxC data is lost.
The atmVcCrossConnectTable is a MIB table that stores a connection relationship between service ports (ADSL) and uplink ports in the service port data. The CxC connection ID uniquely identifies the connection relationship. The foregoing packet capture result indicates that all data behind the ID 673 is lost. As a result, the downlink port index related to the CxC connection ID is calculated as 0.
The primary keys of the database table BMSDB..uaipmb_pvc_SrvportTab are as follows:
DevID, DstIfIndex, DstPara1, DstPara2, MultiSrvType, MultiSrvUserPara1, MultiSrvUserPara2
Other fields excluding DstIfIndex (ADSL port index) are the same for the same NE. Only one CxC service flow can be created for each ADSL port. Therefore, for each service flow, the value of DstIfIndex is unique. However, the value of this field in many records is calculated as 0 due to incorrect NE data, thereby failing to save the data to the database due to a primary key conflict.
Problem location on the UA5000 (IPMB):
The acquired information shows that residual dynamic entry information already exists on the UA5000 (IPMB). The following entry whose index is 672 corresponds to the entry whose index is 673 in the previously captured packet (the ID on the NMS is greater than the ID in the command line by 1, and therefore the ID 672 on the UA5000 (IPMB) corresponds to the ID 673 in NMS parameters).
According to the preceding figure, however, it can be seen that the queried normal PVC entries of the UA5000 (IPMB) do not contain the entry whose index is 672. This entry belongs to an abnormal residual entry. According to the current analysis result, the synchronization failure is caused by this entry.
The UA5000 (IPMB) has not been successfully synchronized for a long time. Therefore, it is advisable to save and back up the latest configuration file, re-load the configuration file to the UA5000 (IPMB), and activate the configuration file.
A new database is re-generated when the configuration file is activated. Then load the SPH226 patch to the UA5000 (IPMB) to avoid dynamic residual entries. After that, the problem is completely solved
Solution
The SPH226 patch based on the UA5000 V100R019C01SPC200 has solved dynamic residual entries for the UA5000 (IPMB). In the UA5000 V100R019C02SPC100, no patch is available for this problem. This problem is also solved in the latest version and patch of the UA5000 V100R019C07. As the host R&D personnel suggest, deploy the relevant patch on the host, and save and re-activate the configuration file to delete dynamic residual entries to solve the problem.
Suggestion and Summary
In addition to data inconsistency between the NMS and the UA5000 (IPMB), a service port synchronization failure may also result in other derived problems. For example, for a customer of an office outside China, the upper-layer OSS first executes the LST-SERVICEPORT command to query whether the service port data exists. If the service port data does not exist, the CRT-SERVICEPORT command is executed to create the service port data. The LST-SERVICEPORT command, however, is used to query data in the NMS database. In this way, service flows of a port cannot be queried, but the service flows are actually available on the UA5000 (IPMB). Therefore, when the OSS delivers the command of creating a service flow, an error "The Connection has existed" is reported.
Matching Rule
ErrorCode: 0x62400358, update uaipmb_pvc_SrvPortTab table failed!
