Default route not coming out of routing table in NSSA when link down

  • 0
  • 1
  • Problem
  • Updated 2 years ago
  • Solved
Hi, I have a problem with a re-distrubuted static route which I think I have nailed down to being a problem with the NSSA setting on the remote area.

We have the following topology;



There are point to point links between the CORE and WAN and also the WAN and REMOTE-SITE in their respective areas. Area 0.0.0.10 is set as an NSSA and area 0.0.0.0 as a normal area. On the core switch we issue command 
enable ospf originate-default cost 10 type ase-type-1
This then creates a default route in the WAN switch and a default route in the REMOTE-SITE switch. If I disable the link between the CORE and WAN switches the default route is removed from the WAN switch but the REMOTE-SITE retains its default route. 

My question is - why does the default route not come out of the REMOTE-SITE routing table when the link between the WAN and CORE dies. If I change area 0.0.0.10 to a Normal area the route does come out of the REMOTE-SITE table. 

We can resolve the problem we are having by changing the REMOTE-SITE to a normal area as it doesn't need to be an NSSA but I'd like to understand this behaviour.

Thanks All.
Photo of Leo

Leo

  • 112 Points 100 badge 2x thumb

Posted 2 years ago

  • 0
  • 1
Photo of Erik Auerswald

Erik Auerswald, Embassador

  • 13,498 Points 10k badge 2x thumb
Hi Leo,

an OSPF Stub area is supposed to have a default route pointing to the ABR. If you change the area to not be stub, this default route is removed. The stub functionality is implemented on the ABR. The behavior described by you seems normal to me.

If you do not want a default route pointing to the ABR, you do not want a stub area.

The actual routes and LSAs seen in the stub area differ between just stub and totally stub, totally stub provides the functionality usually looked for. The "not so" N of your NSSA does not change this. The totally (not so) stub(by) area uses the default route to the ABR to replace every individual route learned via OSPF otherwise. This is true even if no global default route is used inside the whole OSPF domain (autonomous system).

Erik
Photo of Henrique

Henrique, Employee

  • 10,302 Points 10k badge 2x thumb
When you configure an OSPF area to be Stub/NSSA you have to configure the "stub-default-cost" parameter and that will create a default route from WAN to Remote itself even without the originate default option in the Core.

Those are 2 different things.

You can try the following to help clarify it to you:
  • Use the NSSA stub-default-cost = 10 on both Remote and WAN
  • Use originate-default cost = 5 on Core
Check what's the default route cost for both WAN and Remote switches. You should have (for 1G uplink):
  • On Remote switch: Default route cost = 14 (stub-default-cost + 4 due to 1G uplink)
  • On WAN switch: Default route cost = 9 (originate-default cost + 4 due to 1G uplink)
That means what you are seeing on Remote (after disabling the port between Core and WAN switches) might not be the originate-default. It might be the stub-default-cost.
Photo of Tripathy, Priya Ranjan

Tripathy, Priya Ranjan, ESE

  • 2,306 Points 2k badge 2x thumb
Actually  When OSPF's summary routes are not imported, the default LSA   originated by an NSSA border router into the NSSA should be a Type-3 summary-LSA only. This protects the NSSA from routing intra-AS traffic out the AS via the default route of a Type-7 default LSA originating from one of the NSSA's internal routers.  When summary routes are imported into the NSSA, the default LSA originated by an NSSA border router must not be a Type-3 summary-LSA; otherwise its default route would be chosen over the potentially more preferred default routes of Type-7 default LSAs.

Hence converting the NSSA area to normal area solves the issue. To me it very much seems to be normal and expected one.

You can refer further looking into RFC3101 for different behavior of NSSA and other features of ospf application.