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

OSPF inbound route filtering with route-map - adjusting metric

Hi all,

 

Im having a hard time changing the OSPF metric from 10 to 20 on some of the routes below in my Hubs routing table, i require ECMP for my SDWAN to work properly on my Hub.

 

My routes of interest are as follows:

 

O E2 192.168.2.0/24 [110/10] via 10.10.10.2, WAN1ADVPN_0, 00:00:08                                [110/10] via 20.20.20.2, MPLSADVPN_0, 00:00:08 O E2 192.168.3.0/24 [110/10] via 10.10.10.3, WAN1ADVPN_1, 00:00:08                                [110/10] via 20.20.20.3, MPLSADVPN_1, 00:00:08

 

Basically i have 4 OSPF neighbours, two of which hare advertising the same connected network just over different WAN links, i need to change the metric of the networks learnt over the MPLSADVPN VPN's to 20 rather than the default of 10.

 

so i have created two ACL's and applied them to a route map.

 

config router access-list

edit "nxthop" config rule edit 1 set prefix 20.20.20.0 255.255.255.0 set exact-match enable next end next edit "any" config rule edit 1

set prefix any set exact-match disable next end

 

config router route-map

edit "metric" config rule edit 1 set match-ip-nexthop "nxthop" set set-metric 20 next edit 2 set match-ip-address "any" next end

 

config router ospf set distribute-route-map-in "metric"

 

However as you can see it had no effect on the metric, the idea is that the match-ip-next hop should match any routes with next hops in the 20.20.20.0/24 network, so both the below in bold and change the metric to 20:

 

O E2 192.168.2.0/24 [110/10] via 10.10.10.2, WAN1ADVPN_0, 00:00:08                                [110/10] via 20.20.20.2, MPLSADVPN_0, 00:00:08 O E2 192.168.3.0/24 [110/10] via 10.10.10.3, WAN1ADVPN_1, 00:00:08                                [110/10] via 20.20.20.3, MPLSADVPN_1, 00:00:08

 

Can anyone see what the issue is?

 

6 REPLIES 6
emnoc
Esteemed Contributor III

Can you set the route redistributed as E1 for the path you want? E1 will always be selected over E2 routes for the injection via ASBR  and with metric+forward-metric

 

Ken

 

 

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
ericli_FTNT
Staff
Staff

Hi there,

 

OSPF is not a distance-vector routing protocol so its path selection algorithm is not based on metric but on link cost.

 

The number "10" is the cost instead of metric.

 

For changing cost, you can configure it on OSPF interface configuration.

 

Let me know if you have any question on it.

emnoc
Esteemed Contributor III

Doing it by interface would work but it will impact all routes. Since the goal is the E2 pushed outside of the ospf.domain  it would more easier to impact the metric and metric-type at the redist.static

 

 

 

 

    

config router route-map

    edit "ST2OSPF"

        config rule

            edit 1

                set set-metric 200

                set set-tag 88

            next

        end

    next

end

 

config redistribute "static"

    set status enable

    set metric 200

    set routemap 'ST2OSPF2'

    set metric-type 1

 end

 

 

That should  do it along with no  impact to  ALL routes  for OSPF, just Ext-Types. Doing the follow impacts ALL ospf  routes type which might not be  wanted or have other impacts ;

 

config ospf-interface

    edit "internal"

        set cost 20

    next

end

 

just my 2ct

 

Take this blog where we want to  modify and impact on one E2, I could  easily have done the same using a  route-map with a access-list and modify that one prefix or change it's OSPF type or metric,etc.....

 

Here's just a few methods and with  working snapshots from myself

 

http://socpuppet.blogspot.com/2015/03/ospf-e2-route-filter-fortigate.html

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

 

 

ken

 

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
Mattmans1

Hi.

 

Thanks for your input, its a good point Eric, i guess if i could cost them as below, then it would not be equal cost and the routes with the cost of 20 would disappear, what i want to achieve is a routing table that looks like this.

 

Current Hub routing table:

 

O E2 192.168.2.0/24 [110/10] via 10.10.10.2, WAN1ADVPN_0, 00:00:08                                [110/10] via 20.20.20.2, MPLSADVPN_0, 00:00:08 O E2 192.168.3.0/24 [110/10] via 10.10.10.3, WAN1ADVPN_1, 00:00:08                                [110/10] via 20.20.20.3, MPLSADVPN_1, 00:00:08

 

 Desired Hub Routing Table:

 

O E2 192.168.2.0/24 [110/10] via 10.10.10.2, WAN1ADVPN_0, 00:00:08                                [110/20] via 20.20.20.2, MPLSADVPN_0, 00:00:08 O E2 192.168.3.0/24 [110/10] via 10.10.10.3, WAN1ADVPN_1, 00:00:08                                [110/20] via 20.20.20.3, MPLSADVPN_1, 00:00:08

 

Much like you could using ECMP using the priority with the static routes, i need all these routes in the table for my SDWAN to work on my hub (health checks for a start) - but its more for the ADVPN i have running over the top i need to ensure the shortcut message returns down the primary WAN1ADVPN path.  It works most of the time but not always, sometimes it comes back via MPLSADVPN.  Its a Hub with two spokes, each spoke has dual WAN's, thus the hub learns about 192.168.2/3 networks from with spoke WAN OSPF adjacencys's.

 

I attempted to use statics as per below, even though these are dialup VPN's with the add-route disabled, but is does not work as the next hops are wrong as below and you cant set the gateway manually.

 

Hub routing table with statics added instead:

 

O E2 192.168.2.0/24   [110/10] via 10.10.10.2, WAN1ADVPN_0, 13:09:00                 <spoke A                                   [110/10] via 20.20.20.2, MPLSADVPN_0, 13:09:00                 <spoke A S 192.168.3.0/24      [110/0] via 20.20.20.254, MPLSADVPN, [10/0]               <spoke B                                    [110/0] via 10.10.10.254, WAN1ADVPN, [20/0]              < Spoke B

 

Ken - thanks for your example i think though if i did that it would change the metric/cost to 200 for all routes learnt from both adjacencys, i need only one adjacency to change the metric per network as per my desired routing table at the top.  

 

Any ideas how to accomplish the desired outcome anyone?

 

 

Mattmans1
New Contributor

Thanks guys for the replies.  I think  a diagram may have helped to understand this scenario better.  I got this working but i had to redesign the whole thing.

 

using the below example i have modified it.

 

http://cookbook.fortinet.com/client-side-sd-wan-ipsec-vpn-deployment-example-expert/

 

Instead of using DC1 and DC2 firewalls i created these as vdoms on my Hub, terminated the ADVPN clouds on the INET and MPLS vdoms respectively, using IBGP on each and using BGP local pref on the INET hub VDOM to favour it over the MPLS cloud, then using intervdom links to the root and two EBGP connections with EBGP multi-path over the intervdom links redistributing the DC networks from the root to the other vdoms.  This way the ADVPN routes and SDWAN do not interfere with each others functionality like it does in a single routing table.

 

This works well there is no single point of failure, i got the idea from the below post.

 

https://fusecommunity.fortinet.com/p/fo/et/thread=8770

 

ericli_FTNT

Mattmans1 wrote:

Thanks guys for the replies.  I think  a diagram may have helped to understand this scenario better.  I got this working but i had to redesign the whole thing.

 

using the below example i have modified it.

 

http://cookbook.fortinet.com/client-side-sd-wan-ipsec-vpn-deployment-example-expert/

 

Instead of using DC1 and DC2 firewalls i created these as vdoms on my Hub, terminated the ADVPN clouds on the INET and MPLS vdoms respectively, using IBGP on each and using BGP local pref on the INET hub VDOM to favour it over the MPLS cloud, then using intervdom links to the root and two EBGP connections with EBGP multi-path over the intervdom links redistributing the DC networks from the root to the other vdoms.  This way the ADVPN routes and SDWAN do not interfere with each others functionality like it does in a single routing table.

 

This works well there is no single point of failure, i got the idea from the below post.

 

https://fusecommunity.fortinet.com/p/fo/et/thread=8770

 

On Fortigate, I suggest, to deploy OSPF only for connectivity, not for route selection.

 

If you need to implement route selection, use iBGP.

 

Cause those tools like metric, next hop, ... could only work on BGP, not OSPF.

 

That's it.

Labels
Top Kudoed Authors