ISIS_1.3.6.1.3.37.2.0.17 isisAdjacencyChange

Description

ISIS/2/ADJ_CHANGE:OID [oid] The state of IS-IS adjacency changed. (sysInstance=[integer], sysInstanceofLevel=[integer], sysLevel=[integer], sysInstanceofInterface=[integer], circuit=[integer], ifIndex=[integer], circuitIfIndex=[integer], lspID=[opaque], adjState=[integer], ifName=[string], hwIsisAdjChangeReason=[integer], hwIsisAdjChangeSubReason=[integer])

The status of the neighbor changed.

Attribute

Alarm ID	Alarm Severity	Alarm Type
1.3.6.1.3.37.2.0.17	Major	communicationsAlarm(2)

Parameters

Name	Meaning
oid	Indicates the MIB object ID of the alarm.
sysInstance	Indicates the ID of the IS-IS process.
sysInstanceofLevel	Indicates the ID of the IS-IS process.
sysLevel	Indicates the IS-IS level: 1: Level-1 2: Level-2
sysInstanceofInterface	Indicates the ID of the IS-IS process.
circuit	Indicates the ID of the circuit.
ifIndex	Indicates the index of the interface.
circuitIfIndex	Indicates the IF index of the interface.
lspID	Indicates the ID of the LSP.
adjState	Indicates the status of the neighbor. 1: Down 2: Initializing 3: Up 4: Failed 5: Cleared
ifName	Indicates the name of the interface.
hwIsisAdjChangeReason	Indicates the main cause of the change in the neighbor relationship: 1: The hold timer expired. 2: The status of the physical interface changed. 3: It is a protocol-related cause. 4. The BFD session went Down. 5: A configuration was changed. 6. It is a neighbor-related cause. 7. Other causes. 8. The alarm was cleared. 100: The neighbor was cleared.
hwIsisAdjChangeSubReason	Indicates details about the cause of the change in the neighbor relationship: 1: status of peer relation getting up 2: peer deleted 3: interface deleted 4: interface silence 5: invalid hello packets received 6: authentication failed 7: system ID conflict 8: maximum area address number mismatch 9: different L1 area addresses 10: hello packet receiving failure 11: interface down 12: protocol mismatch 13: adjacency deleted for space 14: BFD session getting down 15: level change 16: P2P negotiations change 17: peer reset 18: interface type change 19: IS-IS reset 20: undo network 21: undo isis 22: level mismatch 23: no local MAC address in the received Hello packet 24: three-way adjacency not up 25: topology mismatch 26: circuit ID mismatch 27: Down three-way adjacency state 28: other errors 29: optional checksum TLV check failed

Impact on the System

IS-IS may re-calculate routes, which causes route flapping and interrupts the IS-IS service.

Possible Causes

1. The IS-IS neighbor relationship went Up or Down.

2. The IS-IS configuration was incorrect.

3. The system was busy, and consequently the IS-IS neighbor relationship was intermittently interrupted.

4. The link failed, and consequently the status of the IS-IS neighbor relationship was changed.

Procedure

According to the IS-IS packet format defined in ISO 10589, find the LspID field (in hexadecimal format) in the trap to identify the system ID of the source switch. Then, check whether the neighbor status on both ends is the same.
- If so, go to Step 12.
- If not, go to Step 2.
Download the user logs from the source switch, and then find out the cause for the neighbor status change according to the logs. Check whether the neighbor status is changed because the interface goes Down.
- If so, go to Step 3.
- If not, go to Step 10.
Find information about the local interface from the logs, and then check the interface status and MTU status on the interface. Ensure that both the interface status and MTU status on two ends are Up. Then, check whether the neighbor status on both ends is the same.
- If so, go to Step 13.
- If not, go to Step 4.
Check the system IDs and ensure that the system IDs on both ends are correct. Then, check whether the neighbor status on both ends is the same.
- If so, go to Step 13.
- If not, go to Step 5.
Check the levels of the IS-IS process and ensure that levels on both ends match. Then, check whether the neighbor status on both ends is the same.
- If so, go to Step 13.
- If not, go to Step 6.
Check the area ID of the switch and ensure that area IDs on both ends are the same. Then, check whether the neighbor status on both ends is the same.
- If so, go to Step 13.
- If not, go to Step 7.
Check that IP addresses of interfaces on both ends belong to the same network segment. Then, check whether the neighbor status on both ends is the same.
- If so, go to Step 13.
- If not, go to Step 8.
Check whether the authentication mode is configured on both ends and ensure that the encryption authentication modes on both ends are the same. If authentication is required, ensure that the authentication modes and passwords on both ends are the same. Otherwise, authentication is disabled on both ends (disabling authentication degrades the system security). Then, check whether the neighbor status on both ends is the same.
- If so, go to Step 13.
- If not, go to Step 9.
Check whether interfaces on both ends can transmit Hello packets normally and ensure that they can transmit Hello packets normally. Then, check whether the neighbor status on both ends is the same.
- If so, go to Step 13.
- If not, go to Step 10.
Run the display cpu-usage command to check whether the CPU usage remains 100% in a period of time.
- If so, go to Step 11.
- If not, go to Step 12.
Run the isis timer hello command in the interface view to set the interval for sending Hello packets to a larger value, which increases by 10s each time. Prolonging the interval for sending Hello packets slows down the detection of network faults and thus slows down route convergence. Then, check whether the neighbor statuses on both ends are the same.
- If so, go to Step 13.
- If not, go to Step 12.
Collect the trap information, log information, and configuration, and then contact technical support personnel.
End.

Related Information

None