Routed IPSEC Question

What should be used for the Transit network IP's? Should each P2 have it's own subnet? Should the same /30 network be used for the local and remote?
My goal here is to join ~15 sites with routed IPSEC and OSPF but i'm getting inconsistent results with OSPF. It will work for one site and not another. I believe it has to do with my P2 network settings but i cannot say for sure because static routes to those same interfaces work.
Thank you

Setup seems fairly forward and I was able to get it working on a few sites. Even with identical settings (different transport subnets of course) some sites will not get neighbor information. I listed some errors below that appear in some of the systems that aren't working.
Creating static routes on the tunnels does work and I am using that in the meantime until I can figure out what is wrong with OSPF (or my settings). I did try both FFR and Quagga, i got a few up with quagga last night but nothing since then.
Thank you

I have FRR OSPF running on top of IPSEC VTI.. The only issue i see is FRR OSPF is seeing the ipsec vti interface as un-numbered, so none of the /30s of the tunnels get re-distributed.

FRR does the same with point-to-point OpenVPN interfaces.

In a way it's better than quagga because that means you don't have to worry about learning a route for your own /30 address via some other OSPF path, but at the same time it means traffic between the endpoints won't route more than one hop away easily.

In a way it's better than quagga because that means you don't have to worry about learning a route for your own /30 address via some other OSPF path, but at the same time it means traffic between the endpoints won't route more than one hop away easily.

Yeah i could see that, but it would be shocking if a connected route got removed for a OSPF route. The only reason i even notice this is because without the /30 being re-distributed traceroute is broken. Regardless works pretty well for my limited testing.

Yeah i could see that, but it would be shocking if a connected route got removed for a OSPF route. The only reason i even notice this is because without the /30 being re-distributed traceroute is broken. Regardless works pretty well for my limited testing.

It happened all the time with multi-WAN OpenVPN configs in the past. The route would get stuck in the table if an OpenVPN instance went down and then you'd have to manually remove the route to bring it back. We worked around it a few different ways, but it was always annoying.

My issues were related to the transport network. It seems regardless of the transport network's mask (we tested with /30) it treated it like a /24. Once we moved to using a separate full 24 for each IPSEC tunnel OSPF came right up.