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?
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
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
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.
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 nextend 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 nextend 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.htmlhttp://socpuppet.blogspot.com/2015/03/route-tagging-ospf-fortigates.html ken
PCNSE
NSE
StrongSwan
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?
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
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.
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1517 | |
1013 | |
749 | |
443 | |
209 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.