[j-nsp] Routing loop with OSPFv3 NSSA and external routes

[Chuck Anderson]

What does the inet6.0 RIB look like for 2001:db8::1/128 ?

On Fri, Feb 22, 2013 at 10:41:47AM +0100, Tore Anderson wrote:
> At this point, both R1 and R2 see SW1's NSSA LSA:
> 
> R1> show ospf3 database advertising-router 192.0.2.40 lsa-id 0.0.0.2 extensive
> 
> Area 10.0.0.0
>  Type       ID               Adv Rtr           Seq         Age  Cksum  Len
> NSSA        0.0.0.2          192.0.2.40       0x80000060  1237  0x7dfa  44
>   Prefix 2001:db8::1/128
>   Prefix-options 0x8, Metric 2, Type 1,
>   Aging timer 00:39:22
>   Installed 00:00:09 ago, expires in 00:39:23
>   Last changed 00:00:09 ago, Change count: 1
> 
> R2> show ospf3 database advertising-router 192.0.2.40 lsa-id 0.0.0.2 extensive
> 
> Area 10.0.0.0
>  Type       ID               Adv Rtr           Seq         Age  Cksum  Len
> NSSA        0.0.0.2          192.0.2.40       0x80000060  1241  0x7dfa  44
>   Prefix 2001:db8::1/128
>   Prefix-options 0x8, Metric 2, Type 1,
>   Aging timer 00:39:19
>   Installed 00:20:38 ago, expires in 00:39:19, sent 00:00:14 ago
>   Last changed 00:57:45 ago, Change count: 2
> 
> R1 has now become an ABR, so it translats the type-7 into type-5:
> 
> R1> show ospf3 database advertising-router self lsa-id 0.0.0.7 external extensive
>     OSPF3 AS SCOPE link state database
>  Type       ID               Adv Rtr           Seq         Age  Cksum  Len
> Extern     *0.0.0.7          192.0.2.5        0x80000001   108  0x6314  44
>   Prefix 2001:db8::1/128
>   Prefix-options 0x0, Metric 2, Type 1,
>   Gen timer 00:44:46
>   Aging timer 00:58:11
>   Installed 00:01:48 ago, expires in 00:58:12, sent 00:01:48 ago
>   Last changed 00:01:48 ago, Change count: 1, Ours
> 
> Note that R2 does *not* translate the type-7 into type-5 anymore even
> though it is still an ABR, only R1 does. This is expected as R1 has a
> higher router ID.
> 
> R2 also sees R1's translated type-5 LSA:
> 
> R2> show ospf3 database advertising-router 192.0.2.5 lsa-id 0.0.0.7 external extensive
>     OSPF3 AS SCOPE link state database
>  Type       ID               Adv Rtr           Seq         Age  Cksum  Len
> Extern      0.0.0.7          192.0.2.5        0x80000001   188  0x6314  44
>   Prefix 2001:db8::1/128
>   Prefix-options 0x0, Metric 2, Type 1,
>   Aging timer 00:56:52
>   Installed 00:03:07 ago, expires in 00:56:52, sent 00:03:07 ago
>   Last changed 00:03:07 ago, Change count: 1
> 
> R1 uses the type-7 intra-area LSA when selecting the best route, which I
> think is fine:
> 
> R1> show ospf3 route 2001:db8::1/128 extensive
> Prefix                                       Path  Route      NH   Metric
>                                              Type  Type       Type
> 2001:db8::1/128                              Ext1  Network    IP   4
>   NH-interface ae0.0, NH-addr fe80::[R2 ae0.0]
>   Area 10.0.0.0, Origin 192.0.2.40, Type 7, P-bit, Fwd NZ, Priority medium
> 
> ...while R2 uses the translated type-5 LSA originated by R1 as the best
> route:
> 
> R2> show ospf3 route 2001:db8::1/128 extensive
> Prefix                                       Path  Route      NH   Metric
>                                              Type  Type       Type
> 2001:db8::1/128                              Ext1  Network    IP   3
>   NH-interface ae0.0, NH-addr fe80::[R1 ae0.0]
>   Area 0.0.0.0, Origin 192.0.2.5, Fwd NZ, Priority medium
> 
> I think that the fault lies with R2 here. If R2 had ignored the
> translated type-5 LSA originated by R1, and instead preferred the
> intra-area type-7 LSA originated by SW1 when selecting the best path,
> I think everything would have worked just fine. Agreed?