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.
(I)
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=10.1.12.2, NeighborEvent=LoadingDone, NeighborPreviousState=Loading, NeighborCurrentState=Full)
***************************************************************************************************************************
In the case of the first log, compared with the log message format, we have the following tables:
timestamp | May 29 2019 16:10:31-08:00 |
hostname | Huawei |
%% | %% |
dd | 01 |
modulename | OSPF |
serverity | 4 |
brief | NBR_CHANGE_E |
(I) | (I) |
count | 0 |
description | neighbor changes event: neighbor status changed. (ProcessId=1, NeighborAddress=10.1.12.2, 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 10.1.12.2.
From this log, we could learn that the local device has established ospf neighbor relationship with the remote peer 10.1.12.2.
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=2.2.2.2, AreaId=0.0.0.0, InterfaceName=GigabitEthernet0/0/0, IpAddr=10.1.12.1, PacketSrcIp=10.1.12.2)
***************************************************************************************************************************
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 2.2.2.2, 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.
