OSPF adjacency flapping with "Counterfeit packet received" messages in routed.log

OSPF adjacency flapping with "Counterfeit packet received" messages in routed.log

307
Created On 09/21/23 06:32 AM - Last Modified 02/18/26 22:36 PM


Symptom


  • OSPF neighbors flap with "Counterfeit packet received" message in routed.log
  • This happens due to the continuous dropping of control packets prevents by the Firewall thereby failing to maintain the Full State.
  • Log will be generated in routed.log (less mp-log routed.log)  similar to the one listed below.
**** EXCEPTION 0x3e02 - 42 (0000) **** I:07bd7133 F:00000020
qon2auth.c 1311 :at 17:04:40, 17 August 2020 (1759327867 ms)
OSPF 5 Counterfeit packet received.
Received cryptographic sequence number = 8344571.
Previous cryptographic sequence number = 8344577.
Packet data =
02040598 AC10FD17 00010100 00000002 00000310 007F53FB 00000027 00092005
0A490900 AC10FD19 80000413 DEE60024 FFFFFF00 0000000A 00000000 0003AA71
00082005 0A4F0200 AC10FD19 8000000D FBD40024 FFFFFF00 0000000A 00000000
0003AA71 00092005 0A600700 AC10FD19 800000F4 28AA0024 FFFFFF00 0000000A
00000000 0003AA71 00092005 0A600800 AC10FD19 800000F4 1DB40024 FFFFFF00
0000000A 00000000 0003AA71 00092005 0AC40100 AC10FD19 80000E0E 59F30024
FFFFFF00 0000000A 00000000 0003AA71 00082005 AC1641C8 AC10FD19 800000CD
2D780024 FFFFFFF8 0000000A 00000000 0003AA71 00092005 AC1641D8 


Environment


  • Palo Alto firewalls
  • OSPF v2
  • MD5 authentication


Cause


  • When OSPF authentication is enabled, auth hashing is used to validate the packet received from the neighbor.
  • An element of that packet is the sequence number that is used for the auth process.
  • As per RFC2328 the value received should be as large or higher than the previous one.
  • In this case the 32 bit cryptographic sequence number received is lesser than the one received previously causing failure (highlighted above, the received  is not higher than 8344577).
  • This causes the firewall to identify them as out-of-order or replayed and silently drops all OSPF packet types.


Resolution


  1. Clear OSPF Neighbor. This will force a reset of the sequence number.
  2. Ensure all devices in the network have synchronized clocks. Using NTP servers can help in this.
  3. if the issue is localized to the one of the neighbor device, Ensure the peer does not undergo any uncoordinated reboots (crash/power outage) or configuration rollbacks. These actions cause the neighbor to revert to an earlier sequence number that our firewall will reject.


Additional Information


Firewall or Panorama NTP status displaying "rejected"



Actions
  • Print
  • Copy Link

    https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA14u000000XgaACAS&lang=en_US&refURL=http%3A%2F%2Fknowledgebase.paloaltonetworks.com%2FKCSArticleDetail