Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
kalto
New Contributor

OSPF and PBR?

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?

3 REPLIES 3
Toshi_Esumi
Esteemed Contributor III

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.

emnoc
Esteemed Contributor III

Agreed, we do not use PBR for this. I believe you might be able to set tag and metric on site1/site2 if these networks are E types. Here you could adust the metric per route and with the link cost maybe you achieve with your want.

 

You could maybe even change the distribute admin cost, but again you have to test it. PBR is not the way to go here. use the inherit metric of the dynamic-routing

 

i.e ( ospf tag  for VoIP subnets with a tag 67890 ) 

 

config rule

    edit 1

        set match-interface "wan2"

        set match-tag 67890

        set set-metric 34000

    next

    

   edit 2

        set match-interface "wan1"

        set match-tag 67890

        set set-metric 1000

    next

end

 

 

So you would set a tag at redistribution for VOIP subnets { 67890 in my example )  and then on whatever interface that you do not want that route preferred you adjust the metric to be less favorable.You have to do it both ways which is what Toshi was hinting towards to ensure "uRPF" do not fail nor asymmetrical routing issues.

 

Reference an example in my blog 

 

http://socpuppet.blogspot.com/2015/03/route-tagging-ospf-fortigates.html

 

BGP would be even easier with local_pref, but you do not need to re-architect your design. Just use tags and routes adjustments per tags. So link1 & 2 are actively used, but failover when the one primary path is down. Report back if this works out for you so others can find this post.

 

Thanks

 

Ken Felix

 

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
emnoc
Esteemed Contributor III

Here's a cfg 

 

config router route-map

    edit "matchtag"

        config rule

            edit 1

                set match-interface "wan1"

                set match-tag 3490

                set set-metric 34000

            next

            edit 2

                set match-interface "wan2"

                set match-tag 3490

                set set-metric 1000

            next

        end

    next

end

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
Labels
Top Kudoed Authors