OpenVPN + OSPF Equal Cost Paths

gdi2k

We have a number of sites that we have interconnected with site to site openvpn links, and we're using FRR OSPF to optimize routing and provide failover routes when WAN links go down etc.

It all works fine on the whole, but if two paths are of equal cost, the affected link fails. For example:

N 192.168.12.0/24 [130] area: 0.0.0.0
via 10.32.120.1, ovpnc2
via 10.32.164.1, ovpnc1

In this case, the path cost via ovpnc2 and ovpnc1 are identical (130), and connectivity between the local LAN and 192.168.12.0/24 is broken.

Does anyone know what causes this, and how to fix it?

jimp

Current releases do not support multi-path routing/ECMP, so I'm not sure what it might be trying to do there.

Just yesterday we enabled RADIX_MPATH in snapshot kernels and multipath support in FRR, so you might give a 2.5.0 snapshot a try once that's built in.

mi8088

Just saw this after posting my thread - missed it before. Find it here

I have a similar problem, am not running OpenVPN though (IPSec).

If you enable firewall logging or packet capture, you might be able to see if your reply traffic is taking the other way back - which doesn't work very well.

jimp

If you change your state type to Sloppy on the rules it may help there, though you might need some additional floating rules. Similar to other asymmetric routing issues but not quite so bad since pfSense sees all packets, just not on the same interfaces.

gdi2k

Many thanks for the replies here. For now I've bodged things so that it's mathematically unlikely that two paths will end up with the same cost, but looking forward to trying out multipath support in FRR when it becomes more available / stable.

mi8088 - I haven't actually taken a look at the packet captures yet, but yes, I imagine you're right that the return traffic is coming back via a different path.

mi8088

@jimp
I've been testing my setup in 2.5.0, but have the same issues still. Do I have to enable the multipath support somehow?

bbrendon

@gdi2k
We deployed VTI+FRR (2.4.4p3) and that was a disaster. We're thinking about trying OpenVPN+FRR. Do you know if this issue is resolved in the newer (v0.6.3_1) versions of FRR?