An IOS XE IPsec SA to an AWS tunnel stays up. Small pings succeed. Some packets drop, and the SA shows a rising anti-replay error count. What explains the drops?
Select an answer to reveal the explanation.
Short Explanation
The tunnel is up, and the internet is shuffling the packets before they reach you. You are dropping them because anti-replay thinks a late packet is a replay. A wrong pre-shared key would not have left this SA up and passing pings.
Full Explanation
Anti-replay protects an IPsec security association against resent packets. When the public internet reorders packets enough to fall outside the window, the router counts an anti-replay error and discards the packet even though it was legitimate. Small pings still pass because they are not the packets that arrived late. The SA staying up is consistent with this fault. A wrong pre-shared key would have prevented the SA. It would not increment replay errors on a live association. The BGP hold timer does not mark data packets as replays. A dead BGP session would remove routes, not stamp surviving packets. TCP MSS clamping changes the maximum segment size during the handshake. It does not rewrite IPsec sequence numbers or create replay errors. Exam caveat: widening the anti-replay window can absorb reordering and it accepts a larger window for actual replays. Confirm the drops match the error counter before you change it. Operational check: the replay error counter on show crypto ipsec sa should stop climbing after the window is widened or after the reordering on that path is removed, and the previously dropped flow should pass.