OSPF and PBR?

Question

Hi,

I am trying to setup OSPF and PBR between 2 Fortigate but I always end up with a "reverse path fail error" when I enable my PBR rule. Here is what I am trying to achieve:

The client has 2 sites (let's call them SITE1 and SITE2) linked by two different links. One link is a best effort 1Gbps link (LINK1) and the other one is a low latency guaranteed 300Mbps link (LINK2).

OSPF is working between both site and cost has been manipulated to make sure that the preferred route is on LINK1. Should LINK1 stop working, route on LINK2 comes up and everything goes through that link, which is fine.

We are only trying to manipulate one type of communication, VoIP, which has its own dedicated subnet. The client wants to primarily use LINK2, even if LINK1 is up. So, I created one PBR in each site that look like this:

SITE1: From VOIP_SUBNET_SITE1 to VOIP_SUBNET_SITE2, use interface LINK2 and according gateway

SITE2: From VOIP_SUBNET_SITE2 to VOIP_SUBNET_SITE1, use interface LINK2 and according gateway

Problem is, as soon as I bring the PBR route up on both side, the VoIP subnet stop talking to each other.

If I do a traceroute, I can see the packet being sent correctly on LINK2 but no answer comes back. If I try from SITE1 to SITE2, the packet goes through the Fortigate in SITE1 as it should and is sent to SITE2 where it is received. There, the Fortigate drops the packet saying that "reverse path check fail, drop", as if it had no route for the source address of the packet. Problem is, there is a route from OSPF (using LINK1) and another route from PBR (using LINK2).

What is even more weird is that, if I do the same from SITE2 to SITE1, using the exact same IP address (but reversed), the packets actually pass through the Fortigate in SITE2 (the same one complaining about a reverse path check failing) and is send to SITE1, where the same problem occurs (even if in the previous test it was able to send packet!).

Another test I did was to disable my PBR route. Then, my packet are passing without any trouble between the two site using the exact same IP addresses but on LINK1 instead of LINK2. Then, I went ahead and disabled LINK1 completely, forcing all traffic to use LINK2. Again, everything work as it should, my VoIP test packet using the same IP addresses as previously pass through without any trouble, using LINK2.

So, from what I have read, I shouldn't be a problem to manipulate route using PBR on top of OSPF. But I can't get it to work.

Any idea?

Toshi_Esumi · Answer

Your problem is the returning route for the source subnet doesn't exist toward LINK2 on both sides. They have only the OSPF route toward LINK1, resulting in "reverse path check fail".

If you want to use PBR to get your desired outcome, override the OSPF route with two same static routes, one to LINK1 and another to LINK2 so that you can avoid "reverse...fail". Then the PBR can decide which direction to go to (LINK2).

Still, an expected problem with your setup is when LINK2 goes down, VoIP goes down as well. Because PBRs don't go away in that situation.

For that reason, as well as limited capability to manipulates routes with OSPF, we regularly use BGP (your case it doesn't matter eBGP or iBGP because only one set of peers) without PBRs in similar situations, so that you can set a higher local-pref for the VoIP prefix toward LINK2 (or lower local-pref on LINK1) while all other routes have a higher local-pref toward LINK1 (or lower local-pref on LINK2). With this way when LINK1 goes down, the traffic regularly goes to LINK1 fails over to LINK2, and the same works when LINK2 goes down for the VoIP traffic to fail over to LINK1.

Sign up

Login with SSO

Login to the community

Login with SSO