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

[Tore Anderson]

Hi list,

I'm scratching my head over an OSPFv3 routing loop to an external NSSA
destination that happens when extending the area to another router in
the backbone.

This is (hopefully) all the relevant parts of the currently (working)
setup. The two routers R1 and R2 are MX-es running JUNOS 12.2R3,
SW1 is an EX4200 VC running 10.4R6.

2001:db8::1/128 gets advertised to SW1 by a host using RIPng, and SW1
exports this route into OSPFv3.

  2001:db8::1/128
    | (RIPng-advertised)
    ~
    |
  [SW1 - ID 192.0.2.40]
    |
    | (NSSA area 10.0.0.0)
    |
    | xe-1/2/0.5
  [R2 - ID 192.0.2.4]
    | ae0.0     | xe-1/2/0.6
    |           |
    | (area 0)  | (area 0)
    |           |
    | ae0.0     | xe-1/2/0.6
  [R1 - ID 192.0.2.5]


On R2 I can see the external NSSA route appear fine:

R2> show ospf3 route 2001:db8::1 extensive
Prefix                                       Path  Route      NH   Metric
                                             Type  Type       Type
2001:db8::1/128                              Ext2  Network    IP   2
  NH-interface xe-1/2/0.5, NH-addr fe80::3
  Area 10.0.0.0, Origin 192.0.2.40, Type 7, P-bit, Fwd NZ, Priority medium

...and on R1 I can see that the ABR R2 translated it into a normal
external route and advertised it into area 0:

R1> show ospf3 route 2001:db8::1 extensive
Prefix                                       Path  Route      NH   Metric
                                             Type  Type       Type
2001:db8::1/128                              Ext2  Network    IP   2
  NH-interface ae0.0, NH-addr fe80::2
  NH-interface xe-1/2/0.6, NH-addr fe80::62:2
  Area 0.0.0.0, Origin 192.0.2.4, Fwd NZ, Priority medium
 
The problem occurs when I attempt to include R1 into area 10.0.0.0.
This I do by adding ae0.0 on R1 and R2 into the area in secondary
mode. My problem is that as soon as I do so, traffic to
2001:db8::1/128 starts to loop between R1 and R2. 

As expected, R1 now sees the type-7 LSA generated by SW1 (and
readvertises it into area 0 since it's now an ABR):

R1> run show ospf3 route 2001:db8::1 extensive
Prefix                                       Path  Route      NH   Metric
                                             Type  Type       Type
2001:db8::1/128                              Ext2  Network    IP   2
  NH-interface ae0.0, NH-addr fe80::2
  Area 10.0.0.0, Origin 192.0.2.40, Type 7, P-bit, Fwd NZ, Priority medium

R2, on the other hand, for seam prefers the area 0 external route that
was generated by R1 over the NSSA route generated by SW1:

R2> run show ospf3 route 2001:db8::1 extensive
Prefix                                       Path  Route      NH   Metric
                                             Type  Type       Type
2001:db8::1/128                              Ext2  Network    IP   2
  NH-interface ae0.0, NH-addr fe80::1
  NH-interface xe-1/2/0.6, NH-addr fe80::62:1
  Area 0.0.0.0, Origin 192.0.2.5, Fwd NZ, Priority medium

I have the exact same topology set up for IPv4/OSPFv3/RIPv2, and then
R2 prefers the route it learned from SW1's Type-7 LSA within area
10.0.0.0, instead of the normal external route received from R1. I would
have expected the same to happen with OSPFv3, but for some reason the
priorities are the other way around.

Anyone have an idea as to whether this is a bug or if I'm doing
something wrong here?

BR,
-- 
Tore Anderson