OSPF Loop prevention

On this post, I will show an example of loop prevention on OSPF protocol. There is a nice document at here about the principles of loop prevention. What I will just do is to show this on Junos. In order to show this, I am using the following topology;

On this topology, J40 and J32 are ABRs. J40 has a connection to Area3 in broadcast segment and J32 also has a link to Area3 via J201. It looks like we have multiple paths towards the same Area3 from backbone area. Let’s see how OSPF handles this.

We have a network range 172.40.1.0/24 on area0 and it is summarized into area3. When we check LSDB for this network, we see that we have received two LSA(5) for this.\\
Note: You don’t see this network on the topology as it is a bit big and didn’t want to put the big topology for simplicity.

root@J32> show ospf database netsummary lsa-id 172.40.1.0 detail    

    OSPF database, Area 0.0.0.3
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len 
Summary *172.40.1.0       10.1.1.32        0x80000001  1074  0x22 0xa365  28    <---Advertised from J32 (higher metric)
  mask 255.255.255.0
  Topology default (ID 0) -> Metric: 50                                         
Summary  172.40.1.0       10.1.1.40        0x80000019    13  0x22 0xe809  28    <---Advertised from J40 (lower metric)
  mask 255.255.255.0
  Topology default (ID 0) -> Metric: 41

This is because we have multiple links from Area0 to Area3. As far as the protocol is concerned(as explained on the document I referenced) ABR expects summary LSAs from Area0 only. If it ever receives a summary LSA from a non-backbone area, LSAs will be in the database but won’t be used on calculation.

We can prove the above statement by the following command.

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

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

172.40.1.0/24      *[OSPF/10] 00:26:36, metric 50        <---router which has higher metric (50) is installed
                    > to 10.194.194.2 via ge-0/0/0.194

What we see is that although the path from J40 has a lower metric(41), J32 doesn’t use that route.

I also did a test and I broke the adjacency of J32 with backbone area0 after which route from J40 is installed which also confirms the statement.

During my tests, I got conflicting results which confused me a bit. If I notice later that what I have written is incorrect or anyone finds it odd, please let me know so that I can correct it.