Re: OSPF NSSA type 7 to type 5 translation

NSSA area border router is supposed to translate LSAs from type 7 to type 5.

On the other hand only ASBR can generate type 5 LSA. In the case of NSSA, is it correct to assume that NSSA ABR must also necessarily be an ASBR?

Thanks,

rsg.

No it isn't ie.

R1 (area0) -> (area0) R2 (area2 - NSSA) -> (area2 - NSSA) R3 -> R4

In the above R3 & R4 are running EIGRP and R3 is advertising the EIGRP routes into area2.

R2 is the NSSA ABR and R3 is the NSSA ASBR.

The ABSR in an NSSA area will advertise external LSAs as type 7 as you say. These type 7s are blocked at the ABR ie. they are not advertised out of the nssa. But if the ASBR sets the P-bit in the LSA the ABR will then advertise the external LSA as a type 5 beyond the NSSA. However this doesn't mean the ABR is an ASBR because the definition of an ASBR is that it receives and advertises routes learnt from another routing protocol and clearly this does not apply to an NSSA ABR as in the example above.

Re: OSPF NSSA type 7 to type 5 translation

A router that exchanges routing information with routers belonging to other Autonomous Systems. Such a router advertises AS external routing information throughout the Autonomous System."

"12.1.5. Advertising Router

This field specifies the OSPF Router ID of the LSA's originator... AS-external-LSAs are originated by AS boundary routers."

Note that the last sentence above can kind of serve as a reverse definition of an ASBR from the LSAs it originates.

Similar reasoning can be found in other places of RFC 2328 e.g.:

"12.4.4. AS-external-LSAs

AS-external-LSAs describe routes to destinations external to the Autonomous System... AS-external-LSAs are originated by AS boundary routers."

"A.4.5 AS-external-LSAs

AS-external-LSAs are the Type 5 LSAs. These LSAs are originated by AS boundary routers, and describe destinations external to the AS."

Now, according to RFC 1587 you mentioned (keep reading ):

"4.1 Translating Type-7 LSAs Into Type-5 LSAs

...The newly originated type-5 LSAs will describe the same network and have the same network mask, metrics, forwarding address, external route tag and path type as the type-7 LSA. The advertising router field will be the router ID of this area border router."

So, the NSSA ABR is the advertising router of the type-5 LSAs originated due to the type-7-to-type-5 translation process, and is therefore an ASBR. I guess we could view that ABR as representing the external routing information of the NSSA to the rest of the AS.

Had I not read your second post, I would have provided an answer similar to Jon's. Since you had already read the RFC when you opened the thread, perhaps you could have also mentioned it in your original post instead of letting us fall into the trap!

As always, definitions generally tend to be imperfect and if taken very seriously, people can find themselves into a scholastic loop that loops forever. For example, according to the RFC you are reading, if multiple NSSA ABRs exist, one of them performs the translation process, so an NSSA ABR might not also be an ASBR.

"4.1 Translating Type-7 LSAs Into Type-5 LSAs

This step is performed as part of the NSSA's Dijkstra calculation after type-5 and type-7 routes have been calculated. If the calculating router is not an area border router this translation algorithm should be skipped. All reachable area border routers in the NSSA should now be examined noting the one with the highest router ID. If this router has the highest router ID, it will be the one translating type-7 LSAs into type-5 LSAs for the NSSA, otherwise the translation algorithm should not be performed."

The sentence: "All NSSA area border routers must also be AS boundary routers since they all must have the capability of translating a type-7 LSAs into a type-5 LSAs (see section 3.6 routes for the translation algorithm)." found in the same RFC could therefore be considered inaccurate according to the logic of that same RFC.

If we follow such paths of reasoning, I guess we might find ourselves ready to work in a legal department!

Enterprise Switching Business Unit is glad to announce Beta release 16.12.2 for all Catalyst 9200/9300/9400/9500/9600 and Catalyst 3650/3850 Platforms. This release is made available to allow users to test, evaluate and share fee...
view more

Purpose of the document
This document describes the general recommendations or best practices when designing and deploying the Cisco SD-Access technology. The document assumes that the reader has a general overview of Cisco's SD-Access for Distributed C...
view more

Do you currently have hands-on networking experience? If you do, we'd love to hear from you!
Your feedback will be reviewed and analyzed by our team to directly influence a networking management and monitoring product.
Take the 20-min or les...
view more