A game studio rotates an OSPF key on a Nexus link. Both peers will accept the new key today, and the send lifetime of that key starts tomorrow. Authentication fails tonight. Why is the new key absent from the packets?
Select an answer to reveal the explanation.
Short Explanation
Think of the new key as a badge you can accept before you start wearing it. Both peers accept it today, but the send lifetime begins tomorrow, so tonight’s packets do not carry it.
Full Explanation
An OSPF key-chain key has an accept lifetime and a send lifetime. Accept means a peer will trust packets that use the key; send means a router will use the key in packets it transmits. Here, both peers accept the new key today, but its send lifetime starts tomorrow, so neither router puts it in tonight’s packets. The accept lifetimes do overlap, so rejection due to non-overlapping accept lifetimes does not explain the failure. MACsec must-secure can drop frames without MACsec headers on a hop where that policy applies, but it does not determine whether OSPF includes a key whose send lifetime has not begun. Applying the key chain to a VRF rather than to the OSPF interface would be a configuration-placement issue; it does not explain the stated timing, where the key is not yet valid to send. Caveat: during a key rotation, overlap the new key’s send lifetime with the old key’s accept lifetime so packets remain trusted during the transition. Practical check: inspect the key chain and confirm the new key’s send lifetime includes the current time before investigating the password string.