SRX

Background

I know that you can configure an OSPF area as stub to prevent the flooding of Type 5 LSAs, and that if you use the default-metric option the ABR will generate a Type 3 LSA 0.0.0.0 that can serve as a default route to other routers in the stub area.

I have this OSPF configuration on a clustered pair of SRX240H devices running Junos 11.4:

area 0.0.0.1 {
  stub default-metric 1;
  area-range 172.25.128.0/23;
  interface reth0.0 {
    priority 128;
  }
}
area 0.0.0.0 {
  area-range 172.24.130.0/24;
  area-range 172.24.128.0/23;
  interface st0.0 {
    metric 5;
  }
  interface st0.1 {
    metric 10;
  }
}

The other router in area 1 is a Force10 Layer 3 switch. I had an issue a week ago where the SRX240s lost connectivity back to the other routers in area 0 (they are connected via the st0.0 and st0.1 interfaces, which are IPsec tunnels). When they lost connectivity, the default route the SRX240s had been flooding into area 1 was removed from the OSPF database, and all the clients connected to the Force10 switch lost connectivity to the Internet. It's worth mentioning that throughout all this the SRX240s are not just an ABR in my OSPF design, but are also ASBR, as they also have a default route installed pointing to an upstream ISP.

Question

Is it necessary for an OSPF stub area to maintain connectivity to area 0 in order for the ABR router to generate a default route? If so, is there a better design that will allow what are effectively two sites to maintain independent connections to upstream ISPs, but also exchange routes and network information over a point-to-point connection between the sites (which were IPsec tunnels in this case)?

Hello,

"Active backbone detection" is on by default.

http://www.juniper.net/techpubs/en_US/junos13.3/topics/concept/ospf-areas-overview.html

Junos OS supports active backbone detection. Active backbone detection is implemented to verify that ABRs are connected to the backbone. If the connection to the backbone area is lost, then the routing device’s default metric is not advertised, effectively rerouting traffic through another ABR with a valid connection to the backbone.

You can turn it off with

[edit]
aarseniev@router# set protocols ospf no-active-backbone 

 NOTE: "no-active-backbone" knob is hidden, please type it in full.

HTH

Thanks
Alex

Thank you! I labbed this and confirmed that it will keep the Type 3 LSA 0.0.0.0 flooding into the stub area if the ABR looses its connection to the area 0 backbone.