OSPF equal cost path

On this post, I will try to show how OSPF behaves when there are two equal cost paths towards a destination. To demonstrate this, I have prepared my usual topology.

ospf-equal-cost-path-junos

On this topology all routers are running OSPF but our focus is on the router J32 which is circled at the bottom and our destination network is 172.40.1.0/24 Since we have set the reference bandwidth to 10G and each links are 1G a single link OSPF cost is 10. Now let’s see how J32 device reaches this destination network.

root@J32> show route 172.40.1.0/24 table inet.0    

inet.0: 38 destinations, 39 routes (38 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

172.40.1.0/24      *[OSPF/10] 00:00:15, metric 40
                      to 10.194.194.2 via ge-0/0/0.194
                    > to 192.168.195.1 via ge-0/0/0.195  <--- Active next hop

We can see that metric towards this destination is 40 and OSPF lists both routes but are we really using them? Let’s check the forwarding table. The important thing here is also that if one of the path’s metric was higher, we wouldn’t see it here in the list. We only see the paths if they have equal paths.

root@J32> show route forwarding-table destination 172.40.1.0/24 table default    
Routing table: default.inet
Internet:
Destination        Type RtRef Next hop           Type Index NhRef Netif
172.40.1.0/24      user     0 192.168.195.1      ucst   631     7 ge-0/0/0.195 <--Only one next hop

Nope! we don’t install both next hops but only one. This is something we can manipulate.

First we create a policy for load balancing and then export it into the forwarding table as below.

set policy-options policy-statement lb-ospf from protocol ospf
set policy-options policy-statement lb-ospf then load-balance per-packet
set routing-options forwarding-table export lb-ospf

Once we commit the changes, we check the forwarding table again.

root@J32> show route forwarding-table destination 172.40.1.0/24 table default    
Routing table: default.inet
Internet:
Destination        Type RtRef Next hop           Type Index NhRef Netif
172.40.1.0/24      user     0                    ulst 262142     6
                              10.194.194.2       ucst   632    15 ge-0/0/0.194 <--Next Hop 1
                              192.168.195.1      ucst   631     7 ge-0/0/0.195 <--Next Hop 2

Bingo! we have installed both next hops on the forwarding table which actually means J32 router should load balance the flows towards this destination. How the load balancing algorithm works is out of the scope of this post.

Now we will play a bit with the cost of the links to demonstrate that OSPF installs only the best path.

I am just increasing the metric to 20 from 10 which should make the total cost equal to 50 on the north PATH#1

[edit protocols ospf area 0.0.0.0]
root@J29# set interface ge-0/0/0.196 metric 20 

and then we check the routing table on J32 once again and see that 192.168.195.1 next hop disappeared as it has a higher metric (more cost)

root@J32> show route 172.40.1.0/24 table inet.0    

inet.0: 38 destinations, 39 routes (38 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

172.40.1.0/24      *[OSPF/10] 00:00:03, metric 40
                    > to 10.194.194.2 via ge-0/0/0.194

I hope this was an informative post!

About: rtoodtoo

Genco has worked for more than 10 years as a Network/Support Engineer. He is also interested in Python, Linux, Security and SD-WAN, currently lives in the Netherlands and works as a Network Support Engineer at Tesla Inc. // JNCIE-SEC #223 / RHCE / PCNSE


You have a feedback?

This site uses Akismet to reduce spam. Learn how your comment data is processed.