OSPF with two connections between the same 2 routers Q

OSPF question:

Topology:

  1. Primary area border router (in area 0 AND NSSA area 50)
  2. Primary link from #1 to #4 is a P2P pair of radios
  3. Secondary link from #1 to #4 is another P2P pair of radios
  4. Leaf router in NSSA area 50

So there are TWO separate OSPF sessions, one over each P2P radio link.

OSPF cost is set so the primary link is preferred.

All works well. If secondary link drops, things still work well.

If primary link drops, hwoever, the OSPF link-state database gets confused. It thinks that the primary link is STILL UP (because the ethernet interfaces to the local P2P radios ARE still up) even though the OSPF session drops (dead timer expires).

QUESTION: How do I avoid this? How can I convince the OSPF process that the link state should be updated to match the OSPF session state over the primary link?

I do NOT want to use scripting to monitor (via ping) and drop the interface states. I know I can do that. But that has drawbacks too (like having to periodically re-enable the interface to test the P2P radio link state–unless I use the backup link to communicate and tell the far side to disable/enable the interface there).

Thanks!

-Aaron out.

Something about this just feels wrong.
OSPF would definitely not use the dead link just because the physical interface is not down.
The dead link should be removed from the topology on both sides once the keepalive timer expires w/o receiving a HELLO from the other side.

I’m going to assume that you’ve verified that the link failure is bi-directional… if it’s a unidirectional failure, then hellos in the direction that still works will keep the far side thinking the session is alive

Are the two P2P links configured with separate CIDR ranges? (i.e. they’re not both in a common /24)
Are the two P2P links connected into bridges? (that would definitely mess you up, especially if you’re not running STP)

You should have a /30 subnet on each link, and each link should be an isolated layer 2 broadcast domain.

Have you tried changing the metrics so the primary/backup roles are reversed, and then testing to see if the same behavior happens when link B fails as the primary?