Support Support Downloads Knowledge Base Case Manager My Juniper Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

[Archive] IDP, standalone HA, schad error messages

0

0

Article ID: KB6522 KB Last Updated: 17 Dec 2012Version: 4.0
Summary:
IDP, standalone HA, schad error messages
Symptoms:
Environment:
  • IDP HA, schad messages
  • IDP, HA, standalone, proxy-arp mode, (hotstandby or load sharing)

Symptoms & Errors:

  • Warn: Possible replay attack on node 1 at 1045396616.990043
Cause:

Solution:

The 'possible replay attack' error message is occurring because "old" heartbeat packets are being received.  Each heartbeat packet contains the current time (measured in seconds) of the node sending the packet.

Each node receiving the heartbeat tracks:

  • The last timestamp from each node
  • When that packet was received.

Then when the next heartbeat is received, the node verifies if the timestamp (in the packet) is less then the last timestamp recorded. If yes, then warn that a "replay attack" may be occurring.

Possible Causes of this problem:

  • Someone/thing turned back the clock on the node sending the heartbeats. This would cause the timestamp to go "backwards" and generate this error. It will continue reporting this error until:
    • It catches up to the old time
    • You restart schad on the other (receiving) nodes
  • Someone captured a heartbeat packet and is replaying that packet  onto the network.
  • Some problem with the network is causing packets to get delayed and the heartbeats are being received out of order. This would have to be  a pretty serious problem, since heartbeats are sent out once a second.

In conclusion, Neither #2 or #3 (above) are a problem. The IDP heartbeat mechanism was designed to be resilient to these problems.

#1 is a serious problem however. If you turn back the clock, the other node(s) in the cluster will mark that node as "DOWN", however the actual node will still be "UP". This will cause problems on the network. Running sctop and checking the HA status on each node (w option) will show this as the case.  Again, restarting schad ('service idp restart') on the nodes will clear the problem right up.

Additional Information:

Location of the schad messages is: /usr/idp/device/var/sysinfo/logs/schad.

Warn: Possible replay attack on node 1 at 1045396616.990043

Here's more info:

"1045396616.990043" refers to an absolute time in seconds since 1/1/1970 0:0:0 GMT. 1045396616.990043 seconds since 01/01/1970 means 33 years plus something, because 1045396616/60/60/24/365 = 33.something.

So 1045396616.990043 = some time in 2003 Feb.
As a matter of fact, our NetScreen firewall-devices uses the same format in referring to time. The command: 'Get clock' on any NetScreen firewall will display this kind of time reference.



Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search