OSPF NSSA translator

[sbdy467]

Hello all,

I just have a question I'm not able to find in the RFC

We have an OSPF NSSA area with routers r2 and r3 acting as ABR. Then we have routers r4 and r5 internal in this area, so the topology would be r2 - r4- r5 -r3, with r2 and r3 both connected to the backbone area. Then r3 is elected as the LSA type 7 to type 5 translator (higher router-id). Also r4 is acting as ASBR redistributing some routes.

Then If the link between r4 and r5 goes down. r2 will declare itself as translator and we will have in fact 2 translators in the area. I'd like to know what is making r2 believe he is a translator now. Is it because r2 lost any intra area route to r3 ?

Basically the question is to know how r2 will be aware r3 is translating or it is not translating to declare itself translator or not.... hope it is clear! thanks!

--John

[Georg Pauwen]

Hello,

does this also happen if you configure:

area 1 nssa translate type7 always

on R3 ?

[sbdy467]

Hello,

Configuring "area 1 nssa  translate type7 always" will not help, because r3 is already the translator (higher router-id) so configuring that command is not needed as it is already translating. The question I want to understand is what makes r2 believe it can start translating ?

Thanks

[Georg Pauwen]

Hello,

how are the routers linked ? When the link between 4 and 5 goes down, do 4 and 5 still have a link to R3 (one of them via R2) ?

If the broken link indeed results in a broken NSSA area, the election-preventing command I suggested wouldn't make much sense indeed...

[Giuseppe Larosa]

Hello @sbdy467 ,

with your topology the fault will divide the NSSA area in two parts.

In particular R3's Router LSA for the NSSA area is not valid anymore on R2, so R2 can promote itself to the role of NSSA ABR translator from type  7 to type 5.

I would ay it is an expected behaviour.

Also R3 will miss R4's Router LSA in NSSA area, so for this reason it cannot consider itself a translator as it has no path to the NSSA ASBR R4.

Hope to help

Giuseppe

[sbdy467]

Hello Giuseppe,

That is correct, the fault will split the NSSA area in two parts

> "In particular R3's Router LSA for the NSSA area is not valid anymore on R2, so R2 can promote itself to the role of NSSA ABR translator from type 7 to type 5."

that is correct as well, and the question is how R2 knows the router LSA is not valid anymore ? the router LSA from r3 was not flushed it is still in r2 lsdb. Is it because r2 lost intra-area routes to reach r3 ?

> "Also R3 will miss R4's Router LSA in NSSA area, so for this reason it cannot consider itself a translator as it has no path to the NSSA ASBR R4."

Agreed, but again r4 router lsa is still in the r3 lsdb, so what is making r3 stop translating ?

Many thanks for the feedback !

[Giuseppe Larosa · Accepted solution]

Hello @sbdy467 ,

thanks for your questions they made me think of it more in detail in OSPF terms:

>> Agreed, but again r4 router lsa is still in the r3 lsdb, so what is making r3 stop translating ?

R5 router LSA is updated and the transit link R5-R4 is now with state down,  so R3 knows that R4 is not reachable anymore in the NSSA Area.

>> that is correct as well, and the question is how R2 knows the router LSA is not valid anymore ? the router LSA from r3 was not flushed it is still in r2 lsdb. Is it because r2 lost intra-area routes to reach r3 ?

R4 router LSA is updated and the transit link R4-R5 is now with state down, so R2 will know there is no path to R3 in the NSSA Area,  and it can promote itself to translator for external routes type 7 injected by R4.

Hope to help

Giuseppe

[sbdy467]

Hi @Giuseppe Larosa 

Yes, thanks for confirming! so it is the lack of intra area routes that makes the ABRs promote themselves for translation.

Thanks

--John