OSPF NSSA and injected default route

[Kevin Dorrell]

I am studying the behaviour of the various types of OSPF area. There is a behaviour of an NSSA that took me by surprise, and left me wondering why ...

When you configure a standard stub area, the ABR strips out the E1/E2 routes, and injects a default route into the area instead. In a totally stubby area, the ABR strips out the IA routes as well, and relies on the injected default route.

I know that the main purpose of an NSSA is to define a stub area which is allowed to have an ASBR - type-7 to type-5 conversion on their way to the backbone, and all that. But what happens in the other direction? I see by experiment that the ABR strips out any E1/E2 routes on the way from the backbone to the NSSA, but does not inject a default route to replace them with. It is not until the NSSA becomes totally stubby (TSNSSA, area 1 nssa no-summary), that the ABR injects a default route into the NSSA area. I am struggling to understand why this behaviour. It means that if there are other external routes coming from other areas, they cannot be reached from the NSSA. Can anyone help me think this through?

Kevin Dorrell

Luxembourg

[Harold Ritter]

IOS doesn't generate the default route in the NSSA by default. You need to use the "default-information-originate" keyword on the "area x nssa" statement to force it to. This will cause the ABR to inject the 0/0 as a type 7 lsa into the NSSA.

On the other hand, IOS will generate the 0/0 as type 3 LSA when the ABR is configured as totally stubby NSSA.

Hope this helps,

[Kevin Dorrell]

Harold,

Thanks for the response. I am working my way through the case studies in Jeff Doyle's book. In fact, I should have skipped forward in the book before posting, because this behaviour is mentioned on page 543. Do you know why they chose to make this the default behaviour for NSSA, when the default behaviour for a stub is precisely the opposite? It seems a strange default that cuts off the NSSA from routes that are reachable from other areas.

I see from the book that if an ASBR is also and ABR for an NSSA, then by default it injects the extrenal routes into the NSSA, unless you do area 192.168.10.0 nsa no-redistribution. Maybe their choice of not injecting the default is related to this behaviour. I would be interested to try this for a stub - whether an ABR+ASBR will inject E1/E2 routes into the stub by default, and whether you can stop it with a no-redistribution.

Kevin Dorrell

Luxembourg

P.S. No it doesn't. Unlike an NSSA, an ABR+ASBR does not inject E1/E2 into the stub - it relies on the default route to handle it. Surprised how completely different are the behaviors of a stub and an NSSA.

[Richard Burts · Accepted solution]

Kevin

My understanding of the different treatment of generating default routes between stub and NSSA is this: in a stub or totally stub area the only way to get to anything "outside" of OSPF (any external) is through the ABR so it is appropriate for the ABR to automatically generate the default route. However in a NSSA it is possible to get "outside" of OSPF through the ASBR that is within the area and not through the ABR. In this case the administrator must decide whether the appropriate default route is through the ASBR or through the ABR.

Since the administrator must analyze and decide whether to configure a default route on the ABR it would be inappropriate for the ABR to automatically generate a default route.

HTH

Rick

[Harold Ritter · Accepted solution]

Kevin,

The different default route injection behaviors between stub area and NSSA probably lie in the wording used in RFC1587 and RFC2328 (can vs must).

RFC1587,Section 2.2 says:

In addition, an NSSA area border router _can_ originate a default type-7 LSA (IP address of 0.0.0.0) into the NSSA.

RFC2328, Section 3.6 says:

In order to take advantage of the OSPF stub area support,default routing _must_ be used in the stub area. This is accomplished as follows. One or more of the stub area's area border routers _must_ advertise a default route into the stub area via summary-LSAs.

Hope this helps,

[marikakis]

Harold made an observation on the RFC wording,

and I believe what Rick said is the reasoning behind the RFC wording,

so I have nothing better to say on the default route injection logic.

I do not think the choice of not injecting the default is related to the

option to specify "no-redistribution".

This is for situations where there is no need to inject the particular ABR's

external routes into the NSSA as type 7.

When redistribution occurs in the ABR of an NSSA,

the resulting externals are flooded in all areas that accept type 5 LSAs

and in the NSSA areas that the particular ABR participates as type 7 LSAs.

The problem is that in an ABR that also becomes an ASBR

it is not clear into which area the externals are originated.

Should those be considered originated in the "nssa-part" of the ABR,

and thus allowed into the NSSA ?

Or should those be considered originated in some other area that the ABR participates,

and thus not flooded into the NSSA ?

I would bet that in the case of non-NSSA stubs,

no type 5 LSAs will be flooded into them (by definition of a stub),

regardless if the "no-redistribution" is used or not.

I would also bet that you cannot even enter the command

outside the NSSA configuration context. (Have you tried this ?)

I think this command is meaningful only in NSSAs,

which have a special handling of external routes originated inside them.

Other stubs have no externals whatsoever (neither originated, nor imported).

Maria

[Kevin Dorrell]

Thank you very much to all three of you for your responses. It is interesting to see three different views of the same subject, all three of which resolve the issue, and all three of which make great contribution to understanding it.

Rick: Thanks for explaining the reasoning. I see now that the main purpose of the NSSA is to get external routes into the OSPF domain. The natural (default) way out of the NSSA could be through the externals, or into the backbone, at the choice of the administrator. In fact, one of those externals could be a default route itself, e.g. an Internet connection, in which case you would not want the ABR injecting a default route towards the backbone.

Harold: Thanks for the quotation from the RFC. It is always useful to know where the behavior comes from, and whether it is set in stone. So far I have found the RFC too indigestible to read from cover-to-cover, but I hope soon to have learned enough to digest it at one sitting.

Maria: Thanks for your analysis of the no-redistribution keyword. You make a good point about the ambiguity of the redistribute command. The command is designed to be orthogonal for all routing protocols, and so it does not mention the OSPF area. So if the ABR is also an ASBR, there needs to be a way to control which areas get the redistribution and which do not, and that is why we have the no-redistribution option on the area conmmand.

I did not try the no-redistribution on an area n stub command, but the doc says you cannot do it, so I think you win the bet. I have now cleared my routers ready to study address summarization, so I'll trust you and the doc for now.

And you are right: it would be meaningless (and also illegal) to inject type 5s into a stub, even if you are an ASBR.

(Sorry I didn't check "resolved my issue" on your posting - once I had rated it, it was too late to do so.)

I really appreciate the help I get on NetPro. At work, I do not have the opportunity to discuss infrastructure issues at this level, especially for routing issues. (LAN switching is a different matter.) Study material is fine as far as it goes, but the trouble with studying on your own is that the feedback is no good. That's where NetPro fills the gap. Thanks again.

Kevin Dorrell

Luxembourg