A game studio rotates the OSPF key chain on a Nexus link, and the adjacency drops at each rotation. The new key lifetime starts only after the old key lifetime ends. What prevents that drop?
Select an answer to reveal the explanation.
Short Explanation
A key rotation without overlap is changing the lock while the other guard still has the old key. You overlap the new key accept lifetime with the old key so both peers still share one valid key during the change. Reusing one key forever, or renaming the OSPF process, does not fix a gap between lifetimes.
Full Explanation
A key chain lets a routing protocol rotate keys by giving each key a lifetime. During a rotation, the sending side and the receiving side have to agree on at least one key. If the new key's accept lifetime starts only after the old key's lifetime ends, there is a gap where the sender offers a key the peer will not accept, and the OSPF adjacency drops. Overlapping the new key's accept lifetime with the old key closes that gap so both peers still share a valid key while the change happens. A key chain is built to hold more than one key. Keeping a single key ID forever avoids rotation, and it is not a protocol limit that rejects a second key. MACsec uses MKA for link keys. An OSPF key chain authenticates OSPF, and removing OSPF authentication would leave the adjacency up only by abandoning the control the studio is trying to rotate. The OSPF process tag is a local process name. Neighbors do not use it to pick a key ID. Caveat: the overlap has to exist on both peers, and the key ID and key string still have to match, or a perfect lifetime still fails authentication. Operational check: configure the overlapping accept lifetime on both ends, rotate once in a window, and confirm the neighbor stays full through the change.