Got it

How to analyse the logs generated in the S switch

Latest reply: May 30, 2019 00:45:16 168 1 0 0

During the troubleshooting, the logs generated in the device could help us know what had happened to the deivce, it’s convenient way to get the information about the device errors from the logs. But the logs seems to be unreadable. Actually, the logs are generated in a specific format.


As the picture in the documentation said, the logs contain 10 parts.

%% refers to the identity of Huawei, indicating that the log is produced by a Huawei product.


It indicates the type of the log information.

(l): Log

(t): Trap

(d): Debug

(s): Security log

The flag (l) and Description are separated by a colon (:).


Let's take a look at the following example.


May 29 2019 16:10:31-08:00 Huawei %OSPF/4/NBR_CHANGE_E(l)[0]:Neighbor changes event: neighbor status changed. (ProcessId=1, NeighborAddress=, NeighborEvent=LoadingDone, NeighborPreviousState=Loading, NeighborCurrentState=Full)


In the case of the first log, compared with the log message format, we have the following tables:


May 29 2019 16:10:31-08:00


















neighbor changes event: neighbor status changed. (ProcessId=1, NeighborAddress=, NeighborEvent=LoadingDone, NeighborPreviousState=Loading, NeighborCurrentState=Full)


We could know that these logs were generated by a device named Huawei on May 29 2019 16:10:31, and this is generated by the OSPF module. The brief tells us it’s a log about a neighbor.

The relationship changes. From the description, we could learn more, such as the ospf processId is 1, the relationship between the two device are transferred fromcloading to full, and the ip address of the neighbor is

From this log, we could learn that the local device has established ospf neighbor relationship with the remote peer


Let’s take a look at another example.


May 29 2019 16:28:34-08:00 r1 %OSPF/4/CONFLICT_ROUTERID_INTF(l)[0]:OSPF Router id conflict is detected on interface. (ProcessId=1, RouterId=, AreaId=, InterfaceName=GigabitEthernet0/0/0,  IpAddr=, PacketSrcIp=



The customer reported that they cannot ping the remote peer; we found the logs above.

According to the steps mentioned before, we can learn that this log is generated by the OSPF module, so there must be OSPF configuration on the device. After that, the brief of the log is CONFLICT_ROUTERID_INTF, it indicates the conlict routerid when establish the ospf neighbor relationship. Check the description, we could learn that the conflicted routerid is, then we can check the configuration of the OSPF and change the conflicted routerid. After that, the neighbor relationship established between the two devices,and the ping to the remote peer is OK. 

  • x
  • convention:

Created May 30, 2019 00:45:16 Helpful(0) Helpful(0)

This is very helpful for my study. Thank you very much.
View more
  • x
  • convention:



You need to log in to comment to the post Login | Register

Notice: To protect the legitimate rights and interests of you, the community, and third parties, do not release content that may bring legal risks to all parties, including but are not limited to the following:
  • Politically sensitive content
  • Content concerning pornography, gambling, and drug abuse
  • Content that may disclose or infringe upon others ' commercial secrets, intellectual properties, including trade marks, copyrights, and patents, and personal privacy
Do not share your account and password with others. All operations performed using your account will be regarded as your own actions and all consequences arising therefrom will be borne by you. For details, see " Privacy."

My Followers

Login and enjoy all the member benefits


Huawei Enterprise Support Community
Huawei Enterprise Support Community
Are you sure to block this user?
Users on your blacklist cannot comment on your post,cannot mention you, cannot send you private messages.
Please bind your phone number to obtain invitation bonus.