Juniper OSPF and Unexpected Features

I had an interesting situation in a lab environment the other day. It seems Juniper has been tweaking how OSPF works with their routers with some interesting consequences.

Here’s the layout of the test network:

Juniper OSPF Lab Network

 
All pretty simple and straightforward. R1 is the Area 0, or backbone, router. R2 is the ABR, and R3 is in a stub area. R2 will advertise the default route 0.0.0.0/0 into Area 1 which appears on R3:

 
So there’s the stub area summary route and all is fine. Now, here’s a question for the experts : what happens on R3 if the interface on R1 goes down? – Nothing, right? Well, let’s try it and take a look:

 
And now we wait for a minute and take another look at R3:

 
Uhhh, wait a minute. Where did my default route go? R3 can’t reach stuff outside of Area 1 – not even R2’s interface in Area 0 – 10.20.130.2. What’s going on here?

It turns out that this is a feature from Juniper called Active Backbone Detection. It’s reasoning is that if the Area Border Router ( ABR – R2 here ) loses it’s connectivity into the backbone Area 0 then it will drop it’s summary route into any Stub or NSSA areas. This can be a little bit disturbing and quite surprising if you’re not ready for it.

In some circumstances, this might be useful. If there is two ABRs into the stub area, and one loses it’s connection into the backbone, then you will probably want it to stop advertising it’s default route. Something like this:

Two ABRs connecting the stubby Area 1 to the backbone

 
In this case, backbone detection will be useful – otherwise you’ll need to do some other shenanigans to keep everything working if an ABR loses it’s backbone connection.

The other way around the problem is to apply an undocumented command on R2 to disable the backbone detection mechanism:

 
Notice how Junos wouldn’t do auto completion for the option. It’s really not documented. Now let’s check what R3 thinks of this:

 
Great! problem solved.

Now go back to work.