The GETVPN Resiliency - GM Error Detection feature should be enabled on both the GM and KS for error handling to work. The
KS encodes the group information in the SPI (Security Parameter Index) and then it downloads it via the TEK policy to the
GM.
When a failure is detected by the GETVPN Resiliency - GM Error Detection feature, a syslog message is generated to show the
source IP address of the erroneous packet:
*Feb 10 21:01:56.043:
%GDOI-4-TIMEBASED_REPLAY_FAILED: An anti replay check has failed in
group GETVPN from sourceip-address
100.0.0.9.
my_pseudotime is 600006.78 secs,
peer_pseudotime is 500033.34 secs, replay_window is 100
(second)
*Feb 10 21:01:56.043:
%CRYPTO-4-PKT_REPLAY_ERR: decrypt: replay check failed
connection id=29, sequence
number=11
The show crypto gdoi gm command displays the history of the last 50 Time-Based Anti-Replay (TBAR) errors. You can use these source IP address records
to track down the sender group members (GMs) and investigate any existing hardware or software problems. The following statistical
information is also available in the command:
-
GM recovery feature ON/OFF
-
Interval between recoveries
-
Number of GM recovery reregistration enforced
When errors occur, the GM reregisters to the next available key server (KS) to retrieve the latest policy and keys and maintains
all previously downloaded group policies and keys until the registration is complete.
For instance, when a cooperative key server (COOP KS) split occurs, each promoted KS generates its own Key Encryption Key
(KEK) and Traffic Encryption Key (TEK). When a GM receives invalid SPI packets, it will decode it (the KS encodes the group
information in the SPI and then it downloads it via the TEK policy to the GM) and if it finds that it belongs to the current
getvpn group then it will start the recovery registration.
An invalid SPIs can belong to one of the following two categories:
In the case of a positive invalid SPI, a recovery registration to the next key server (KS) on its list is performed. This
recovery registration is repeated for each invalid stateful packet inspection (SPI) packet or TBAR error in each client recovery
interval to the next KS on the list. When all the KSs in the list are recovered and no longer contain the invalid SPI, that
SPI is marked as a false positive and no more recovery registrations are performed. The KSs will always do the recovery registration
for TBAR errors. However, once the GM recovers to all the KSs in the list because of an invalid SPI and none of the KSs has
that SPI, it will mark that SPI as a false positive and will not do more recovery registrations due to that SPI.
A syslog message is generated to notify you that this GM recovery reregistration feature is triggered. For instance, if you
configure the GM to monitor for control-plane errors every 300 seconds, when the recovery registration occurs the following
syslog is generated:
*Feb 23 19:06:28.600: %GDOI-5-GM_RECOVERY_REGISTER: received invalid GDOI packets; register to KS to refresh policy, keys, and PST.
Feedback