FRR-OSPF Not routing via IPSec VTI
-
If this has already been asked and answered, please forgive me for not being able to find it - I did look; please direct me to the answer.
Here's the issue I'm facing - attempting to setup OSPF between five (5) sites each with 15 VLANs:
Sites 1-thru-4 are running the latest PFSense CE on bare-metal, site 5 runs the latest (NON-RC) PFsense+ on an Azure VM. Sites 1 and 2 are currently spun up in bare metal, sites 3 and 4 are still awaiting parts (the chip shortage is real)...
Each site connects to site 5 via a single ROUTED IPSec VTI in a /30 on a site-specific 172.18.x.y/30 pair where the remote Azure VM site is 172.18.x.1/30 and the local bare metal site is 172.18.x.2/30.
Static routing works great in this hub & spoke configuration. However, due to the shear number of static route entries that would have to be manually updated with site adds (about 15 additional sites with 15VLANs each are expected in the next 6-months), I would like to go with dynamic routing.
In FRR-OSPF, I have setup the backbone area (0.0.0.0) containing the IPSec VTI interfaces, I have setup local site-specific stub areas for each site containing all site-internal interfaces, I have setup unique routed naming using the IP address of the internal LAN interface at each site...
In both OSPF Routes, I'm seeing that the routes are being properly advertised:
Azure-VM (PFsense+):
Bare-Metal (PFSense CE):
However, the routers can not PING each other nor can they PING any of the hosts behind them. The routers' routes tables are also not being updated to reflect the changes.
Any help on where to go next would be greatly appreciated - it has been almost 2-decades since I have even looked at dynamic routing so I know I've probably missed something simple somewhere - I just have no clue where.
-
@jcook-atlas BUMP
-
@jcook-atlas so I think in a hub and spoke topology with OSPF I think the issue here might be incorrect nexthops? I would check that.
But if this were me I would do BGP. Specifically iBGP with your hub acting as a route reflector. If that won’t work then eBGP.
That’s more of a typical design than using ospf -
@jcook-atlas I don't know if you've moved on from this to BGP like someone else suggested, but I think your issue may just be a typo. You have 172.18.2. on one side and 178.18.2. on the other.