Deprecated: Hook custom_css_loaded is deprecated since version jetpack-13.5! Use WordPress Custom CSS instead. Jetpack no longer supports Custom CSS. Read the documentation to learn how to apply custom styles to your site: in /var/www/ on line 6031
OSPF Loop prevention –

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 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 detail    

    OSPF database, Area
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len 
Summary *        0x80000001  1074  0x22 0xa365  28    <---Advertised from J32 (higher metric)
  Topology default (ID 0) -> Metric: 50                                         
Summary        0x80000019    13  0x22 0xe809  28    <---Advertised from J40 (lower metric)
  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 table inet.0 

inet.0: 39 destinations, 41 routes (39 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both      *[OSPF/10] 00:26:36, metric 50        <---router which has higher metric (50) is installed
                    > to 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.

About: rtoodtoo

Worked for more than 10 years as a Network/Support Engineer and also interested in Python, Linux, Security and SD-WAN // JNCIE-SEC #223 / RHCE / PCNSE

You have a feedback?

Discover more from

Subscribe now to keep reading and get access to the full archive.

Continue reading