In this article, we examine a scenario where OSPF flaps without any relevant trigger, configuration discrepancy, or supporting logs. The issue was ultimately traced to a policer applied to the protocol, which dropped packets during periods of high LSDB changes.

• OSPF sessions go down for extended periods of 15 to 30 minutes. 
• No relevant logs are observed in either the syslog or OSPF trace options to determine the root cause. 
• The OSPF flapping occurs consistently, almost always at the same time of day.
• Policer configured under the loopback interface, matching OSPF packets.

The only relevant logs observed consistently at the same time each day during the OSPF flap are as follows:

Jun 20 00:25:23 user rpd[7075]: RPD_OSPF_NBRDOWN: OSPF neighbor x.x.x.x (realm ospf-v2 irb.31 area 0.0.0.0) state changed from Full to Down due to InActiveTimer (event reason: neighbor was inactive and declared dead)

Jun 20 00:26:05 user rpd[7075]: RPD_OSPF_NBRDOWN: OSPF neighbor x.x.x.x (realm ospf-v2 irb.31 area 0.0.0.0) state changed from Exchange to Down due to InActiveTimer (event reason: neighbor was inactive and declared dead)

Jun 21 00:25:55 user rpd[7075]: RPD_OSPF_NBRDOWN: OSPF neighbor x.x.x.x (realm ospf-v2 irb.31 area 0.0.0.0) state changed from Full to Down due to InActiveTimer (event reason: neighbor was inactive and declared dead)

Jun 21 00:26:37 user rpd[7075]: RPD_OSPF_NBRDOWN: OSPF neighbor x.x.x.x (realm ospf-v2 irb.31 area 0.0.0.0) state changed from Exchange to Down due to InActiveTimer (event reason: neighbor was inactive and declared dead)

Jun 21 00:52:02 e user rpd[7075]: RPD_OSPF_NBRDOWN: OSPF neighbor x.x.x.x (realm ospf-v2 irb.31 area 0.0.0.0) state changed from Full to Down due to InActiveTimer (event reason: neighbor was inactive and declared dead)

Jun 22 00:31:42 user rpd[7075]: RPD_OSPF_NBRDOWN: OSPF neighbor x.x.x.x (realm ospf-v2 irb.31 area 0.0.0.0) state changed from Full to Down due to InActiveTimer (event reason: neighbor was inactive and declared dead)

Jun 22 00:32:24 user rpd[7075]: RPD_OSPF_NBRDOWN: OSPF neighbor x.x.x.x (realm ospf-v2 irb.31 area 0.0.0.0) state changed from Exchange to Down due to InActiveTimer (event reason: neighbor was inactive and declared dead)

The logs indicate that the device did not receive a Hello packet within the respective Dead Interval (typically 40 seconds), so the neighbor was declared down, however, it does not indicate the reason why the Hello packets were not received in first place.

When checking the Firewalsl, we can see the following configuration applied under the Loopback interface, matching OSPF protocol with a Policer applied to the term:

set interfaces lo0 unit 0 family inet filter input RE-PROTECT 

set firewall policer POLICER filter-specific
set firewall policer POLICER if-exceeding bandwidth-limit 128k
set firewall policer POLICER if-exceeding burst-size-limit 10k
set firewall policer POLICER then discard

set firewall family inet filter RE-PROTECT term OSPF from protocol ospf
set firewall family inet filter RE-PROTECT term OSPF then policer POLICER

root@user> show firewall

Filter: RE-PROTECT
Policers:
Name                                                   Bytes              Packets
POLICER                                                1313932            7678     < There are hits for this when the OSPF sessions go down.

OSPF packets were policed and subsequently dropped during periods of high LSDB changes. After removing the Policer applied to the OSPF protocol, the issue was resolved. If this scenario is encountered, you can either delete the Policer applied to the term matching the protocol or increase the bandwidth and burst parameters, depending on your traffic patterns