This article explains why OSPF/ISIS flaps with reason 'InactiveTimer' and the possible scenarios in which this can happen. A troubleshooting command is provided to quickly narrow down whether the issue is with RPD utilization and/or host queue on the device.
OSPF and ISIS may flap with the following message:
Jun 1 07:06:24 router-name rpd[6987]: %DAEMON-5-RPD_OSPF_NBRDOWN: OSPF neighbor 100.64.1.1 (realm ospf-v2 ae157.0 area 0.0.0.0) state changed from Full to Down due to InActiveTimer (event reason: neighbor was inactive and declared dead)
This is an indication that the consecutive hellos are not received/seen by the local router and the hold time has expired for that particular adjacency/neighbor.
This can happen when the neighbor is indirectly connected to the local router and either the peer is down or there is an indirect link failure.
There is also a possibility the local router received a burst of other control packets at a point where it is not able to handle them, which leads to dropping subsequent hellos for ISIS/OSPF and eventually dropping ISIS/OSPF adjacency.
Another possibility is RPD utilization consistently stays high and ISIS/OSPF protocols are not getting enough cycles to process the hello packets. Then eventually ISIS/OSPF times out.
Check if there are any drops in the net.isr queue with the following sysctl command executed under RE shell:
sysctl
% sysctl net.isr.drop
Check CPU/RPD utilization to see if it spiked to 100% while the ISIS/OSPF adjacency timed out. For steps to troubleshoot high CPU, refer to the following articles:
Collect the following DDOS output to see if there was any DDOS violation which could have lead to host path being congested. Troubleshoot based on which protocol is violated.
>show ddos-protection protocols
Check protocol traceoptions for any issues with the hello packets being missed:
set protocols ospf traceoptions flag all set protocols isis traceoptions flag all