New Member

Question

OSPF inbound route filtering with route-map - adjusting metric

Forum|Forum|7 years ago
May 25, 2018
3 replies
12754 views

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?

emnoc

New Member

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

ericli_FTNT

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

New Member

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

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

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

Mattmans1Author

New Member

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?

Mattmans1Author

New Member

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

Staff

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.

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded