A government agency rotates an OSPF key chain. Neighbors drop when the old key lifetime ends, and the replacement key is set to start the next morning. What was missing from the key schedule?
Select an answer to reveal the explanation.
Short Explanation
You shredded yesterday's warehouse key at closing and the new key does not arrive until morning, so nobody can get in overnight. You overlap the key lifetimes so the new OSPF key is accepted before the old one stops being sent. A reload does not invent that overlap, and the neighbors will drop again on the next gap.
Full Explanation
A key chain rotates authentication keys by time. Each key has a window when it may be sent and a window when it will be accepted. If the old key stops before the new key starts, as it does for this agency overnight, the neighbors have no key they both accept and the adjacency drops. The missing piece is an overlap: the new key must be accepted while the old key is still being sent, so the change has a period when either key works. Reloading both neighbors does not move a key chain forward. They will still refuse each other until a key is valid on both sides. MACsec encrypts frames on a link and uses its own key agreement. It does not extend an expired OSPF key until morning. OSPF interface priority influences designated-router election. It does not let a neighbor authenticate with no key, and raising it will not hold the adjacency through a gap in the key schedule. Caveat: the clocks on the two switches have to agree closely enough that the overlap you configured is actually overlap in real time. Operational check: set the new key's accept window to begin before the old key's send window ends, then confirm the adjacency stays up across the change without a reload.