This post is inspired by a discussion at Twitter with Ivan Pepelnjak and
Nicolas Michel. Nicolas asked what happens when there is the same route from two
different OSPF processes. Which one will be selected? Ivan explained how
to use the distance command. First before I show how it works and why we
need to get some few basic concepts explained.

LSDB – Link State Database – All OSPF LSAs populate the LSDB
RIB – Routing Information Base – The best routes from every protocol
compete to get installed to the RIB
FIB – Forwarding Information Base – Routes are copied from the RIB
and used for forwarding (CEF)
CEF – Cisco Express Forwarding – The algorithm that Cisco uses for
the forwarding (FIB)

If we have for example OSPF, this is how a route gets selected to the RIB(global).
The routers exchange LSAs with each other. Within an area every router has the same
view of the network. These LSAs populate the LSDB. If there are multiple paths to
a destination they will compete with each other unless they are of same type and equal
cost. Intra area is preferred first, then inter and finally external routes. There is no
way of modifying this behaviour. The best route then goes to the OSPF RIB, could be several
if they are equal. From there this route will compete with other routing protocols and the
AD will decide which one is installed. If the OSPF one is best then that one goes to the global
RIB. Then finally the RIB populates FIB with this information and forwarding can ensue.

This is a picture I made that describes the process.


We start out with a very basic topology looking like this.


R1 and R3 will announce the same network R2 will use two different OSPF processes.
We start out with the basic configuration:



We see the session coming up immediately. Now lets bring up R3 as well.


Both OSPF peerings are up. Now lets follow the steps that was shown in
the picture above starting by looking at the database.

We see that R1 is announcing and we have a metric of 2 to it.
Do we see R3 announcing that as well?

Yes, it’s there. Now we take a look at the OSPF RIB. Which ones do we see there?

The greater than sign indicates that the one from OSPF process 1 was selected.
Why? When running multiple OSPF processes the one that first installs to the
RIB will be selected to the global RIB. Now we confirm by looking in the
global RIB.

Yes, that looks correct. Final step is to verify that FIB is also updated.

So the one that first writes to the global RIB wins. Now lets bring down the
process that is currently winning.

The OSPF RIB and global RIB should now be updated.

Now if we bring back OSPF process 1, what will happen? Process 3 should still be
winning since it installed to global RIB first.

Now process 1 is winning, which is odd. Lets debug ip routing to see what is
really happening. We shutdown interface in process 1.

Now we bring back process 1.

We can see that IOS is claiming that distance is lower which it is clearly not.
What happens if we change process 1 to process 11 and we shutdown the interface
in process 3?

Now we look at the output from the debug.

We can see that first process 11 is the only option available so the
route is installed via f1/0. Then f1/1 comes back up and now is reachable
via f1/1 and is chosen because of “closer admin distance” which is not true. This must
mean that the OSPF process number is the tie breaker.

We take a look at the OSPF RIB and global RIB to verify once more.

What if we change the AD of process 11?

That makes process 11 win again. So these tests seems to indicate that if everything
is the same then the tiebreaker is the lowest process number. For EIGRP it is the
lowest AS number so maybe Cisco chose to make it comparable.
Also take a look at what Ivan is saying at IOS hints

Tiebreakers with routes from different OSPF processes
Tagged on:                 

18 thoughts on “Tiebreakers with routes from different OSPF processes

  • March 16, 2013 at 4:12 pm

    I was under the impression that there was just one RIB. This was confirmed by this post: Now I see “OSPF local RIB” in the output of sh ip ospf rib.

    I know it’s just semantics after all, but I admit I’m confused. 🙂

    • March 16, 2013 at 10:59 pm

      I’ve looked at it as a RIB and that’s how it was described to me but I could be wrong. I’ll have to look into it some more. I’ll get back to you.

      • March 17, 2013 at 11:22 am

        Actually the “show ip ospf rib” will show the routes submitted to the RIB process by OSPF. The RIB process is a complex system. The most common part of the system is a “cache” that store routing informations and it is called Routing table. Others include Route selection process, APIs that interface with other process like OSPF & BGP, redistribution process, data structures like prefix,path and interface descriptor.

        The RIB system main functions is to interface to different routing information sources, receive the information, select the “best” one, store it in the routing table cache, feed the forwarding process’ cache(FIB) and maintain/verify the routing table entries with both event & periodically driven algorithms.

        Since in the above scenario there are two OSPF processes, each will interface with the RIB process using different APIs and thus they will be treated as different routing information sources by the RIB. It is the “Route selection” process, part of the RIB process, that will determine which one to use. Most often it will determine this by using AD value submitted by the routing information source ( routing protocol, in this case)

  • March 16, 2013 at 4:56 pm

    Hi Daniel,

    Very nice experiment.

    I’m not sure which IOS version you used, but I think you have run into a “bug” as mentioned in this site:

    “Before Cisco bug ID CSCdw10987 (registered customers only) (integrated in Cisco IOS Software Releases 12.2(07.04)S, 12.2(07.04)T, and later), the last process to make an shortest path first algorithm (SPF) would have won, and the two processes overwrite other routes in the routing table.”

    I think you were shutting down the interface for the “lower” OSPF process every time, making it the last process to run SPF when you bring the interface up and overwrite the other process’ entries.

    I have recreated your scenario using 12.4(15)T and the result is that the first OSPF process that installed the entry will always win in accordance to the above Cisco’s site.

    • March 16, 2013 at 11:01 pm

      I tested it on 15.2 something. I’ll try to recreate it but configure the process with the higher ID first.

  • March 17, 2013 at 3:14 pm

    What happens when you make the lower process submit an internal route with a high metric, and the second higher process submit an E2 route with a lower metric. 🙂

  • March 17, 2013 at 3:16 pm

    What happens when you make the lower process submit an internal route with a high metric, and the second higher process submit an E2 route with a lower metric 🙂

    • March 17, 2013 at 6:32 pm

      Even in this scenario, the first route to enter will still win the RIB route selection process. RIB will treat the two different OSPF processes as if they are from different routing protocol sources.

      Please check Alex Zinin’s bok chapter 4 routing table maintenance:

      ” c. If the AD values are equal but the routes are from different sources, the behavior depends on whether the routes are submitted by processes of the same type. If they are, the metrics of the routes are compared as if the routes were from the same protocol. If metrics are the same, the route from the process with the lower process number wins. If the routes are from different sources, the new route is ignored. (Note that this check is implemented for EIGRP routes only. All other routes are treated as from different protocols, so the old route is left in the routing table.) ”

      I wonder what is the reason behind the EIGRP exception, may be Cisco’s designers want to be unique for their own indigenous protocol?

  • March 17, 2013 at 7:37 pm

    I’ve just confirmed with 12.2 SRE (33) and I don’t see that. I get the same result as Daniel in that whatever process number on R1 is the lowest, will win. It doesn’t matter if I increase the metric to either of them, the lowest process still wins.

    The only time the lowest process doesn’t win, is when the lowest process number has an external route and the higher process number has an internal route, in that case the higher process wins.

    But if they both submit type5s or type1s, then the route form the lowest process will win, and even take over the route from the other.

    At least in the version I tested.

    • March 17, 2013 at 7:53 pm

      try to use higher IOS versions. I tested using 12.4(15)T and the oldest route won always. I didn’t test using internal/external routes, but I don’t think the route type can and should make any difference. In Daniel’s task, he always shutdown the interface with a lower process number, making it the last one to run the SPF when he brought back the interfaces.

      Alternatively, try to shut down the interfaces of both process consecutively and if both processes can overwrite each other’s route table entry, then the reported bug exists.

      • March 17, 2013 at 7:55 pm

        Both 15.2 and 12.2(33)SRE are both later versions that 12.4(15)T and show the ‘lowest process number wins’ behaviour

  • July 11, 2013 at 8:20 am

    HI Daniel,

    I’m using the version (Cisco IOS Software, 3600 Software (C3660-IS-M), Version 12.3(11)T2, RELEASE SOFTWARE (fc1)) in GNS3. When i try to use the command “show ip ospf rib” it’s saying command invalid.

    Please help me on this

    • July 11, 2013 at 8:22 am

      That’s a very old IOS. You should be using at least 12.4T. Try to use show ip ospf route instead.

      • July 16, 2013 at 8:05 am

        Hi Daniel,

        I tried with Both IOS versions (12.3 and 12.4) but neither supporting the command “sh ip ospf route” and “sh ip ospf rib”

  • July 15, 2013 at 8:31 am

    Thanks Daniel. Let me download and try it.

  • February 5, 2015 at 8:40 am

    Great blog Daniel. I originally thought it would have used the cost and was expecting loops but your blog & Ivan’s cleared it up.

    One interesting point is I got a GNS3 lab setup with CSR1k running IOS15.4(2)s. It would seem that Cisco has changed the way OSPF prefers path. OSPF now uses the lowest process ID as a tie-breaker like EIGRP.

    • October 11, 2016 at 10:25 pm

      I’ve experienced the same behaviour on VIRL with IOSv (version 15.6). I was trying to replicate the behaviour as seen in a video and noticed the difference.

      In VIRL at least the router (now) prefers the lowest process ID. I wonder if there’s any documentation to be found on this subject. So far I haven’t been able to find any.

  • February 5, 2015 at 8:59 am

    So it would seem like this is another possible means of stopping loops of forming although it would have almost zero use in Production environments as it would only stop loops from forming one way. I did test this by changing the process ID.


Leave a Reply

Your email address will not be published. Required fields are marked *

%d bloggers like this: