A national retailer's two Nexus switches exchange OSPFv2 hellos, the interface MTU matches, and the hello and dead timers match, but the adjacency never forms. One side of the link is a stub area and the other is not. Which mismatch is stopping the neighbor?
Select an answer to reveal the explanation.
Short Explanation
OSPF hellos are a handshake, and one side is wearing a different glove. You already matched the MTU and the timers, so the stub flag is what keeps this neighbor from forming. The process tag is local to each switch and does not have to agree.
Full Explanation
OSPF hellos carry an options field that includes the stub flag for the area. Both neighbors must agree on that flag or they refuse the adjacency, even when the area number, the IP MTU, and the hello and dead intervals already match. The retailer link is exactly that case: one side treats the area as stub and the other does not, so the neighbor never forms. The process tag only names the local OSPF process. Neighbors do not compare it, and making the tags equal would not clear a stub mismatch. A passive interface suppresses hellos on that port. It does not form an adjacency that somehow skips the database exchange, and this pair is already exchanging hellos, so the port is not passive. Router IDs are supposed to be unique. Matching them on purpose causes unstable LSA ownership and is not a prerequisite for leaving the Down state, in a stub area or otherwise. Caveat: a totally stubby area and a plain stub area also disagree in the options field, so both sides need the same area type, not merely the word stub somewhere in the configuration. Operational check: compare the area type on both switches, make them match, and confirm the neighbor reaches the full state.